Structuring a serverless application on a single domain with 40+ services and 150+ functions

Question

Currently working on a serverless application which utilises serverless-domain-manager to maintain our API under https://api.business.com The whole project is structured as a monorepo with microservices as suggested at serverless-stack.com. The main reason for this is code sharing between services, there is a lib directory contains 80% of the actual code (business logic) and the individual services map onto these lib helpers, think of user and admin APIs which do the same thing with more granular permissions.

There are currently 40~ services each of which has it's own base path on the API, for example 3 of the services are:

• Service user is api.business.com/user/
• Service users is api.business.com/users/
• Service product is api.business.com/product/

The problem is some of the services are getting a little heavy with 25+ individual functions in them. From my understanding you are suppose to keep these microservices as light as possible. If you think of the user service mentioned above, we have the following

• GET /user/profile
• PUT /user/profile
• GET /user/settings
• PUT /user/settings
• GET /user/notifications
• PUT /user/notifications
• GET /user/store
• GET /user/store/STORE_ID/products

You get the idea... it's been drastically simplified!

In the case of this user service, it feels like the case of users stores are the perfect candidate for a separate micro service user-stores, or even user-profile and user-settings etc. The problem is the serverless-domain-manager only supports a single 'word' as the basePath. So the API endpoint would change from /user/store/STORE_ID/products to /user-store/STORE_ID/products.

While perfectly possible, this feels like I'm losing the ability to clearly structure my APIs with the perfect tool, a /.

How have others managed to structure their larger applications in similar situation?

Answer 1

This isn't a direct answer, but have you looked into lambda layers? You may be able to separate all your libs into a layer which would simplify your overall project and keep things lean.

Is there any way you can avoid using the domain manager plugin?

Answer 2

This is an issue that I am facing too. The system that I am working with has 20 services, 1 lambda function per API endpoint, totalling 200+ lambda functions.

The total size of the lambda deployments is huge, and deployment takes a long time.

I came across a post on serverless architecture pattern, and the service pattern which groups multiple related endpoints to a single lambda function seems to be a viable option. This can help to reduce the lambda deployment size, but in return, there will be additional code and complexity in routing the request to the appropriate handler.

Lambda layer could be useful too, although I have not read up much on it. There is a sample project that demonstrates AWS lambda layers