Serverless - large app - serverless-framework

Question

I am new to serverless framework.
I am starting a Rest API that will have multiple routing, for example:
GET user/{userid}
POST user
GET account/{accountid}
POST account
Do I need 2 services - account + users?
What are the best practices? If 2 services then 2 serverless.yml? does any one have example for serverless large app?
Thanks everybody!

Answer 1

For your example it's enough to use one service (serverless.yml).
You can use one lambda in 1 service to handle users and accounts requests.
functions:
<your-function-name>:
handler: handler.execute
events:
- http:
path: /user/{userid}
method: get
- http:
method: post
path: /user
- http:
path: /account/{accountid}
method: get
- http:
method: post
path: /account
Or you can create 2 lambdas (one per entity)
functions:
user:
handler: userHandler.execute
events:
- http:
path: /user/{userid}
method: get
- http:
method: post
path: /user
account:
handler: accountHandler.execute
events:
- http:
path: /account/{accountid}
method: get
- http:
method: post
path: /account

Answer 2

It really depends on the architecture you want for your app.
Take a look here, I think it might help you decide what you want really want.
If you have a lot of endpoints at one point you might need 2 services, because you'll reach the resources limit. You can always set the pathmapping if you want to have one single url for your app.
resources:
Resources:
pathmapping:
Type: AWS::ApiGateway::BasePathMapping
Properties:
BasePath: <your base for this service>
DomainName: mydomain.com
RestApiId:
Ref: ApiGatewayRestApi
Stage: dev

Answer 3

In few words - as you wish.
Technically: you can aggregate several functions into one, and invoke specific one, base on event parameter attribute. Moreover - you can run express/koa server inside AWS lambdas (or other FaaS) without any pain.
+ as a bonus you can use ANY and {any+}:
events:
- http:
path: /foo
method: ANY
- http:
path: /foo/{any+}
method: ANY
But in general - depends on situation. If you invoke specific endpoint very often, then it's better to move it to separated lambda. If you know that bench of endpoints invoked seldom - it's better to aggregate them under one lambda. Especially if you use warm-up.

Answer 4

One thing I like about architecture is that there is no right answer, but the most suitable for your problem/situation. On top of that, best/good practices are a guideline to help you on all of that.
In my case, I added the complexity to the code so my CRUD paths are very simple.
cms/{entity} or cms/{entity}/{id}. Entity means my collection in my BackEnd, so I know which model to use.
Applying this to your question you would have something like:
GET {entity}/{userid}
POST {entity}
With this solution you don't have to create a function for each new entity you create in your DB. It also has the Open-Closed concept of the SOLID principles.