Support for NATS

[michaelsogos]

Do you like to add support for NATS also, like you did for gRPC?
It will be a killer feature for postman 😄

Actually we are migrating from Postman to Insomnia Designer because full of feature (to test API of course), and because GIT SYNC support (also because cheaper 😄).

We are working on an open source project based on NestJS framework with microservices driven by NATS, and it will be great if we can centralize also microservices tests into one amazing solution like Insomnia.

[nijikokun]

The next item that we have on the list for protocols is Websockets, which I believe is very similar to NATS? I'm wondering whether the gRPC UI would be viable for NATS? If so, it would be providing another network layer and the data model like exists for gRPC. Would be a good first network issue for someone looking to contribute!

[michaelsogos]

From my understanding NATS is not about HTTP protocol or derivated; so i don't guess it share nothing with WebSockets.
NATS has common feature with gRPC, but it is more than an RPC system.

Its main purpose is to coordinate and route messages from PUBLISHER to SUBSCRIBER like standard message queue systems providing also REQ/RES pattern (uncommon on MQ systems).

NATS implement raw own TCP protocol to send\receive data and it is extremely useful for implementing an microservice architecture.

Insomnia, even if a bit out of topic, could implement a client to PUBLISH or SUBSCRIBE (or just send request and wait for response like usual REST API) to a specfied topic\subject (like usual we do with URL for REST API).
Why? Because nobody care about testing microservices endpoints.

After i read about support for gRPC, i asked my self why not for NATS (or even Kafka, Rabbit, MQTT, etc.).
From logical points of view a test for REST API (or SOAP) is same as for MQ system, but instead use HTTP protocol there is another one.
Both needs an URL, an request BODY, in some case an HEADER (metadata), in some case an AUTHENTICATION and a client to show response (when used with REQ\RES pattern or simulated with two client one for PUBLISH and one for SUBSCRIBE based on what kind of test we need to do).
Again for testing purpose we need to check if the received message (no matter if it is a JSON or whatelse) match an assertion ("expect" in you case 😄 ), and how long (or how many bytes) the RPC call was.

Around the world we didn't found any client born with test in mind for MQ system and for who implement microservices architecture. That's why i guess you added support to gRPC and that's why i guess it can be a killer feature for your competitor (starting from Postman).

Try to image what Insomnia can become for developers around the world if you add support to different protocol than HTTP (or WS) 😄. Can we say a leader in the market ?!
Try to image how much it is so simple to implement (from logical point of view of course) starting from actual CORE.

In other words ...
... why not?

[nijikokun]

From my understanding NATS is not about HTTP protocol or derivated; so i don't guess it share nothing with WebSockets. NATS has common feature with gRPC, but it is more than an RPC system.

Absolutely, while there are some similarities to gRPC and it's a different application-layer protocol (both run over TCP), there is some similarities with WebSockets as well! Primarily PUB/SUB a two-way communication channel which has similarities to gRPC bi-directional as well.

Try to image what Insomnia can become for developers around the world if you add support to different protocol than HTTP (or WS) 😄.

Well said and that's definitely the direction we are headed! With gRPC we looked at how Insomnia could service these different application-layer protocols ways of making requests with an intuitive interface within Insomnia. I think we've hit a good middle-ground with the recent gRPC release and can leverage the same interface (client/bi-directional) for NATS, Kafka and WS (Pub/Sub).

Like you said, it's similar, just different way of sending under the hood ;)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.