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.
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.