Feat: Fastify adapter

[SeanCassiere]

Not particularly the cleanest implementation, but I got an adapter working for Fastify.

https://github.com/SeanCassiere/fastify-trpc-openapi-adapter/blob/master/src/fastify.ts.

Let me know what you think. It's definitely a bit jank since the types for Fastify's request and reply objects don't exactly overlap all the types in NodeHTTPRequest & NodeHTTPResponse.

[jlalmes]

Hi @SeanCassiere - thanks for this! We can add this fastify adapter to the trpc-openapi repo if you want to open an PR. Happy to work with you on this - we can use https://github.com/trpc/trpc/tree/main/packages/server/src/adapters/fastify as a battle tested pattern to follow.

[jlalmes]

I actually forgot to mention sachinraja/uttp when I wrote my earlier message. This could be a good solution - any thoughts?

[sachinraja]

@jlalmes I can try doing a PR with it if you want. I probably need to add some things before this package can use uttp anyway.

[SeanCassiere]

Sorry was out of sick for the last couple of days. Will get on this tomorrow.

As mentioned in your comment above, I'll match the pattern being used.

Any thoughts on the uttp thing? Or shall I do what I'm currently doing by remapping the request and reply the methods to match what is used by the Node HTTP service (https://github.com/SeanCassiere/fastify-trpc-openapi-adapter/blob/master/src/fastify.ts#L37-L42). @jlalmes

[jlalmes]

Hi @SeanCassiere, sorry for the super late reply!

Or shall I do what I'm currently doing by remapping the request and reply the methods to match what is used by the Node HTTP service

If you're still keen to work on this then I think this is the route we should take :)

[SeanCassiere]

Hi @jlalmes, no sweat, I should have followed up on this as well.

I'll get on it 👍🏼.

[SeanCassiere]

@jlalmes just for confirmation, as this is for the 1.0.0 release - #91, I'll be pulling a branch off of next and NOT master.

[SeanCassiere]

... the road so far

• Added the adapter in this branch.
• Added an example project, with tRPC, trpc-openapi, and swagger UI being set up in examples/with-fastify.
• For the time being, I've copied over the same tests being used for the Express adapter, and altered the set-up process to run them on a fastify server with the new fastify adapter (which they are passing all of them 😊).
• Added a super minimal set-up in the README.

[SeanCassiere]

@jlalmes in the testing of the fastify adapter, I've run into a blocker which requires more intimate knowledge on how the req and res objects are piped through the trpc-openapi plugin for the createContext function.

Scenarios

Please see the two scenarios below using Fastify:

1. Reading the headers in createContext

If I want to access the Authorization header using the @trpc/server/adapters/fastify plugin, I can access it using the following.

const createContext = async ({ req }: CreateFastifyContextOptions) => {
  console.log(req.headers.authorization);
  ...
}

However, in trpc-openapi, this is not possible since req.headers are undefined. As an alternative, the following has to be done to get to the header.

const createContext = async ({ req }: CreateFastifyContextOptions) => {
  console.log(req.raw.headers.authorization);
  ...
}

2. Settings headers in createContext

To set the x-request-id header with the @trpc/server/adapters/fastify plugin, it can be done using the following.

const createContext = async ({ res }: CreateFastifyContextOptions) => {
  const requestId = uuidv4();
  res.header('x-request-id', requestId);
  ...
}

However, in trpc-openapi, this is not possible since the res.header() function is not available, and instead the res.setHeader() has to be used.

const createContext = async ({ res }: CreateFastifyContextOptions) => {
  const requestId = uuidv4();
  res.setHeader('x-request-id', requestId);
  ...
}

Current fix/patch* in the createContext that works

Currently, in the createContext function, this can be worked around if you dropdown to using the raw objects stored in the req and res options.

const createContext = async ({ req, res }: CreateFastifyContextOptions) => {
  const requestId = uuidv4();
  res.raw.setHeader('x-request-id', requestId);
  if (req.raw.headers.authorization) {
    const user = jwt_decode(req.raw.headers.authorization);
  }
  ...
}

All-in-all, from what I can gather, the req and res objects being provided to the createContext function, are not the same as the ones being passed in for the primary tRPC fastify plugin.

[Asher-JH]

Hey @SeanCassiere, hows the blocker going? Would be awesome if we could use this fastify-adapter in an upcoming project soon. Anything I could help with maybe?

[SeanCassiere]

Hey @SeanCassiere, hows the blocker going? Would be awesome if we could use this fastify-adapter in an upcoming project soon. Anything I could help with maybe?

@Asher-JH, In it's current state the adapter is certainly usable, however, it wouldn't have the 'feel' of interacting with the first party Fastify Request and Response objects, rather you'd have to drop down to using the raw ones instead.

I've tried a few things to give it a shot, but I cannot understand why the Fastify methods are being stripped out when they arrive at the createContext function.

Need help from @jlalmes , as he's both the library author and quite a thorough understanding of how the official tRPC works.