Organization of the Lambda functions

With a REST API, there are a few options you have as to how each API endpoint maps to a function. The primary options in this design are whether to have a single Lambda function handle a single HTTP verb/resource combination, or whether to have a single lambda function handle all HTTP verbs for a particular resource. It should become more evident as we work through this chapter that Lambda function organization and application code organization are related, but not the same:

In the preceding diagram, we see a possible Lambda function layout for a REST API. On the left, unique functions handle a unique CRUD event and resource combination. On the right, Lambda functions perform actions on a single resource but with different actions (create, read, update, or delete).With the first model (left side of the diagram), each REST endpoint is mapped to a single Lambda function. This design provides fine-grained control for updating functions, allowing for the deployment of a single API endpoint without the danger of inadvertently affecting other APIs.

The major downside is that this may quickly become unwieldy as the API grows. Imagine the case of an API with 20 resources (session, user, and so on), each with three to four actions / HTTP verbs. If you follow this scenario through with some basic multiplication, the quick growth of the Lambda functions that you'll need to manage and navigate will become obvious.

With the next design, logical groups of REST endpoints are grouped and triggered, in effect the main function that routes the request to the appropriate handler. If you imagine the simple case of listing sessions from this API, an HTTP GET would come into the /session endpoint, which would trigger the handle_sessions() function. As a part of this payload, our application code would know that a GET method was invoked and would then invoke a get_sessions() function, perhaps the same as in the previous design. The significant benefit of this architecture is that the number of Lambda functions is drastically reduced over the previous design. The downside is that deploying updates affects all REST endpoints, which are handled by a single function. However, this may also be a benefit. If there were a bug in some shared code that affected all /session/{id} endpoints (GET, PUT, and DELETE), we'd only need to update a single function to fix them all. With the previous design, we would need to update three functions individually.

For this chapter, we will use the grouped design so that we have a single Lambda function for groups of REST endpoints. Each group will share a common URL pattern, and the HTTP verb will be used to trigger different functions within the application code.