Is it possible to use with NATS RPC
kulak opened this issue · 2 comments
I am using NATS RPC project to simplify development of services:
https://github.com/nats-rpc/nrpc
Is there a way to use Resgate project with NRPC NATS communication model?
I'd prefer Resgate to manual mapping.
From a quick look at NRPC:
- Primarily for service-to-service communication (but may allow client-to-service communication over an nrpc specific gateway)
- Uses protobuf encoding
- RPC only (well, it is in the name :) )
Compared with Resgate:
- Primarily for client-to-service communication
- Uses JSON encoding
- Live resources + RPC (through the call requests)
The reason why Resgate is using JSON instead of Protobuf is (primarily) because it needs to be able to decode responses and events to populate and update its cache, without having to configure it with .proto files for each time a service changes.
I can see a few alternative answers to your question.
Have Resgate act as an NRPC gateway
Description
The (web)client connects to Resgate and makes requests either over WebSocket or HTTP. Resgate would turn it into an NRPC request over NATS, and then relay the response back to the client.
Conclusion
No. An NRPC specific gateway is the way to go in such a case. Resgate does this already with the JSON based RES protocol, but it would require quite a lot to add NRPC to it.
Use NRPC for internal and Resgate for external
Description
Service-to-service would go over NRPC while client-to-service requests comes over Resgate.
Conclusion
Yes. This should be doable. It shouldn't be too hard writing a Middleware for go-res that wraps nrpc methods to Resgate resource methods. But is it really a good idea to have a service expose the same API with two different protocols? Maybe.
Use RES protocol for both internal and external
Description
By dropping NRPC and use RES protocol for both service-to-service and client-to-service communication. This was not part of the question, but worth mentioning.
Conclusion
Yes, but not yet. You get some overhead of using JSON over Protobuf, and you lose the static checks of protobuf, but would gain things like client-to-service, live resources, and access control.
However, the go-res package still lacks service-to-service support, and in the roadmap it isn't planned until 2020 - Q1.
Thank you. Great response.