Monorepo organization: Single serverless file or 1 per lambda?

Serverless Framework
, ,
1

Hi there.
I’m new to serverless, serverless framework and AWS too, so I’m sorry if something isn’t clear.

I was building a service on AWS in a monorepo (node.js + lerna) with some lambdas and I’m reading all around the web people organizing their projects and serverless files in different ways, but I haven’t figured out which would be the best way to do so (at least for my case).

I’m creating a series of lambdas (let’s say 2) and an API Gateway to serve some end points.
I have a couple of shared resources: a DynamoDB and an SQS queue to invoke one of the two lambdas.
All of this is made with a monorepo (node.js) and a series of packages, some of which are shared among the lambdas and some of which aren’t.
I’m now seeing two possible ways to organize the serverless configuration, both of which have their downsides:

  1. Every lambda has it’s own serverless.yml file. Maybe there are some shared yaml file to avoid duplicating some configurations.

Example:

PROS:

  • Faster deployment (I can deploy a single lambda whenever I want)
  • I can easily run serverless-offline and serverless-offline-sqs plugins in the related lambdas, and debug with them.

CONS:

  • I don’t have a single CloudFormation stack, but everything is disconnected from the rest… leading to possible inconsistencies.
  • I still have to duplicate the usage of those configurations inside the serverless files
  1. Have a common serverless.yml file in the root folder. This common serverless is the one used to deploy. Other yaml files can be used for configurations and/or for declaring the function specification. They are all referenced in the common serverless file.

Example:

PROS:

  • Single CloudFormation stack.
  • Very easy to read serverless file too: all my stack is in that same serverless file. I don’t have to duplicate the root definition of the serverless file for every lambda.
  • Actually can deploy single lambda here too with sls deploy function (actually this should only be used when developing).

CONS:

  • Can’t figure out how am I supposed to run in the single lambda serverless-offline and serverless-offline-sqs. I can only run it from the root folder, since the only serverless file is out of the other packages, but running the debug from out of the packages looks so bad compared to running it inside a single package/lambda.

To wrap it up I guess the question still is:
Do I have a single serverless file in the root folder (and optionally some configuration yaml files here and there) or do I keep them separate for each lambda?
Also, is there a way to avoid those CONS I talked about?
And finally, since you guys definitely know more than me, am I missing something else that should lead me towards one way or the other? (or maybe a third option I’ve completely missed)

Thank you guys in advance for your time and your patience in reading this far.

1 Like
2

curious as to what you ended up doing, and how you structured it. I’m struggling with same scenario, and how to handle common configuration. Referencing parent serverless.yml doesn’t seem to work consistently, and I still have to declare pretty much the entire configuration in the child anyway, so not realizing much of a benefit. I tried using the …parent… plugin, and that did nothing at all. I was hoping to find a definitive answer for recommended best practices on this, but seems like I’m coming up with a ton of semi different approaches, none of which I can seem to get working lol.

1 Like
3

I’d suggest spliting your project to smaller services.
Each service should contain serveral lambdas that relate to each other. Something like this:

/config # for common yml configurations
/users # would contain a serverless.yml with user lambdas
/events # same for events
/items # and items
/…

This will be less tedious as configuring an entire stack per lambda, but not as messy as throwing everything into 1 file