I am looking for ways to get around this issue. My Serverless project is 95% API Gateway endpoints, and they all point to one router lambda function. I have ~80 different methods defined so far in total, and this error occurred when I reached that amount.
I understand that this is a CloudFormation limit, and not a limit of the framework, per se, but I am not sure how to get around this obstacle. Each resource has a unique template that lets the single lambda function which table to use in the database, as well as some other info that tells it which fields on the body are required or not. I think this is the primary reason that my CloudFormation template has got so large so quickly.
An option that I found was to divide my single Serverless project into multiple projects, and then have them reference each other when needed. This would be an ideal solution, except for the fact that I need all of my API endpoints in the same API, and as far as I know, there is no way to have multiple Serverless projects reference the same API Gateway.
Each resource has a unique template that lets the single lambda function which table to use in the database, as well as some other info that tells it which fields on the body are required or not.
The easiest solution is probably to simplify the routing at the API GW by moving some of the config/routing into the Lambda
Doesn’t the first solution you provided only make the api’s appear to be combined? The plugin describes setting up a custom URL to assign each API gateway to a subsection of, this doesn’t exactly solve the issue of keeping them together. Unless it’s doing something else that I’m not aware of, that doesn’t seem like it actually solves the problem.
Each CORS configuration for an endpoint, adds another Stack to your set, so your effective size will be N number of endpoints * 2, + whatever else you have going on.
So you really have 2 options in front of you.
Break your code up so that groups of endpoints are facilitated by a single function. Usually this is done around a logical resource path. /users is one function, /accounts is another.
If you don’t want to break up your application into microservices then you will have to look at a different cloud provider. They may treat the structure differently and your deployment will no longer hit the account limits.
This is the reason why we are still on 0.5.6 of serverless framework, where these limits were never reached. We tried to upgrade to 1.x but these limitations prevented us from using it, which is a real shame. I am hoping that one day some other solution will be made available to allow us to upgrade.
I have decided to go with a different approach than Serverless for API definintions. I am using Swagger to define my endpoints, and then run a node script that assembles and uploads the swagger to my API. This way, I have 2 MB of template that I can use instead of being limited by CloudFormation sizes.