{{ message }}
Repository navigation
[Feature Request]: TCP Transport Adapter for server to server communication (mainly for microservices) #729
Description
I created similar issue for tRPC here -> trpc/trpc#5995
It needs financial investment which is understandable.
Also in that issue I attached simplified example for using TCP with tRPC.
I believe people who use something like gRPC for microservices communication can benefit from such adapter.
Activity
dinwwwh commentedon Jul 5, 2025
Just take a look at your mvp, it feels very like current oRPC
peer adapterdoes:oRPC
peer adaptercan use for any things that support transfer text or binary +clientshould (not required) long live connectionI just wonder, is
websocketis not enough for this kind of communication?valerii15298 commentedon Jul 5, 2025
I think mostly yes.
Websocket is initialized still over http and has some overhead comparing to raw tcp but then you would need to implement custom framing/[de]serialization when using raw tcp.
Nest.js for example has tcp option: https://medium.com/@issam.eddine.bouhoush/microservices-with-nestjs-setting-up-an-architecture-with-tcp-protocol-b505b2e54b98 - I was using similar approach to this in one of my company projects.
But it is another question they implemented framing/serialization stuff etc...
That is where this idea came from. Nest js has multiple transport layers which you can configure: https://docs.nestjs.com/microservices/basics one of which is TCP.
Now looking at Nest.js transport layers abstraction I think it is interesting pattern in general.
Let's say you have two oRPC servers which need to communicate with one another. And you use usual routers procedures, etc.
And then at any time you can change transport layer from websocket to tcp to redis to rabbitmq to anything similarly how nest.js does. Could be compelling feature to some people I guess.
If oRPC is transport agnostic and has API/docs for making custom transport adapters then it is possible to add such adapters at any time. And oRPC will become more and more as alternative to something like Nest.js.
Does it make sense to add such adapters?
Will be there target audience and people who will consider using oRPC instead of Nest.js for such feature?
Do we want for oRPC to try to be alternative to something like Nest.js?
These are questions I do not have answers for...
For me personally I do not have a need for it at the moment(maybe will need in the future though). I no longer work on that project where I needed server to server communication, but at that time such functionality would have been extremely useful and we could have decided to use oRPC instead of Nest(oRPC did not exist back then though).
So these points are mainly just ideas depending on which direction oRPC is targeted to grow.
Now that Nest.js is bit of legacy old bloated project(my subjective opinion - they did not migrated to ESM yet), there seems to be free space for modern alternative to Nest.
dinwwwh commentedon Jul 5, 2025
I definitely want to support this. Most of the work is already done with standard-server-peer, so I'll just need to review the communication layers. Creating custom [de]serialization for TCP isn't a problem at all. But after looking at Redis, RabbitMQ, etc. I started thinking about how I can support more with less effort.
dinwwwh commentedon Jul 6, 2025
Here my simple implement for oRPC working with all features (event iterator, file upload/download): https://github.com/unnoq/orpc-tcp-playground
dinwwwh commentedon Jul 4, 2026
With built-in WebSocket reconnection support in v2, I think we can just use WebSockets for internal communication.