The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Jez Nicholson (14) [Avatar] Offline
I am undecided on how to structure my project. I am building an API Gateway + SNS + Lambda + DynamoDB for a server for a mobile game.

I have all of my core api Lambda functions in a single repo, with a single function per operation....getPlayer, setPlayer, putRun, etc. which are then mapped to API Gateway. All is well and good. Nice and atomic.

However, I am undecided whether to have a folder for each function with its own serverless.yml definition, or to group all of the functions into a single serverless.yml

Having multiple serverless definitions gives the benefit of tight control over exactly what the function does. It also makes each function completely standalone.

A single serverless.yml looks like the permissions will be applied to all functions. Probably not a big deal because they are all my DynamoDB tables.

Also, for a single serverless.yml I would be including all packages and libs with every function. Again, maybe not so bad if all the functions are similar (talking to DynamoDB) and there isn't one the has a massive C library in it.

One pitfall of multiple is that to share the same tree in the API Gateway I have to tell Serverless the ids of existing nodes e.g.

restApiId: 112otrmfkl
restApiRootResourceId: 11zu1p7gth
'/players': g6uny7
'/players/{playerId}': cirtdp

Any more single vs multiple pros and cons?

In the future, will having a single definition mean that I release new versions of every function every time I change one of them?
Yan Cui (73) [Avatar] Offline
Hi Jez,

By having separate serverless.yml files, did you mean that you'll still refer them in the main serverless.yml for the repo? Otherwise you'll have to deploy each function with "sls deploy" separately, which as you pointed out, requires hacks to get them to share the same CF resource, which is environment specific so you'll run into maintenance headaches when having to deploy to multiple stages or regions.

And yes, having a single serverless.yml file means you deploy everything in one go when you run 'sls deploy'. Although, you do have the option to deploy functions individually too, with 'sls deploy -f funcName'.

Instead, I think the better way to go is:
* use the serverless-iam-roles-per-function plugin to assign per function policy:
* enable per function packaging option, and set up include & exclude for each function if necessary:

One reason to split up the serverless.yml file is to avoid this 400-line limit, which I wasn't even aware until I heard about it from Ana at JeffConf last week, she has a couple of other good ones to watch one for too, check out her slides:
Jez Nicholson (14) [Avatar] Offline
My separate serverless.ymls are indeed completely independent of each other. They just happen to be held in the same repo in different folders. And yes, that API Gateway hack sucks! I could conceivably get CI to run multiple sls deploys....but I think that I will look at the plugins, thank you.