Propan VS scikit-llm

Later, we discovered Propan, a library created by Nikita Pastukhov, which solved similar problems but for RabbitMQ. Recognizing the potential for collaboration, we joined forces with Nikita to build a unified library that could work seamlessly with both Kafka and RabbitMQ. And that's how FastStream came to be—a solution born out of the need for simplicity and efficiency in microservices development.

The next step was to figure out what to do next. We posted questions on a few relevant subreddits and got quite a few feature requests, mostly around supporting other protocols, encoding schemas etc. But, we also got a message from a developer of a similar framework Propan that was released at about the same time and was gaining quite a traction in the RabbitMQ community. That developer was Nikita Pastukhov and he made an intriguing proposal: let's join our efforts and create one framework with the best features of both. Both projects were growing at roughly the same speed but targeted different communities. So the potential for double growth was there. After a quick consideration, we realized there was not much to lose and there was a lot to gain. Of course, we would lose absolute control over the project but losing control to the community is the only way for an open-source project to succeed. On the positive side, we would gain a very skilled maintainer who single-handedly created a similar framework all by himself. The frameworks were conceptually very similar so we concluded there would not be much friction of ideas and we should be able to reach consensus on the most important design issues.

FastStream simplifies the process of writing producers and consumers for message queues, handling all the parsing, networking and documentation generation automatically. It is a new package based on the ideas and experiences gained from FastKafka and Propan. By joining our forces, we picked up the best from both packages and created a unified way to write services capable of processing streamed data regardless of the underlying protocol. We'll continue to maintain both packages, but new development will be in this project.

FastStream (https://github.com/airtai/faststream) is a new Python framework, born from Propan and FastKafka teams' collaboration (both are deprecated now). It extremely simplifies event-driven system development, handling all the parsing, networking, and documentation generation automatically. Now FastStream supports RabbitMQ and Kafka, but supported brokers are constantly growing (wait for NATS and Redis a bit). FastStream itself is a really great tool to build event-driven services. Also, it has a native FastAPI integration. Just create a StreamRouter (very close to APIRouter) and register event handlers the same with the regular HTTP-endpoints way:

Hello everyone!

Two months ago I told you about Propan - the Python framework to build messaging services based on Any Message Broker. So, there were a lot of changes for this time and I want you to tell me again about them.

At first, we added Kafka, Redis Pub/Sub, SQS, and NatsJS support (to RabbitMQ and regular NATS). At now you can interact with these brokers via the same Propan interfaces.

Also, we added an AsyncAPI schema autogeneration, so you already have documentation for your services if you are using Propan.

And the last (but not least) - PydanticV2 support! You can use V1 and V2 both, but V2 is much faster - it is a preferred way to write new services.

By the way: we have a new Propan major version draft, so if you want to participate in the discussion and suggest a new feature, it is time to join our discord and tell about it!

Propan: https://github.com/Lancetnik/Propan

Also it is important for my own Propan package implementing some custom routers.

As you may know, I am developing Propan framework to interact with various message brokers single way. When I published a post about the existence of the framework, users immediately asked "When to expect SQS support?". Now!

A couple of days ago I wrote about the release of my framework for working with various message brokers - Propan!

Just found Sci-KitLLM on LinkedIn. It's an open source package for building LLM usage directly into your workflows that use sklearn. Seems the main use case is text classification atm. Very interesting looking, would love to hear people's opinions.