Moving Session State out of Lambda Functions
In this lesson, you will get familiar with resumable sessions and how to minimise coordination between different Lambda executions.
We'll cover the following...
Regardless of the application architecture, the session state can’t reside in Lambda functions; it has to go somewhere else.
The usual solution for fault-tolerant session state in three-tier applications would be to put it into some kind of distributed data grid. DynamoDB would fit well in this case. Each Lambda instance could read out the session state at the beginning of a request, and save it towards the end. This would make each function slower and increase the operational cost of the application significantly. It would also make the application more error-prone since a function might experience problems between updating the session state and returning the result to the client.
There is an alternative that makes the application significantly cheaper. In Chapter 8, you moved the gate-keeper responsibility out of the application business code layer to the platform. As a result, client code can talk directly to AWS resources using temporary access grants. Service resources (such as S3) can directly prevent the client from performing something it is not authorised to do. Keeping the workflow on the server-side is not really improving security. This means it is safe to move user workflows all the way to the client devices, and with them, move user session data ...