Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

High-Performance server for NATS.io, the cloud and edge native messaging system

github.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#31

Post by protochron »

I work quite a bit with CNCF wasmCloud (https://wasmcloud.com/) and that project wouldn't exist without NATS. You can think of wasmCloud as a distributed compute lattice using WebAssembly on the server for providing the compute and NATS to provide the interconnectivity between your various WebAssembly modules.

NATS certainly has its quirks, but I can't recommend it highly enough if you need any sort of pub/sub or stream processing. It even has built-in key-value and object storage for when you need to store larger messages or content. I definitely prefer Jetstream to Kafka in pretty much every use case I can think of. At my current employer (https://cosmonic.com) we use NATS not only for wasmCloud, but we also stream log data and metrics and it keeps up with everything we throw at it with a very low footprint. Auth is kind of counterintuitive until you've spent some time with it, but NATS provides you with a ton of flexibility (docs here: https://docs.nats.io/running-a-nats-service/configuration/se...).

https://natsbyexample.com/ is a great resource, and can do a better job than I can in illustrating the various ways NATS can be used along with different deployment topologies.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#32

Post by xuancanh »

re-thc wrote: post #28
zmmmmm wrote: post #20

Struggling to figure out what "cloud native" actually means. Unfortunately their own web site doesn't say and the CNCF web site they link to leaves me none the wiser. At a guess they are talking about applications being built from the ground up to dynamically allocate resources using cloud providers APIs directly rather than relying on an assumption fixed resources are already provisioned and the application runs wit…

> Struggling to figure out what "cloud native" actually means. - very fast startup - low memory - can be easily distributed or is stateless

That is not what cloud native means. It is an overloaded term, but the basic idea is that the application is designed to operate in the cloud environment, utilizing cloud's capabilities such as elastic and automated infrastructure management.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#33

Post by re-thc »

xuancanh wrote: post #32
re-thc wrote: post #28

Earlier quoted context omitted.

> Struggling to figure out what "cloud native" actually means. - very fast startup - low memory - can be easily distributed or is stateless

That is not what cloud native means. It is an overloaded term, but the basic idea is that the application is designed to operate in the cloud environment, utilizing cloud's capabilities such as elastic and automated infrastructure management.

> That is not what cloud native means. > utilizing cloud's capabilities such as elastic and automated infrastructure management.

Contradictory perhaps? So it's not what it means but it is what it means?

In order to achieve what you've said in vague terms you definitely do need to try to be stateless, have fast startup and reduce memory. Clear examples are things like lambda and fargate.

How can you be elastic if you have an application server that takes 10 minutes to start?

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#34

Post by no_circuit »

TIBCO Rednezvous, https://www.tibco.com/products/tibco-rendezvous, is the first thing that came to my mind from previous experience in the financial industry working with real-time market data. Although I'm not sure if it has built-in KV support for dealing with large payloads like NATS does, TIBCO RV and their related software packages are worth checking out to see what an long time established commercial product offers. Which leads me to...

... the protocol is text-based like HTTP with CR LF for field both for the client, https://docs.nats.io/reference/reference-protocols/nats-prot..., and cluster protocols, https://docs.nats.io/reference/reference-protocols/nats-serv... -- which means encoding overhead if your payloads are binary. So depending on your definition of performance, ymmv.

I really do not see how implementing an API across multiple languages is easier by making a new linefeed-based protocol, https://github.com/nats-io/nats-server/blob/0421c65c888bf381..., than just using code-generated JSON or gRPC (Protobuf or Flatbuffers). One could then write subscriptions/clustering algorithms in a protocol-neutral library.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#35

Post by c-cube »

no_circuit wrote: post #34

TIBCO Rednezvous, https://www.tibco.com/products/tibco-rendezvous , is the first thing that came to my mind from previous experience in the financial industry working with real-time market data. Although I'm not sure if it has built-in KV support for dealing with large payloads like NATS does, TIBCO RV and their related software packages are worth checking out to see what an long time established commercial product o…

I don't think there's encoding overhead. It's like http, like you said, but just like http body encoding it seems that actual payloads are preceded with their length so that you just read n followed by n bytes. Look at the docs for `pub` for example. Json would be less efficient; gRPC adds tons of complexity and overhead.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#36

Post by klabb3 »

c-cube wrote: post #35
no_circuit wrote: post #34

TIBCO Rednezvous, https://www.tibco.com/products/tibco-rendezvous , is the first thing that came to my mind from previous experience in the financial industry working with real-time market data. Although I'm not sure if it has built-in KV support for dealing with large payloads like NATS does, TIBCO RV and their related software packages are worth checking out to see what an long time established commercial product o…

I don't think there's encoding overhead. It's like http, like you said, but just like http body encoding it seems that actual payloads are preceded with their length so that you just read n followed by n bytes. Look at the docs for `pub` for example. Json would be less efficient; gRPC adds tons of complexity and overhead.

Correct. Text based is more than fine these days, as long as you use length prefix so you can avoid escaping. But you do still need to parse lines which can be tricky in bare or poorly tooled environments. It’s the best trade off today, because debugging binary formats is a serious obstacle.

> Json would be less efficient; gRPC adds tons of complexity and overhead.

Indeed. There aren’t many suitable specs around, and this protocol, albeit custom, is very easy to implement. Which is proven by the fact that there are well maintained Nats clients in many different languages.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#37

Post by jensneuse »

We've recently built an adapter for NATS KV so you can easily expose it through an HTTP-based GraphQL API. (https://docs.wundergraph.com/docs/databases/kv) We're also looking at supporting streams in the future.

What's great is that NATS is written in go and we can easily embed it for testing and dev purposes. Furthermore, Synadia makes it super easy to run NATS across multiple regions.

Re: High-Performance server for NATS.io, the cloud and edge native messaging system

#38

Post by klabb3 »

zerbinxx wrote: post #12
atombender wrote: post #7

Earlier quoted context omitted.

NATS is not a queue. It's distributed pub/sub message broker for communicating between applications. NATS's only responsibility is to route messages in near-real-time from publishers to consumers. Messages are ephemeral and dropped immediately after delivery; if nobody is listening, the messages vanish. Messages are only queued temporarily in RAM if the consumer is busy, and they can get dropped if a consumer doesn't…

It is worth noting that the jetstream API (to me) (not that experienced) to lack some of the features of Kafka w.r.t. replayability - for instance I can’t easily say “go back and re-run messages from X point-in-time”. Instead it may be necessary to write custom handlers for replay or safeguard your systems to be very idempotent (a good pattern in event driven systems, but not one that is explicitly required by Kafkae…

Jetstream has real time replay[1], and you can easily pick a starting time, and continue to stream new events as well.

But yes, to be able to replay without side effects you’ll want to make sure you’re setting up the consumers correctly. That may need some custom logic, but isn’t that necessary with any message queue?

[1]: https://docs.nats.io/using-nats/developer/develop_jetstream

Post reply on HN