Fastify integration via plugin rather than sideloaded server

[zackdotcomputer]

Describe the feature

(I wanted to open an issue to get a sense of how open you would be to this before diving in and working on a PR - opinions welcome)

I was doing a small project where I wanted to get ORPC set up. I've been really pleased with how flexible it is and happy to work with it instead of TRPC for a bit. However, I'm integrating ORPC into an existing Fastify server and am already using Middleware at the Fastify level to handle things like security and auth. Because of that, the suggested Fastify integration pathway of adding in ORPC as a side-loaded Node server before the rest of the Fastify application was undesirable. It would mean I would need to replicate the functionality of the Fastify middleware I'm using as ORPC plugins.

In experimenting with this, I found three potential paths forward that would allow ORPC to be set up as a Fastify plugin instead:

1. Disable Fastify's request content parsing on the paths covered by ORPC. In some light experimentation, this appears to work just as one would hope for simple request/responses, but I haven't tried it in more advanced cases like file upload or streaming requests. However, I think the theory here is sound because AFAICT the issue currently is that the Fastify content parsing step consumes the request's body stream, leaving nothing for ORPC to parse on its end. (I think this would be primarily a documentation change for the website to inform people how to do this and the trade-offs.)
2. Write a FastifyHandler class that lives alongside the existing ORPC Handler adapters. I am moving forward with this option in my own code and would be happy to work on productionizing it back into the ORPC repo if desired. Again, while I have already demonstrated locally that this works in more cases than I bothered to with option (1), I suspect there are edge cases in the feature set of ORPC which this won't handle.
3. Combine these approaches into a full FastifyPlugin which could be registered against Fastify directly and which would disable content decoders, add new ones, and use the FastifyHandler internally.

I am going to move forward at least for my own project towards option (3). I'm opening this issue to get a sense of whether a tighter integration with a specific vendor/platform like this is something you'd like contributed to the ORPC repo, or if this is something you consider a "user-led solution" which should exist as an external tool? And if it is something which should get contributed back, should it look like solutions 1, 2, or 3?

Thanks!

Additional information

• Would you be willing to help implement this feature?

[unnoq]

Thanks for your interest in oRPC, @zackdotcomputer!

1. I think your approach should work fine - though it won't integrate perfectly with some of Fastify's built-in features (like cookies and headers). but oRPC cookie/headers plugin still work (see related: cookies/headers does not work in NestJS (Fastify Adapter Only) #992).

2. & 3 To be honest, I don't know Fastify deeply enough. I've never figured out how to properly reuse the current Node adapter with it. From what I've seen, not many people are running oRPC with Fastify today. So my focus has been elsewhere.

Luckly, oRPC is designed to be easy to extend. If you'd like to build your own adapter, you can start from the existing Node handler and just replace the pieces you need: https://github.com/unnoq/orpc/blob/main/packages/server/src/adapters/node/handler.ts