EP07: Going off piste; KV patterns with NATS.io (pt1)

Now that we have v2.10 of the nats-server released, it's time to discuss what we can do with NATS. We start by discussing patterns that we can easily achieve with the KV store. Enjoy!
---
If you like this video, be sure to hit like and subscribe!
Want to suggest a topic? Find us on Twitter ( / nats_io , LinkedIn ( / nat.. , or Slack (slack.nats.io)!
Here are some useful links for NATS!
- Website - nats.io
- Examples - natsbyexample.com
- Docs - docs.nats.io
The home of the NATS team: synadia.com

[@thetooth]

Cool talk, I'm using regular pub/sub, as well as streaming and kv in a robotics project at the moment. The industrial and robotics industry is sleeping on nats, it's one of those ecosystems where people really like their de facto standard tools and don't like straying outside of what ROS or rockwell offer so you have a lot of old (but still good) tools and technology you need to rope together to get anything functional. Meanwhile my current PoC is just a bunch of microservices, with each consisting of >50% loc business logic per unit, and all the communication and data handling semantics offloaded to the nats server. Yes, the latency is measured in microseconds and there's no determinism guarantees which is a problem for some tasks, but overall the advantage of having a single data and control plane, that is for the most part platform and language agnostic, is great for productivity.

[@trashmail8]

Nice episode, many thanks and I'm already looking forward to the next episode?
Pattern/solution: would it be possible, or better, would it be a proper solution, to:
- Use a NATS K/V store as a distributed cache for e.g. JSON data that is refreshing only once in a while? (Instead of generating/request-replying it for every single request)?
- Use a protected/shielded NATS (cluster)'s K/V store important values like e.g. API tokens for your own environment or those of customers if such data is needed to call 3rd party applications. E.g. storing customer OAuth tokens. ?
And regarding the object store: how is the data actually stored? As in: if you are running a NATS cluster: how and WHERE is the object data actually stored? Is all object data replicated across all NATS instances? Or will it use some form of sharing? I have all kinds of potential ideas brewing, but I need the mental picture somewhat to be more complete to actually consider to actually use it.
NB. I really think this information is lacking from the, otherwise excellent, official NATS documentation!
Thank you once again. 🙏

[@SynadiaCommunications]

Very happy it was useful!
A KV store as a cache for values that are updated infrequently is a great use case. Clients can either choose to watch the store and receive real-time updates when the value changes per key or still opt for the on-demand request/reply interaction.
For managing sensitive data, there is nothing inherently in NATS than any other system that manages state. Given that NATS is multi-tenant, there is the option of isolating a KV bucket for this purpose within a specific account that has limited access.
Of course you have the option of encrypting the values before storing, ensuring that only clients having a private key can decrypt the value.
Regarding the object store, this is a client abstraction which chunks a large object into a sequence of order messages on a stream. As a result, it inherits all the properties of a stream, specifically replication and the option of creating mirrors, commonly used across regions or leafnodes.
100% the docs need improvement and there is a new docs site in the works which will make these concepts first class.
Thanks for feedback and questions, hopefully the answers were helpful!

[@trashmail8]

@@SynadiaCommunications Thank you very much for the extensive reply! It's definitely helpful.
" Given that NATS is multi-tenant, there is the option of isolating a KV bucket for this purpose within a specific account that has limited access."
That's a good point. When "thinking in NATS", to keep in mind that you can have different accounts with different permissions. So you can have a KV store permission with e.g. secrets that's only accessible by "finance endpoints/services" while you have other topics accessible by e.g. "webshop" endservices.
These kind of "solution patterns" are good things/use cases for these videos, but also for "how do I?" examples that would be very valuable to the online documentation
"Regarding the object store, this is a client abstraction which chunks a large object into a sequence of order messages on a stream. As a result, it inherits all the properties of a stream, specifically replication and the option of creating mirrors, commonly used across regions or leafnodes."
These inherited properties like the mirroring is very interesting and also something I overlooked because I need to extend my personal "thinking in NATS" solution library. ;-)
It's indeed about "Escaping the HTTP mindset" to mention an earlier episode name, but it's also about "Going beyond the HTTP mindset". The former can move you from POST/GET/etc.-land to Pub-Sub/Request-Reply land, but going beyond with KV and Object stores is opening up so much more of a new playing field.
But that also raises so many new questions because the borders of this playing field are still not fully clear.
What is a large object? 1 MB? 10 MB? Can I send 100 or even 1000 MB to an object store, where it gets chunked and distributed further to other nodes if there is a cluster configuration? Would NATS be able to deal with such a thing because according to the FAQ the max size of a message is 1 MB by default..
So for me personally, already loving NATS for so many reasons, I still find it difficult to design and commit to a more extensive architecture because I don't have enough feeling for where the potential walls are positioned. Am I not painting myself into a corner in certain cases, etc.
Hopefully this also sketches more or less what is still keeping my NATS solutions relatively simple so far. :)

[@holgerwinkelmann6219]

Nice Episode! David, as you come from the Network backgrounds, what about a distributed DHCP Server which hand out IPs for given Lease Time?

[@davedotdev-synadia]

That's a great use case! Networking is a whole untapped area right now. Could also be used to coordinate TE information across a fleet of devices, instead of some horrific vendor implemented solution. The KV is a perfect foundational block for that, especially with the watcher functionality.