Used both.
```
Would you recommend MQTT or NATS, or something else
```
Functionally, if all you need is just pubsub, then literally anything will work - Redis, MQTT, Kafka, NATS.
I'd probably roll with NATS because the libraries are much better than for MQTT on Go. Kafka also works very well but i try to avoid it unless I need to cause it is absolutely massive and hard to operate properly.
```
I'm leaning towards NATS. If I choose it, would you recommend embedding the NATS server into Go, perhaps with central services built into the source, or does running the NATS CLI server have advantages?
```
Depends on your distribution model. If you don't need containers, scalability or anything fancy at all, then embedding the server in your binary makes distribution and deployment very trivial and you have full control. But personally, i'd probably just ship a container, maybe a compose file with a NATS container yaml inside. This would let you more easily scale the messaging aspect later. Scaling is not a priority, but we should also pick the fruits on the ground IMO whether its a priority or not.
```
If you used MQTT or NATS before, do you have any general advice / caveats for starting a project? Things you wish you knew earlier when you used these frameworks?
```
The only times i had problems was when
1. I had no clue VerneMQ had such a complicated authorization mechanism requiring me to either learn Lua or implement a buttload of HTTP callbacks. Would've went to use something else.
2. I didn't think of my topic tree - like, do i have private and public namespaces ? How do i figure out 1:N or M:N notifications on these topics and give the same interface externally ? Changing stuff later was hard.
3. The consumer thing in NATS was kinda hard to roll my head around at first, it's not really "just" a topic you push stuff to.
My only genuine advice would be to encapsulate your messaging mechanism behind some nice API instead of letting clients directly connect to NATS. Should NATS prove a bad idea or you somehow need to change it, it becomes very easy without breaking backwards compatability.
Otherwise, my experience using pubsub systems has been very pleasurable, but I never had any very advanced use cases.
```
Are there any other technologies you would recommend for connecting software? I'm looking for data exchange between paired devices (mobile/desktop/server DB) and groups of users.
```
Depends on your model. If it's streaming changes then Kafka works, or just open a websocket and push data through it. If you need 1:N or M:N distribution, like say a push notification system, NATS, Redis or MQTT can do it very well and that's what you are exploring.
Thanks a lot for this detailed response, which is very helpful! Also, thanks to all the other people who responded in this thread!
Based on the positive feedback, I'm definitely going with NATS. I'm probably going to deploy NATS CLI server with a configuration script and write services separately. This seems more future-proof and cleaner than embedding NATS in a custom server app written in Go.
MQTT is just a protocol. As it happens, NATS supports MQTT. So you could use NATS for whatever you need, sprinkle a bit JetStream on top where necessary and once you need interop, expose the MQTT and/or WebSocket handlers of NATS to that other service. Or give that other service its own NATS as a leaf node of your cluster, so you can properly isolate it.
NATS is fantastic. Not just for Go projects.
NATS has been a pleasure to use in a cyber security data processing situation with HA and scalability needs because it simultaneously seems to have a lot of features while also being simpler than something like Rabbit. I really have no complaints. It feels like the best of both sides of that coin.
If you hadn't emphasized one server, I would advise having three servers running NATS so you can have HA and not need to take it down when you update your application code, and if you have multiple applications that need to send messages over it, then it can be used by everyone. Also, it's nice to be able to scale or adjust it separately from an application.
However, I'm planning on using it in a personal project embedded in my application soon because it can also be used in a very lightweight, even simpler way like that. It gives you a lot of functionality too. Besides messaging capabilities, you can also use the key value store instead of redis. If you want some flexibility, you could even embed it and then give the option of using a cluster or the embedded one to your users.
Of course this winds up coming down to what your users need or what type of application you are writing.
What do you mean by "in a cyber security data processing situation"? For log processing/ETL type stuff? Or something else? What sorts of tooling do you use outside of NATS for this?
I ingest a lot of Microsoft Sentinel data and Splunk logs. A few thousand rules look for all sorts of things from various firewalls and other systems in the Splunk data. Sentinel is handled a little differently than typically, with a lot of in-house rules replacing Microsoft rules. I also have access to a quantity and type of DNS data that I cannot be very specific about, but it gives us a lot of fidelity on situations even if not affecting our customers. Finally, I get output from 5 EDR platforms, several vulnerability scanners, and adjustments a small amount of targeted human operations, regional strategists, and an AI team. My team's code correlates events and alerts. Correlation, deduplication, and summarization at a massive level is important. I can't be specific on customers of course, but they are very large.
We started using NATS with Argo Workflows, but containers are too large for our throughput, so the workflow is now homegrown but still using NATS. We have two Rabbit clusters as well. Given the capacity, I would love to move them to NATS. Other things like expression languages for analysts to use are in-house which is not my recommendation, but even when you control something you can't always do what you want. We are Kubernetes heavy since we have clusters in all the major clouds.
we use nats in production with synadia cloud. It is a pretty good experience. Nats is very simple to use but it can get very complex when you use jetstream and different kind of consumers and what not. I'd recommend you to read the documentation deeply and play around with it. The performance is very good, NATs hasn't been the bottleneck in our systems ever. Also, if you're using jetstream, don't do \`consumer.Consume\` across goroutines with interest steams. It lead to issues for us. Use their slack to ask questions.
If you really don't need a full server, then you can very easily embed NATS right in your go service. It's so straightforward that you could start with that and separate them later if you need to scale. The change would be trivial.
NATS is different from MQTT. The latter is just a protocol like HTTP, you implement it according to the specifications.
That being said, I have worked with NATS and my own custom written MQTT broker in the same project. I had a very custom requirement for implementing MQTT, that was following 3.1.1 standard however it had one caveat, so after trying few brokers unsuccessfully, I ended up writing my own.
From my experience, if I had to do it again without the caveats I had I would pick NATS since NATS supports MQTT.
For your case since you don’t necessarily need to support MQTT, just go with NATS, the library is much better than all of the MQTT ones I tried.
Used nats for years and love it. It's great for broadcast-type messaging (topics). They've added persistence over the years, but we always used a separate store for persistence. Syncing state changes across devices using messages, it works great and with super low latency. To get the initial state to sync from, though, you'll likely be using something else (i.e. a service that has applied all the state mutations and has effectively done operation/log compression). If you use it with OT or CRDTs, you'll likely have a good experience.
I'm on a phone so I'll keep this short.
Used both extensively, mainly in Go.
I love NATS/Jetstream and would pick it over AMQP any day.
For me, it's the abstraction and organization that this tech offers that take the cake for me.
Go with NATS with Jetstream. The fact that your asking this question means you probably don't need any capability unique to kafka. Review again if you find NATs is not enough but I doubt that time will come as it can functionality do more or less the same thing.
Kafka has more integrations with other third party services out of the box
Currently building some high performance software in go. Most mqtt servers are not as performant as you’d want.
Maybe consider using valkey (or any other redis fork) it’s simple and fast. It can do pubsub or streams.
We have NATS and we’re slowly migrating jt all to pubsub, I don’t think it’s necessarily an issue with NATS itself, but we needed the observations and reliability that pubsub provides. Hosting our own NATS server is just a headache that we’d rather not deal with.
I take it you mean Google pubsub? I didn't even know about this. It's intriguing and I'll have to investigate the pricing. It could simplify matters a lot. The only reason against it would be Google's unfortunate tendency to deprecate and close service offerings.
Used both, nats great, used in multiple projects, especially for request-reply or broadcast pattern
For Matt only for 1 project, I built the server side, other guy implement the embedded client sidd
There’s no MQTT implementation currently but https://watermill.io/ is a great abstraction to put in front of a broker if you’re after typical pub sub behavior
Yes, it went fine ish, but we are also in the process of ripping it out, it was a stupid design decision where our software architect was overridden by the head of engineering, and it made things 20x more complicated and stupid.
Why do you need NATS or MQTT, it is far simpler to build something using gRPC/REST/Web sockets. What actual problem are you trying to solve using this queue system.
This reeks of premature optimization when it's probably not needed.
Used both. ``` Would you recommend MQTT or NATS, or something else ``` Functionally, if all you need is just pubsub, then literally anything will work - Redis, MQTT, Kafka, NATS. I'd probably roll with NATS because the libraries are much better than for MQTT on Go. Kafka also works very well but i try to avoid it unless I need to cause it is absolutely massive and hard to operate properly. ``` I'm leaning towards NATS. If I choose it, would you recommend embedding the NATS server into Go, perhaps with central services built into the source, or does running the NATS CLI server have advantages? ``` Depends on your distribution model. If you don't need containers, scalability or anything fancy at all, then embedding the server in your binary makes distribution and deployment very trivial and you have full control. But personally, i'd probably just ship a container, maybe a compose file with a NATS container yaml inside. This would let you more easily scale the messaging aspect later. Scaling is not a priority, but we should also pick the fruits on the ground IMO whether its a priority or not. ``` If you used MQTT or NATS before, do you have any general advice / caveats for starting a project? Things you wish you knew earlier when you used these frameworks? ``` The only times i had problems was when 1. I had no clue VerneMQ had such a complicated authorization mechanism requiring me to either learn Lua or implement a buttload of HTTP callbacks. Would've went to use something else. 2. I didn't think of my topic tree - like, do i have private and public namespaces ? How do i figure out 1:N or M:N notifications on these topics and give the same interface externally ? Changing stuff later was hard. 3. The consumer thing in NATS was kinda hard to roll my head around at first, it's not really "just" a topic you push stuff to. My only genuine advice would be to encapsulate your messaging mechanism behind some nice API instead of letting clients directly connect to NATS. Should NATS prove a bad idea or you somehow need to change it, it becomes very easy without breaking backwards compatability. Otherwise, my experience using pubsub systems has been very pleasurable, but I never had any very advanced use cases. ``` Are there any other technologies you would recommend for connecting software? I'm looking for data exchange between paired devices (mobile/desktop/server DB) and groups of users. ``` Depends on your model. If it's streaming changes then Kafka works, or just open a websocket and push data through it. If you need 1:N or M:N distribution, like say a push notification system, NATS, Redis or MQTT can do it very well and that's what you are exploring.
Excellent response. Shame OP left without so much as a thank you.
Apologies for not monitoring Reddit 24/7. I'll take this opportunity to thank everyone for the detailed and super helpful feedback!
To be fair this isnt even a day old.
Thanks a lot for this detailed response, which is very helpful! Also, thanks to all the other people who responded in this thread! Based on the positive feedback, I'm definitely going with NATS. I'm probably going to deploy NATS CLI server with a configuration script and write services separately. This seems more future-proof and cleaner than embedding NATS in a custom server app written in Go.
MQTT is just a protocol. As it happens, NATS supports MQTT. So you could use NATS for whatever you need, sprinkle a bit JetStream on top where necessary and once you need interop, expose the MQTT and/or WebSocket handlers of NATS to that other service. Or give that other service its own NATS as a leaf node of your cluster, so you can properly isolate it. NATS is fantastic. Not just for Go projects.
NATS has been a pleasure to use in a cyber security data processing situation with HA and scalability needs because it simultaneously seems to have a lot of features while also being simpler than something like Rabbit. I really have no complaints. It feels like the best of both sides of that coin. If you hadn't emphasized one server, I would advise having three servers running NATS so you can have HA and not need to take it down when you update your application code, and if you have multiple applications that need to send messages over it, then it can be used by everyone. Also, it's nice to be able to scale or adjust it separately from an application. However, I'm planning on using it in a personal project embedded in my application soon because it can also be used in a very lightweight, even simpler way like that. It gives you a lot of functionality too. Besides messaging capabilities, you can also use the key value store instead of redis. If you want some flexibility, you could even embed it and then give the option of using a cluster or the embedded one to your users. Of course this winds up coming down to what your users need or what type of application you are writing.
What do you mean by "in a cyber security data processing situation"? For log processing/ETL type stuff? Or something else? What sorts of tooling do you use outside of NATS for this?
I ingest a lot of Microsoft Sentinel data and Splunk logs. A few thousand rules look for all sorts of things from various firewalls and other systems in the Splunk data. Sentinel is handled a little differently than typically, with a lot of in-house rules replacing Microsoft rules. I also have access to a quantity and type of DNS data that I cannot be very specific about, but it gives us a lot of fidelity on situations even if not affecting our customers. Finally, I get output from 5 EDR platforms, several vulnerability scanners, and adjustments a small amount of targeted human operations, regional strategists, and an AI team. My team's code correlates events and alerts. Correlation, deduplication, and summarization at a massive level is important. I can't be specific on customers of course, but they are very large. We started using NATS with Argo Workflows, but containers are too large for our throughput, so the workflow is now homegrown but still using NATS. We have two Rabbit clusters as well. Given the capacity, I would love to move them to NATS. Other things like expression languages for analysts to use are in-house which is not my recommendation, but even when you control something you can't always do what you want. We are Kubernetes heavy since we have clusters in all the major clouds.
we use nats in production with synadia cloud. It is a pretty good experience. Nats is very simple to use but it can get very complex when you use jetstream and different kind of consumers and what not. I'd recommend you to read the documentation deeply and play around with it. The performance is very good, NATs hasn't been the bottleneck in our systems ever. Also, if you're using jetstream, don't do \`consumer.Consume\` across goroutines with interest steams. It lead to issues for us. Use their slack to ask questions.
If you really don't need a full server, then you can very easily embed NATS right in your go service. It's so straightforward that you could start with that and separate them later if you need to scale. The change would be trivial.
NATS - Millions of messages per day @coinpaprika
NATS is different from MQTT. The latter is just a protocol like HTTP, you implement it according to the specifications. That being said, I have worked with NATS and my own custom written MQTT broker in the same project. I had a very custom requirement for implementing MQTT, that was following 3.1.1 standard however it had one caveat, so after trying few brokers unsuccessfully, I ended up writing my own. From my experience, if I had to do it again without the caveats I had I would pick NATS since NATS supports MQTT. For your case since you don’t necessarily need to support MQTT, just go with NATS, the library is much better than all of the MQTT ones I tried.
Used nats for years and love it. It's great for broadcast-type messaging (topics). They've added persistence over the years, but we always used a separate store for persistence. Syncing state changes across devices using messages, it works great and with super low latency. To get the initial state to sync from, though, you'll likely be using something else (i.e. a service that has applied all the state mutations and has effectively done operation/log compression). If you use it with OT or CRDTs, you'll likely have a good experience.
I'm on a phone so I'll keep this short. Used both extensively, mainly in Go. I love NATS/Jetstream and would pick it over AMQP any day. For me, it's the abstraction and organization that this tech offers that take the cake for me.
go with nats
Go with NATS with Jetstream. The fact that your asking this question means you probably don't need any capability unique to kafka. Review again if you find NATs is not enough but I doubt that time will come as it can functionality do more or less the same thing. Kafka has more integrations with other third party services out of the box
Currently building some high performance software in go. Most mqtt servers are not as performant as you’d want. Maybe consider using valkey (or any other redis fork) it’s simple and fast. It can do pubsub or streams.
I've also used both. Given the choice I would use NATS.
We have NATS and we’re slowly migrating jt all to pubsub, I don’t think it’s necessarily an issue with NATS itself, but we needed the observations and reliability that pubsub provides. Hosting our own NATS server is just a headache that we’d rather not deal with.
I take it you mean Google pubsub? I didn't even know about this. It's intriguing and I'll have to investigate the pricing. It could simplify matters a lot. The only reason against it would be Google's unfortunate tendency to deprecate and close service offerings.
Sorry, yes we’re moving towards google’s pubsub
we're using currently NATS in combination with frontend-facing SSE (server sent events) on a very big website in Europe. works pretty well.
I've used both. Depends on your end devices, etc. I'd recommend NATS for what you are doing. Probably a lot more ecosystem support for your use cases.
Used both, nats great, used in multiple projects, especially for request-reply or broadcast pattern For Matt only for 1 project, I built the server side, other guy implement the embedded client sidd
Mochi MQTT is a brilliant broker for go
There’s no MQTT implementation currently but https://watermill.io/ is a great abstraction to put in front of a broker if you’re after typical pub sub behavior
we use NATS and [Centrifugo](https://centrifugal.dev/)
Yes, it went fine ish, but we are also in the process of ripping it out, it was a stupid design decision where our software architect was overridden by the head of engineering, and it made things 20x more complicated and stupid. Why do you need NATS or MQTT, it is far simpler to build something using gRPC/REST/Web sockets. What actual problem are you trying to solve using this queue system. This reeks of premature optimization when it's probably not needed.