Funboost: one decorator to put a Python function on a queue

The dual mode is the trick, and it is why the decorator is enough

Funboost's central idea is that adding the boost decorator to a function gives you two things from one definition. The documentation calls it an anti-framework framework and describes the two modes as the reason it is easy to pick up. Call the function directly and it runs synchronously, without going through a queue. Call the push method on it and the same function is sent to a message queue for distributed asynchronous execution. That dual behaviour is what lets you adopt the library incrementally, because a function that is pushed in one place and called directly in another keeps working, and a test can call the function synchronously while production pushes it. Everything else is configured through the parameters of the decorator, which the documentation names as BoosterParams, and the guidance is that the examples in the chapter on getting started all follow the same pattern with only those parameters changing. The stated core value proposition is to leave the complexity to the framework and the simplicity to the user, with the framing that the capabilities are heavy while the usage is light, since only one line of the boost decorator has to be written.

Forty brokers, including databases and bare sockets

The broker list is where the framework earns the word comprehensive, and the principle behind it is stated as anything can be a broker. The traditional message queues named include RabbitMQ, Kafka, NSQ, RocketMQ, MQTT, NATS and Pulsar. The database category is the surprising one, because it covers both NoSQL and SQL. On the NoSQL side there is Redis in several modes, List, Pub/Sub and Stream, and MongoDB. On the SQL side there is MySQL, PostgreSQL, Oracle, SQL Server and SQLite, the last supported through SQLAlchemy or Peewee. Then there are network protocols used directly, with TCP, UDP, HTTP and gRPC, which means queue communication is possible without deploying a broker service at all. The file system category covers local files and folders, again with SQLite for single machine or simple scenarios. The event driven category is MySQL CDC based on binlog change capture, which is what gives the framework its event driven capability rather than a plain task queue. Finally, third party frameworks can be used as the underlying broker, with Celery, Dramatiq, Huey, RQ and Nameko named, which means the same interface can schedule work onto an existing framework's machinery. The practical value of this is that changing brokers does not change your code, and the setup.py reflects the same list as optional extras.

Reliability controls, and the ones that decide whether a task queue is useful

The reliability set is what separates a task queue from a message dropper, and the framework's own description of it is worth taking seriously. There is consumption acknowledgement, so a message is not considered done until the consumer says so. There is automatic retry. There is a dead letter queue, so a message that keeps failing lands somewhere you can look at instead of cycling forever. There is checkpointing for the crawling case. And the claim is that even if the server goes down, the task is not lost. Alongside that sits a set of control features that the documentation says number around thirty, and the ones worth calling out are precise rate limiting, distributed rate limiting, scheduled and delayed tasks, timeout and circuit breaking, and task filtering. The reason these matter together is that they are the difference between a queue and a queue you can operate. A task queue without a dead letter queue is a place where failures accumulate invisibly, and a task queue without a rate limit is a way to take down a downstream service the first time a batch job runs. The open source web manager, funweb, is the monitoring surface, covering queue backlog, consumer status and task state.

Concurrency modes, including stacking them on top of each other

The concurrency story is broader than most libraries offer, because it covers both the execution model and the way those models compose. The base modes are threading for multiple threads, asyncio for asynchronous IO, gevent and eventlet for coroutine style concurrency, and a single thread mode for when you want none of it. On top of that there are the stacked modes, where multi-processing combines with any of the fine grained modes, for example multi-threading or coroutines, so that you can use multiple cores and multiple threads at once. The stated goal is to squeeze out the CPU as far as possible. The reason this is unusual is that the choice of concurrency model is normally made once, by the framework you adopt, and here it is a per-function parameter. That is a genuine advantage when the workload is mixed, where one function is IO bound and another is CPU bound, and the framework lets each run in the right mode inside the same process. The topics listed for the repository include threading, asyncio, eventlet, gevent and multiprocessing, which matches the documented set.

Functions as services, and the scheduling of them

The FaaS direction is described as a highlight in the documentation, and the mechanism is the funboost.faas module. With it you can turn an ordinary function into an HTTP microservice endpoint, and the description is that functions are discovered automatically and that publishing a message, getting the result and managing the task are all one click, giving a serverless-like experience. The architecture underneath is conventional, the producer to broker to consumer model, with an optional RPC mode where the consumer calls back to the producer, and the documentation is explicit that the design keeps the core flow as simple as possible even though the feature set goes far beyond what a specialist framework such as Scrapy offers. Alongside that there is a set of orchestration style features named in the feature map, including distributed scheduled tasks, workflow style task orchestration, micro-batch consumption, FaaS hot loading, Prometheus metrics and OpenTelemetry tracing, along with two spider oriented modules. The feature map is presented as a mind map image, and the recommendation to download it and view it locally suggests the surface area is too large to read as text.

How it differs from Celery, and the marketing behind that

The project compares itself to Celery in some detail, and you should read the comparison with a critical eye because it is written by the competitor. The stated analogy is that the relationship between funboost and Celery is like the relationship between the iPhone and Nokia Symbian, and the argument is that the two have overlapping core functions, both being asynchronous task schedulers built on distributed message queues, following the same producer, broker and consumer shape, so overlap does not make one redundant. The comparison table then contrasts the design philosophies, framing Celery as framework enslavement where code has to be organised around the architecture and the App instance, and funboost as non-intrusive empowerment. The first class citizen differs, with the Celery App instance against the user function. The syntax differs, with a task decorator on an app against the boost decorator. The table also makes performance claims, describing funboost as far ahead with publishing performance at 22 times and consumption performance at 46 times Celery. Those are the project's own numbers, no benchmark methodology is given for them, and no independent measurement is offered, so treat them as a claim to verify rather than a result. The useful part of the comparison for an engineer is the structural difference, which is real and checkable in the source of either project.

A repository shaped around documentation and AI context files

The repository layout says something about how the project is run. At the top level there is the funboost package, an examples directory, a tests directory, a test_frame directory, a txt_queues directory, a setup.py, a requirements file and two large markdown files, funboost_all_docs.md and funboost_all_docs_and_codes.md, the latter described as about 900K of context containing the rules, the skills, the full tutorial, the source and usage demos, and positioned as something you can feed directly to an AI so it writes code for you. There are also agent configuration directories for several tools and a CLAUDE.md. Installing it is a single pip command:

pip install funboost --upgrade  

The presence of AI-oriented files is a deliberate strategy rather than an accident, and the documentation pushes it hard, with a chapter 14 described as the recommended route for learning the framework using a large model, and a page listing DeepSeek and Gemini among the million context models the file is meant for. The full documentation is hosted on ReadTheDocs, and the argument for reading it is that the framework is simple enough that the tutorial chapter 1.3 is the only example you strictly need. The last push was on 2026-08-11 and the repository publishes no GitHub releases, so the pip version is the version marker to track.

Editorial conclusion

Funboost is a good fit for a Python codebase that has a few functions which need to run reliably off the request path, especially one that already has a broker and does not want to restructure its code around a task framework, since the decorator leaves the function callable both ways. It is the wrong tool for a team that wants a full task framework with its own conventions, since the project positions itself explicitly against that, and it is the wrong tool if you need only one broker and one behaviour, where a small amount of Celery or plain kombu code is easier to own. It is also the wrong tool if you cannot accept a dependency with this many optional backends, since the install with all extras pulls a large set of client libraries. Before adopting it, read the section on evaluating whether it is worth the investment, then pick one broker and one set of control options and start there rather than using the full surface. The licence field for the repository is not identified, so read the licensing before building on it, and note the last push was on 2026-08-11 with no GitHub releases published.

Frequently asked questions

Official sources

1. Issues
2. README
3. ydf0509/funboost on GitHub