Compared to HTTP/REST I miss the debugabilty of it. Since all messages are sent over websocket and received, in binary form, since there is no support from Chrome or Firefox, one has to tediously manually extract the json payload and try to make sense of it.
Jetstream is still quite the mystery. It just doesn't want to work the way I want it to, especially on the JS client side, blocking script execution and timing out.
Then there's auth, after a few shutdowns and reboots I got locked out of my local installation. Oidc subject to nats user mapping doesn't exist and has to be done manually.
So TL;DR the core functionality is great. Everything else seems to be WIP.
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.
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"s. And that's fine for their infrastructure only. The problem is, in the real world you have an external identity service (OIDC, IAM,...) and the JWT this service creates includes a subject, but the NATS auth system has no support for external bridges. Also you have to decide, would you like to use operator/account/user or single JWT, or passphrase or manually managed user/password accounts? In a professional world, you'd have various customer applications each divided by their operators, accounts and users. And then fine grained user capabilities.. headache time.
So what you have to do is distribute a default user certificate with a client (client meaning actual client in the client/server sense), then do the signin/sso process and have some middleware checking this token from the OIDC auth process and check is a user with this subject exists, if not, create a new user and cert and send that cert back to the client which will then create a new connection with the new certificate.
Very complicated.
The initial default client certificate is required for "logging in" via NATS. I guess it could be a standalone program, the oidc to nats user mapper/manager.
So compared to HTTP/REST, more work involved.