How to structure Fastify code for serverless APIs?

[dnafication]

You have already researched for similar issues?

I have read some discussions around making serverless support better in the future. (fastify/fastify#2746). There aren't much else in the discussions regarding AWS Lambda or Serverless in general.

What are you trying to achieve, or the steps to reproduce?

I have an existing REST API built with Express.js deployed to AWS Lambda using Serverless Framework. It is currently a monolith application i.e. API gateway proxies all requests to a single express route handler. It is easy to swap out express with Fastify and still get a tonne of performance improvement but I want to go a step further. I would like to implement single purpose (or at least common functionalities grouped into one) function that will expose a Fastify instance with its own set of plugins, schemas and routes. Would that be a good idea?

API Gateway
| -- /user/{proxy} --> userHandler 
| -- /products/{proxy} --> productHandler

Or have a Fastify monolith (structure below) where all routes are forwarded to Fastify App which when booted will load all schemas or plugins which may not be needed for the requested route? I really like the directory based routing which comes out of the box with fastify-autoload. Can something like that be implemented?

API Gateway
| -- /{proxy} --> Fastify app handler

Are there any example open source projects where Fastify is used in serverless environment effectively?

What was the result you received?

Not Tested

What did you expect?

Some sample code samples with guidelines of different types of code structuring approaches.

Context

• node version: 14
• fastify version: >=3
• os: Mac, Windows, AWS Lambda
• any other relevant information:

Please read this entire template before posting any issue. If you ignore these instructions
and post an issue here that does not follow the instructions, your issue might be closed,
locked, and assigned the missing discussion label.

[zekth]

The benefit of keeping one monolith is to be able to keep the function as warm as you can. Even if fastify is fast, the cold start is still one of our concerns.

Also, by having only one app, you'll just have one ci and ship process to handle. The drawback is if it fails it might take down the whole app and not just a handler; so be sure to properly test it.

For example one of my project is structured like so:

  # Routes and integrations
  integrations = {
    "ANY /wishlist/{proxy+}" = {
      lambda_arn             = // Specific built lamda
      payload_format_version = "2.0"
      timeout_milliseconds   = 12000
    }

    "ANY /{proxy+}" = {
      lambda_arn             = // fastify javascript lambda
      payload_format_version = "2.0"
      timeout_milliseconds   = 12000
    }
  }

In the previous example the specific built lambda is a function shipped as docker with still as fastify app but some low level dependencies shipped too. This makes the function run slower and consume more memory, but it's used only for specific usage; the rest is handled by a classic JS function.

Also you might want to take a look at this project to wrap your fastify app in a lambda function: https://github.com/fastify/aws-lambda-fastify

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.