dougmoscrop / serverless-http

Use your existing middleware framework (e.g. Express, Koa) in AWS Lambda 🎉
Other
1.72k stars 166 forks source link

Support for multiple lambdas per express app #147

Open lucas-rudd opened 4 years ago

lucas-rudd commented 4 years ago

I'm very interested in using serverless-http for an application. However, it seems as though, when using this plugin, we will only able to deploy a single lambda to handles all of our routes.

There are two things that concern me with this architecture.

1: Due to the way serverless functions operate, there is a cold-start time when spinning up new containers. Because only one lambda is handling all requests, it's likely that it will increase the number of cold-starts than would occur with one lambda per method.

2: This requires all the application code in a project to be uploaded to a single function. There are limits that Cloud Providers place on the amount of code you can upload to a single function in their environment.

Some back-end projects utilize webpack to do tree-shaking and reduce the overall size of the deployment when using serverless framework. Others include/exclude files on a per function basis to leave out unnecessary files; however, because a single function has the code for all routes, the optimization that can be done is severely limited, leading to bloated function sizes. It's foreseeable that this could lead to the deployment limit being exceeded and the project being unable to be deployed. This is especially true for functions bundled together with node_modules.

This plugin has a variety of values, and we'd like to make use of it so that we have the flexibility to switch from a serverless architecture to a traditional server architecture if necessary.

Is there any way to allow for the ability to split out the express application and deploy multiple functions based on the route rather than a single function?

So, instead of having your severless.yml file looking like this:

functions:
  app: 
    handler: handler.handler
    events: 
      - http:
          path: GET
          method: /users

It would look like this

functions:
  get: 
    handler: handler.handler.get
    events: 
      - http:
          path: GET
          method: /users
  post:
    handler: handler.handler.post
    events:
      - http:
           path: POST
           method: /users
ghostd commented 4 years ago

Hi,

The documentation mentions thislib can call several function: https://github.com/dougmoscrop/serverless-http/blob/master/docs/EXAMPLES.md#multiple-functionsresources

Does it fit your needs?

dougmoscrop commented 4 years ago

Nothing stops you from deploying multiple Lambdas, each using serverless-http, each importing their own application, but translating that to a server architecture would mean multiple processes or some kind of entrypoint that mounts your sub-applications as middleware -- which is all fine and normal. There's definitely nothing here preventing any of that.

However:

1: Due to the way serverless functions operate, there is a cold-start time when spinning up new containers. Because only one lambda is handling all requests, it's likely that it will increase the number of cold-starts than would occur with one lambda per method.

One Lambda is not handling all requests, one Lambda is handling a request at a given time, and more will be spun up. Having multiple Lambda functions for your API can actually make cold starts worse, because you have a larger surface area - first a GET is cold, then a POST is cold, and so on.

It's true functions can get quite large, at that point you have to decide if you want to find alternatives to organizing your system, more like "services".