NATS as a transport/protocol

[sourcec0de]

Introduction

Hello, aspiring contributor here. 👋
First off, thanks for the hard work!
I'm enjoying buf connect-web and connect-go.

I'm not sure if this is the correct place for this discussion.
Feel free to transition this ticket to a Github discussion instead of an issue.

Proposal

I am interested in adding NATs as a transport.

Here are some examples of gRPC/RPC over NATs in the wild.

1. nats-grpc
2. nrpc

What does this solve?

1. run gRPC services in private networks (no ingress)
2. bridge security constrained networks (span multiple private clouds/on-prem)

What I need to be successful

If adding NATS support is of interest, I would love to make this contribution.
I'm looking for some documentation around adding a new protocol/transport.
I initially thought to follow the pattern set by protocol_grpc.go and protocol_connect.go.
Please let me know if I'm looking in the right direction.

Diagram

NATS bread and butter is enabling this type of communication topology.

[akshayjshah]

Hi @sourcec0de! This works today - you don't need to do anything :)

protocol_connect.go and protocol_grpc.go define two different RPC protocols, but both depend on HTTP as the transport. To use NATS, you just need a library that wraps NATS with a net/http-compatible abstraction. Luckily, https://github.com/ripienaar/nats-roundtripper already exists. Waldemar Quevedo (@wallyqs) from the NATS team has a commit demonstrating how to get this working end-to-end with connect-go: wallyqs@2e744ec

[sourcec0de]

@wallyqs you're awesome!!!

@akshayjshah thank you for pointing this out!!!
This is EXACTLY what I was looking for.

With the example being so simple it might not be worth adding this to the package.
connect doesn't necessarily need to have NATS as a dependency in its go.mod.

🙇 thanks again!