If I have two services, 'Users' and 'Products', each with several functions with endpoints defined for each one (as any traditional API would), is it possible for them to be organised separately in a code base (for clarity) but once deployed share the same API base URL? For example, consider I have the following structure:
/src
-- /users
---- event.json
---- handler.js
---- serverless.yml
-- /products
---- event.json
---- handler.js
---- serverless.yml
and my src/users/serverless.yml has the following defined:
functions:
create:
handler: handler.create
events:
- http: POST user
read:
handler: handler.read
events:
- http: GET user
and my src/products/serverless.yml has basically the same thing, just swap 'user' for 'products'.
Currently, both of those services will be deployed to distinctly different API endpoints, one with a URL https://fghijklmnop.execute-api... and another with a URL https://abcdevwxyz.execute-api....
My question is, would it be possible to have these services be deployed but remain under a single API with a single URL (so both would be served under URL https://abcdevwxyz.execute-api....)?
I'm assuming the answer to be, 'No, because Cloud Formation...', but I thought I would post the question here simply for the sake of discussion and to aid my own understanding of building serverless applications.
I'm aware of using Custom Domains, as per the answer here, but for a quicker development cycle this is not really an ideal solution.
My only solution so far would be to simply create a service called 'api' which would contain all the endpoints my API would need which would simply invoke my other services' Lambda functions directly rather than via previously-configured endpoints. It would be an abstraction layer, really, but add potentially unnecessary layers to my application. Again, curious to see what the community feels on this.
I came up with my own solution to this problem. I abstracted the integration points of my application so that I have specific Integration services (API, S3, SNS, etc.) which respond to events and then process those events and delegate them to separate microservices. I wrote an article on it, with code examples.