Closed gedw99 closed 9 months ago
Ah this is interesting. I mostly use NATS for service-to-service stuff but I guess with nats.js coming along you probably could look to deliver your API directly via NATS instead of using an intermediate layer.
On a quick read it feels like enough NATS-specific or authorization-leaning stuff needed that I'd hesitate to add here but I'm a big enough NATS fan I'll keep it on my radar at least.
I will have a go at using it with this repo at runtime to see if it works in terms of sync aspects .
the Auth Server is really well done btw.
Yea it is I've become a huge fan over the last few years after spending a ton of time working on a bespoke SSO system earlier in my career. Having something battle tested and independently scalable to handle auth is a real lifesaver. Only done a little actual work in it but the code is clear and easy to understand when you need to dive in.
I'd love to see what you come up with for NATS,even if it doesn't get merged I could see myself using it. I know the backend APIs here pretty well and could probably put together decent administrative tooling more easily than with native NATS stuff. Don't have a solution in mind but one thing I'm wondering is how it might fit in with #111.
I am planning to add a nats admin GUI if that’s what you’re getting at. Will be built with html so it’s reactive .
also about that auth call-out issue there are 5 examples of how to do it with NATS here: https://natsbyexample.com/ This allows Authz-Server to integrate with NATS Jetstream. This configuration could be built into Authz-server GUI too
Also yes you can use nats.js in a web gui.
then nats server is acting as a geo load balance because the client will connect to the closest nats server and then via rpc to the nearest backend server.
https://github.com/lerenn/asyncapi-codegen Is what I use sometimes . It’s a code generator that conforms to the async-api spec. It’s like openapi but designed for bidirectional. Push to the client gets converted to a WS or SSE Call. I tend to use SSE as it’s crazy simple.
Examples are here : https://github.com/lerenn/cryptellation/tree/main/svc
Then htmx SSE extension can be used for the web page aspects. I am tempted to write a htmx-nats-js extension though like the existing one: https://htmx.org/extensions/server-sent-events/
code for SSE extension is decoupled too:
https://github.com/bigskysoftware/htmx/blob/master/src/ext/sse.js
it’s not really required . You can just hit the server and use the standard SSE extension . If you want Nats.js to do the load balancing then you have the Nats.js logic and so all the htmx data messages travel through the Nats nats message broker instead of directly to / from your server. Same of course goes for http pull which can just go through NATS broker.
Hope this is of interest in some ways
I noticed you used ego. It is pretty old but also simple. It can be made to use nats and htmx so that’s it’s also bidirectional to keep the gui up to date in terms of real time. The trick is to isolate the updates to view to the right users when data changes in the db. This is where sessions come into play. I have not grokked to see how you do sessions. Intend to keep session data inside Nats so that it’s scoped only to that user but available to all backend servers. Each backend server then can access the global session data. To have caching you just run a nats leaf server as part of each backend server .
Maybe this is interesting for your architecture. It’s a very nats centric way of doing this sort of scale out architecture and so not for everyone.
Nats team are formalising the jwt integration
Ah man this is great stuff. What I spend these days on is more traditional websocket based stuff but I definitely have my eye on this type of architecture if we make it to a "vnext" type of situation. If you are doing any of this in public or even semi-private let me know I'd love to help where I can even if just for demos. I can definitely help with anything authn-related and probably a lot of the NATS stuff too - been looking for a reason to get my hands dirty with nats.js especially. Generally its a lot of my interests converging here (if you added a tinygo client to the mix I might lose my mind 😅)
Regarding ego I'm pretty sure it's just for the status page that I've never looked at but probably should someday.
thanks and yes I will contact you to get a review of it.
https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_callout
It would make things easier when devs need to integrate with NATS for whatever they use NATS for ...