Currently I have a monolithic gRPC server that implements several service stubs that are utilized by a large amount of internal client programs (none of this is public internet facing).

As our requirements have gotten more complex and more backends are being accessed by the monolithic gRPC server, I am looking to break them out in a more logical way. This would separate the single server into multiple servers that work with a particular backend, as opposed to one serer that rules them all.

The challenge I am facing is that I don't want to refactor each client to be aware of the specific server that is implementing its service.

I am looking at how others have solved this problem and I have looked at containerizing these applications and utilizing something like Kubernetes to handle the coordination and providing a gateway, but this seems like overkill for the scale of what we are working with. (We have a small development team and the additional overhead/cost of managing Kubernetes is not worth it).

Another thought was to create a gRPC Gateway from scratch that basically just forwards the requests/responses to the appropriate servers. But before I do that I wanted to see if anyone else had similar experiences?

1 Answer 1


Not sure if this should be an answer, or just a comment but here goes.

Internally, gRPC uses HTTP/2, and at least nginx supoprts being a reverse proxy in front of your server. The clients see a single server, while internally you split it up however you wish.

Searching for "gRPC reverse proxy" gives a number of hits for existing software, nginx is just the solution I am aware of.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.