-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
KafkaJs seems not maintained anymore #13223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Sam from Confluent here. I know that the Confluent team are now officially supporting a javascript client with this early access release: https://github.com/confluentinc/confluent-kafka-javascript From the Readme:
Check it out and see if it meets your needs. |
Hi @samuelleach, thanks for pointing it out. I didn't knew about this work, on Confluent website I just saw a mention to node-rdkafka. Anyway based on the facts that this library is at an early development stage and the migration from |
+1 As a heavy user of NestJS and Kafka, I'd like to know the framework uses the best lib. https://github.com/confluentinc/confluent-kafka-javascript says, "This library is currently in early access and not meant for production use." I'd like to see NestJS switch to node-rdkafka sooner than later while keeping an eye on confluent-kafka-javascript for the future. |
Any thoughts from the maintainers? Because if you decide to change/add |
@samuelleach Looking forward to this library becoming production ready. It is disappointing to see the KafkaJS project become stale and I appreciate Confluent picking it up. One thing to keep in mind is that NestJS uses a custom partitioner for assigning reply topics to support the MessagePattern. See https://github.com/nestjs/nest/blob/master/packages/microservices/helpers/kafka-reply-partition-assigner.ts |
Related to tulios/kafkajs#1603 |
Version 1.0.0 of confluent-kafka-javascript is released (see https://github.com/confluentinc/confluent-kafka-javascript/releases/tag/v1.0.0). Are there any plans on switching to that now stable library from the non maintained kafkajs library? |
I’m really looking forward to this |
Please, do not replace kafkajs. It still provides useful functionality such as partition reassignment. There is no such functionality in node kafka client libraries that use As for the issue #12703, I believe the reason why messages are consumed one topic at a time, is because in nest/microservices ServerKafka creates only one consumer for all the topics. To consume topics concurrently, each topic must have its own consumer. Current behavior:
Supposed behavior:
An option to create a dedicated consumer for a topic would have solved the issue with concurrent processing of messages in different topics. |
There is no point to keep kafkajs, it is not maintained at all (issues will never be closed). Any mechanisms such as partition reassignment could be implemented in different libraries. |
About this, I took some time to play around with Confluent kafka-javascript library and NestJS and I find it very promising, also it recently reached a stable version. I didn't try to replace the internal microservice implementation but I've just used it as a standalone module. If anyone is interested I've wrote a short article (here) with my discoveries, hope it will help someone. Additionally, I'm still interested to try to replace the KafkaJS implementation behind NestJS to use Confluent library, but as the position of the maintainers is not very clear I don't know of it's worth investing some time in it. |
Ideally, we'd see a new transport strategy (as suggested here #13538) so folks can slowly migrate over time if they see a need for it. |
another lib: |
Cool! I didn't know about this one. However the comparison they have made is on node-rdkafka and KafkaJS not on the new Confluent kafka-javascript library which should be the reference for benchmarks and DX. |
I've been working on a custom transport strategy that allows integrating Otherwise, the transporter seems to be working well - will share it as soon as it's ready to use (can be safely used for those who rely on |
@samuelleach is there any chance that Confluent's package will support custom partition assigners? |
For those who want to use Server class (
|
Why not just use node-rdkafka? |
I don't mind implementing strategies for confluent's wrapper and rdkafka as well, if needed |
I mean that node-rdkafka is much more popular solution in comparison to platformatic/kafka (better maintenance, more opportunities) |
confluent's wrapper is also very promising |
Confluent's wrapper appears to have some significant shortcomings at the moment:
Given these issues, it doesn’t seem reliable enough to use as a foundation for a transport layer, at least for now. I'd rather recommend everyone to stick to kafkajs (or consider using platformatic/kafka strategy that I've shown above) |
@kamilmysliwiec I think that a wrapper for the official confluent wrapper makes sense at this stage. Even if it's just for the brave to already try it out and start discovering kinks? |
@kamilmysliwiec yeah I did see that comment and took a look at the issues you linked. I agree with your reading that better to stick with kafkajs for production (or try plataformatec) and though those issues would perhaps be an issue for a robust production-ready solution, I was thinking that I wouldn't mind exploring how the confluent wrapper performs with our preview trafiic (which given more time I would trust to be the better long term bet ) basically because I'm not really using the event hooks and would love to find issues early... But understand your sentiment.... |
node-rdkafka might be used (wrapper for Nest needed) |
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Lately I was using NestJs to build a Kafka micro service for a consumer application. I had to study in depth what NestJs uses as the underlying transport to be able to communicate with Kafka brokers safely and efficiently. To be sure of that I needed to tune the underlying Kafka client implementation KafkaJs. While checking the repository I saw that this project is no more maintained and the people who previously worked on it are no longer responding even to discussion they started (see tulios/kafkajs#1603). Because of that I think that this situation could mine the stability of the NestJs project too considering that Kafka is a must-have integration for today's projects.
Describe the solution you'd like
The solution should be to migrate to a stable Kafka implementation that have a strong support. node-rdkafka, which wrap the official C/C++ Confluent driver should be a good choice.
Teachability, documentation, adoption, migration strategy
Dropping the support for KafkaJs may not be the best solution solution for whom is using it without issue in production but certainly you may allow people to start or switch to a different implementation (https://www.npmjs.com/package/node-rdkafka). That could be the right way to start removing support for KafkaJs in case the project remains in this stale situation.
What is the motivation / use case for changing the behavior?
Avoid to be locked in a Kafka implementation that is not going to be supported anymore.
The text was updated successfully, but these errors were encountered: