laconia
laconia copied to clipboard
Handling multiple endpoints (fat Lambda) with adapter-api
Apologies if this has already been asked/requested.
Is your feature request related to a problem? Please describe. Not directly related to a problem, but there are a lot of fat Lambda (for the term: https://theburningmonk.com/2020/07/are-lambda-to-lambda-calls-really-so-bad/) projects out there. And it would be nice to handle them without resorting to something like Express or similar.
Describe the solution you'd like Basically, I would like to pass in functions that handle specific endpoints. So something like this
// other setup
function handleGetPuppy(event) { // lambda event is passed into the function
// ...
}
apigateway({
functionMappings: {
'/puppy': {
GET: handleGetPuppy,
},
// more mappings
}
});
Additional context If the request is acceptable but no-one has time to take a swing at it, I can try to take a look myself and open a PR.
Welcome @VanOvermeire, and thanks for raising this issue. I'm not sure if the link is pointing to an explanation of what a fat lambda is. In terms of your use case, my thoughts at the moment are it might be easier if you create a separated function for the routing. This way each of the route will be able to have its own adapter logic (whether it's params or body or etc).
adapterApi.routing({
'/puppy': adapterApi.apigateway() // existing functionality
})
One thing that we would love to do in Laconia is to make sure that we encourage good practice. I haven't been following the recent movement, is fat lambda the encouraged practice now?
@all-contributors please add @VanOvermeire for ideas
@ceilfors Sorry if the link was not clear. Fat lambdas are one name (monolithic is also used?) for when you have a single lambda handling multiple endpoints. So wildcard in your (Cloudformation) infra setup and routing within that one Lambda to send stuff to the right place.
It is considered a valid choice when you have a lot of endpoints because your infra would become very complicated if you add one lambda per endpoint (plus, deploy times would increase since you have more to deploy to). The downside is obviously the size of the lambda zip (hence the fat and monolithic terms).
Regarding your code comment, yeah it does make sense that certain routes will use params while others will have a body.
That's cool, I certainly have experienced that downside. I don't think that I'll be able to take a swing on this, so I really appreciate that you'll be having a look into this yourself. I'd recommend designing the API first by testing it in your codebase (the API design is always the tricky part). Given that we are thinking about separating the responsibility by doing the adapterApi.routing(
, the code should be fairly decoupled and you can open the pull request after.
Closing this for now as the associated PR was closed. Feel free to re-open if there's still interest in this functionality!