Building Serverless Applications with Google Cloud Run

Chapter 5. Working with HTTP Sessions

User-facing web applications generally use HTTP sessions to make the experience unique for every user. If you have ever built a web application, it’s likely you have worked with HTTP sessions before.

On a traditional server, you might have been storing session data with local files or in memory since this is the default for a lot of web frameworks. While this will superficially seem to work on Cloud Run, it’s not very reliable. A Cloud Run container is disposable. It can disappear when it is not used, leading you to lose session data and stopping sessions mid-flight.

Examples of session data include the authentication status (logged in or not) and short-lived intermediate states, such as the contents of a form the user is filling in but that still has errors, or a status message the user needs to see but that can be deleted after (“flash message”).

If you’re not saving session data on the containers themselves, you need to persist it somewhere else. A common choice is to use Redis, a low-latency key-value store with the capacity to handle a lot of concurrent connections. I’ll show you how to use Memorystore, which is a product on Google Cloud that manages Redis for you. There are alternatives to Memorystore: Firestore and Cloud SQL. I compare them at the end of the chapter.

Even if your primary use case is building stateless APIs (those that don’t use HTTP sessions), this chapter is still useful for you to read because it shows how to connect ...