API Gateway adapter?

[mmkal]

Would you be open to adding an API Gateway adapter? I haven't dived in deeply enough to the express and standalone ones to know exactly what it'd entail, but here's our current approach:

import * as trpc from '@trpc/server'
import * as trpcExpress from '@trpc/server/adapters/express'
import {z} from 'zod'
import serverless from 'serverless-http'
import express from 'express'

const appRouter = trpc.router<{foo: string}>().query('getUser', {
  input: z.string(),
  async resolve(req) {
    return {id: req.input, name: 'Bilbo', now: Date.now()}
  },
})

export const app = express()

app.use(
  trpcExpress.createExpressMiddleware({
    router: appRouter,
    createContext: () => ({foo: 'bar'}),
  }),
)

export const handler = serverless(app)

export type AppRouter = typeof appRouter

Which is fine, but we're relying on the serverless-http library to do all the magic hacks that make our entire backend work. And it doesn't feel right that we need express and serverless-http as prod dependencies at all, since API Gateway lambdas are actually already kind of closer to what trpc/server does in the first place, I think (just functions that take inputs and return promise outputs, rather than weird res.status(...).send(...) side-effects). How I imagine it could look:

import * as trpc from '@trpc/server'
import * as trpcApiGateway from '@trpc/server/adapters/apiGateway'
import {z} from 'zod'

const appRouter = trpc.router<{foo: string}>().query('getUser', {
  input: z.string(),
  async resolve(req) {
    return {id: req.input, name: 'Bilbo', now: Date.now()}
  },
})

export const handler = trpcApiGateway.createApiGatewayHandler({
  router: appRouter,
  createContext: () => ({foo: 'bar'}),
})

export type AppRouter = typeof appRouter

So I think it fits pretty neatly in alongside the other adapters. A simple API Gateway handler looks something like:

export const handler = async event => {
  return {
    statusCode: 200,
    headers: {'x-foo': 'bar'},
    body: JSON.stringify({
      result: `Hello ${event.queryStringParameters.abc} ${event.body.def}`,
    }),
  }
}

[KATT]

This would be a great addition to the adapters! I was talking to a company that would want a very similar thing, I think - @thisdotrob, can you share what you ended up with?

You can use trpc.createHttpHandler straight off - see example code here: #655 (comment).

If you want to add an official adapter, you can like at the next.js one for a reference implementation. Also happy to jump on a call and talk through the codebase if you're interested in contributing.

[Lilja]

I found this project today and I am very excited to try this. I believe for my own use case running something like this on AWS lambda would be beneficial for me and my project.

I had a look into creating a handler that would work for an AWS lambda, I spent about an hour. Perhaps this is common knowledge but I'd thought I would just share my findings.

src/http/requestHandler#requestHandler() is very "hard-coded" in a way that it just works for http.IncomingMessage for req and http.ServerResponse for res. I don't know if you Alex have done something with a lambda before, but you usually get an input that looks like this.

It's hard to create a BaseRequst object from scratch, since it doesn't have properties like socket, connection. I guess you could mock some of these but I don't think that it's stellar design to solve that kind of problem.

It would be amazing if there was a way to query/run that handler with less "raw" input parameters. For example, being able to run requestHandler with something like

export function createApiGatewayHandler<TRouter extends AnyRouter>(
  opts: CreateApiGatewayContextOptions<TRouter>,
) {
  return async (event: APIGatewayProxyEvent) => {
    const req = {
      body: event.body,
      method: event.httpMethod,
      query: event.queryStringParameters,
      headers: event.headers,
    };
    const path = event.path;
    return await requestHandler({
      ...opts,
      req: req as BaseRequest,
      path,
    });
  };
}

and then somehow let the adapter handle the response with json-body, headers and what not.

[KATT]

Tjena @Lilja!

I've added you as a contributor and started a branch on refactoring the http internals to make this easier.

See #880 - it's still really messy, but the idea is there. Feel free to pick that branch up and finish it, I won't have time to work on it more for a week or so.

[Lilja]

Morsning korsning!

The work on the branch is very much appreciated, I like what I see so far. I can definitely see how I can implement it further.