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

61–70 of 75 posts

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

#61

Post by mprime1 »

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…

The non-cynical, snark-free definition would be “built from the ground up to be used and deployed in various kinds of cloud based environments”.

Whether that’s just marketing BS or real depends on the project. Wether it fits your particular kind of cloud environment is also a different story.

In the specific case of NATS I love how I can start with a single server on localhost, then maybe upgrade to a single fly.io instance, then later move to a larger AWS, instance, then later add some fault-tolerance by turning a single server into a cluster, then later have multiple clusters in various AZs around the world, hosted on different cloud providers.

NATS makes all of these changes (and a lot more) a breeze. Any component or application using pub/sub, KeyVal, durable streams, request/response will just keep working without a single any changes.

Disclaimer: I love NATS, it’s the most promising piece of infrastructure technology I have seen in a long time.

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

#62

Post by no_circuit »

klabb3 wrote: post #36
c-cube wrote: post #35

Earlier quoted context omitted.

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…

The only developers that would likely need to debug binary protocols are the framework developer themselves. It would be an extremely rare occurrence for someone to need to use a binary/hex viewer to figure out what is going wrong with their "app". Perhaps you are thinking of telemetry/introspection of one's own messages? In that case there usually is a library call to convert them to a human readable format like JSON, e.g., https://protobuf.dev/programming-guides/proto3/#json.

IMO it is a real waste of developer time to code up a new transport protocol without determining that the existing ones don't work or don't perform as well as needed. Multiply that by all the programming languages that need to be supported... when instead the client APIs could have been mostly code generated.

Although may only apply to the "client-side" API, what is going in the message payload? JSON probably, or some other serialization format. I don't think a lot of developers are hand writing parsers for their own payloads. The overhead of the JSON or Protobuf parser is already in there.

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

#63

Post by jitl »

sofixa wrote: post #45
jitl wrote: post #2

With all the message queue whatever thingies, as an outside I’m quite confused about ideal use cases. NATS vs MQTT vs Kafka vs Redis Queue vs Amazon SQS - how do they all stack up?

> NATS vs MQTT vs Kafka vs Redis Queue vs Amazon SQS - how do they all stack up I'm curious why are RabbitMQ and AMQP no longer part of such comparisons (not only your comment, nobody else on this thread has mentioned them).

At my past job RabbitMQ was an infrequent source of painful surprises. I think it's kinda like HAProxy, a venerable solution that's well known but being replaced in new work more trendy implementations of the same kind of thing.

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

#64

Post by coder543 »

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'm not sure how much it will reduce your skepticism, but I believe NATS was actually created by the same person who created TIBCO RV: https://twitter.com/derekcollison/status/1163299967089254402

Derek seems like the kind of person who might know a thing or two about messaging systems.

I really like what NATS has become, and I do appreciate the simplicity of the protocol.

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

#65

Post by rcombatwombat »

evnix wrote: post #48

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 N…

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

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

#66

Post by rcombatwombat »

Kinrany wrote: post #58
atombender wrote: post #54

Earlier quoted context omitted.

You wouldn't/shouldn't choose NATS if your application needs different semantics. NATS does not have stateful storage. So when a consumer disconnects and reconnects, there is nowhere for NATS to store the messages temporarily. You can solve this by storing messages in a stateful storage first, then use NATS as a way to distribute them. You would need your own mechanism to replay messages on reconnect. This is coincid…

Jetstream is distributed as an optional part of NATS, so while it exists as a layer on top of NATS Core and provides a different model, describing NATS as entirely stateless is not totally accurate Though I suspect that Synadia people might do at least one more minor iteration of Jetstream: it still seems a little more complex than it needs to be, unlike Core

See https://github.com/nats-io/nats.go/tree/main/jetstream#readm...

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

#67

Post by rcombatwombat »

atombender wrote: post #14
zerbinxx wrote: post #12

Earlier quoted context omitted.

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…

Yes, I did not mean to suggest that Jetstream is equivalent to Kafka. It's quite different.

IMHO and I would argue that JetStream functionally does much more than Apache Kafka (e.g. stream filtering using subject based addressing, stream with working queue semantics, constraints on streams, compare and set (so you can do CRUD operations), stream sourcing and mirroring, etc...), and has many (most?) of the features of Kafka Streams.

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

#68

Post by rcombatwombat »

jonathanstrange wrote: post #49

Can someone tell me which transport protocols and ports this uses or can be configured to use? Moreover, do clients have NAT traversal capabilities (no pun intended)? This is always so hard to figure out for B2B libraries.

It supports clients connecting over TCP (which can be encrypted) and Websockets (can also be encrypted), you can configure it to pick on any port you want and it works through Network Address Translation (see https://docs.nats.io/running-a-nats-service/configuration#co...). Even supports MQTT clients directly (https://docs.nats.io/running-a-nats-service/configuration/mq...)

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

#69

Post by rcombatwombat »

lakomen wrote: post #57
devmunchies wrote: post #29

Earlier quoted context omitted.

You can subscribe to all topics by using a *. Why not have a debug subscriber that listens to all messages and plays it in the terminal? I agree that the auth system is cumbersome. I wanted to use it on the edge for IoT devices where the device only has the same permissions as the user who the device belongs to, but not very easy. Their auth isn’t very customizable.

This is actually a good idea, I'll try that, thanks :) But, you know, it's still a bit more complicated than opening the browser's debug console and inspecting request and response in the networking tab. Yeah you have operators, which are essentially the auth admins or orgs, however you'd like to look at it, then there are accounts which are an alias for "project name" and then you have users, which are "client name"…

The 'auth callout' feature introduced in NATS 2.10 is there exactly for that (integrating NATS auth with whatever existing IdP system you already have): the client app passes whatever you use as it's credentials at connection time the server then passes them to the security callout service (something you write, following a template that receives whatever the client app passed as credentials and then works with whatever system you have to check those credentials and whatnot and then generates on the fly and returns to the servers equivalent NATS credentials which in turns uses them for that client connection. (https://github.com/nats-io/nats-architecture-and-design/blob...)

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

#70

Post by sofixa »

jitl wrote: post #63
sofixa wrote: post #45

Earlier quoted context omitted.

> NATS vs MQTT vs Kafka vs Redis Queue vs Amazon SQS - how do they all stack up I'm curious why are RabbitMQ and AMQP no longer part of such comparisons (not only your comment, nobody else on this thread has mentioned them).

At my past job RabbitMQ was an infrequent source of painful surprises. I think it's kinda like HAProxy, a venerable solution that's well known but being replaced in new work more trendy implementations of the same kind of thing.

Interesting, at my past job we used RabbitMQ at decent scale and it was rock solid once the initial kinks around scaling were ironed out (there weren't enough resources for the amount of messages that were thrown at it).
Post reply on HN