zlacker

We have had pretty bad experience with NATS. Apart from core NATS which is just in memory, you need their sub modules to build any kind of serious business on top of it.

We initially built our code around NATSStreaming, they then went ahead and deprecated that.

But since we saw so many big companies using NATS, they thought it might be a good idea to stick with it and we did a year long migration to their shiny new NATSJetstream Push based approach, but from what I see now in the conversations they are going to deprecate that too in favour of Pull based approach which is architecturally very different, now we will have to somehow convince management for another rewrite. I am not sure if we should even rewrite or just move to another product at this point.

Dear NATS, please stop throwing away and rewriting protocols and products. Or make it such that the end client libraries would handle that upgrade automatically with a library upgrade.

We should have just stuck with the more traditional Kafka or RabbitMQ.

What I have also learnt is that when companies put big brand logos on their websites, it just means some random Dev from that company is using it for their side project or experimental mini project.

>>evnix+(OP)
From what I've seen it's too early to migrate from Push. With the last update they emphasized Pull as the default, but Push is not deprecated yet.

And even NATS Streaming still works: it is deprecated, not removed.

Unlike databases, a good thing about messaging and streaming solutions is that you don't have to pick one: you can make them talk to each other as long as there are bridges. This also applies to different approaches to messaging/streaming provided by a single platform.

>>Kinran+Md
Just like you don't want to support tens of different databases you shouldn't build your solution on lots of bridged message busses. If stuff goes down at 2 am you don't want to have to find out which message queue was the problem or what tooling you should use to debug it.

>>bzzzt+Vy
Sure, but it's an inconvenience, not a total blocker. With databases you lose foreign keys and you have to replace a single query with N. And you don't want to have ten different solutions of course, but two is fine and allows for comfortable migrations.

>>evnix+(OP)
(note that NATS Streaming is a now deprecated predecessor to NATS JetStream)

Pull does have advantages over push (e.g. one-to-one flow control since the transfer of the messages is initiated by the client (pull requests)), and they are basically functionally equivalent (only thing push can do that pull can not is send a copy of all the message to all the subscribers, should you ever need it). They both exists because historically push came first and then pull later).

As a developper using NATS JetStream you should really not have to worry about push or pull, you should just care whether you want to consume the messages via call back or via an iterator or via fetching batches, after that whether pull or push is being used underneath the covers is irrelevant to you.

And this is exactly how it is in the new JetStream API (https://github.com/nats-io/nats.go/tree/main/jetstream#readm...) you don't have to worry about push/pull anymore and you can consume in any of the 3 ways described above (callback, iterator, fetch batch) it's all a lot simpler and easier to use.