Since this is the very first chapter that has application code and working examples, it's important to talk through some of the tooling and systems to set the stage for this and subsequent chapters. In this and the following chapters on web applications, our toolchain will consist of services from AWS:

• AWS API Gateway as the HTTP proxy
• AWS Lambda for computing
• AWS S3 for static file serving
• AWS CloudFront for the CDN
• AWS RDS for RDBMS management
• AWS Certificate Manager (ACM) for free certificate management

While AWS is the dominant player in the Platform as a service (PaaS) ecosystem, it is by no means the only choice. While reading this chapter and others in this book, remember that the patterns presented should apply to any cloud provider, albeit sometimes with a certain degree of adaptation.

You may be questioning the reasoning...

At first glance, a three-tier web application using a REST API can be an easy topic and pattern. After all, there are only three layers, which are responsible for very discrete tasks, and the final result is just a web application after all. However, there are many nuances and areas for tweaking with any web application. Serverless web applications are no different. This chapter will attempt to cover as many areas as possible, but it's impossible to include every possible configuration or design option.

Seeing as we are responsible software designers, let's sketch out our architecture at a high level and drill down into more detail as we work through the different layers:

This diagram should look familiar as it's the backbone of many client-server web applications out there today. Let's walk through the different layers, going from the...

Application code is likely the area of most interest and the layer that has the most changes from a traditional web application hosted on a managed server, so let's start with that.

Let's differentiate two classifications of our organization for the logical layer:

• Organization of the Lambda functions themselves, within AWS
• Organization of the application code

Lambda functions are the unit of work in Lambda and other FaaS providers (for simplicity and clarity, I will refer to these as Lambda functions from here on out). A single Lambda function may be updated or deployed in isolation without affecting other Lambda functions.

Presentation layers are not necessarily the most exciting area but, in reality, they are the entry point for your entire web application, and you should think through the details carefully. Naive deployments of HTML, CSS, and JavaScript files may result in slow load times, which has a noticeable impact on user experience.

When building serverless systems on top of AWS, there are a few different services that enable us to host static assets quite easily. Other PaaS systems have similar offerings, although there may not be a one-to-one comparison with all of the AWS services.

Any frontend assets need a filesystem as a home. In this case, the natural choice is AWS Simple Storage Service...

It's safe to say that most web applications today have some data store, whether it's a relational database (PostgreSQL, MySQL, SQLServer, and so on), a non-relational database (MongoDB, Redis, Cassandra, and so on), or even static file storage (S3, OS filesystem, and so on).

AWS RDS service will manage a PostgreSQL database for our coffee cupping application. RDS offers different RDBMS choices, most notably PostgreSQL, MySQL, Oracle, and SQLServer. There are other choices, and I encourage you to take a look at the various offerings. For this exercise, we'll be using a standard PostgreSQL database hosted on RDS. Many configuration options come with RDS, which we won't cover. Just know that it's possible and quite simple to run, configure, and manage a high-availability RDBMS instance using RDS. Other PaaS providers offer similar services for...

Since we've covered the overall design and different layers, let's get down to the implementation of our application code.

Every application, web or otherwise, needs a primary entry point. In our case, we'll use handler.py to begin application execution when a Lambda function is invoked. Serverless Framework applications will generate a handler.py file when you bootstrap a new project, so this pattern should be familiar to anyone who has used Serverless before. If you've never worked with the Serverless Framework, what follows will be a thorough introduction:

import sys

from pathlib import Path

# Munge our sys path so libs can be found
CWD = Path(__file__...

Now the fun part, we'll deploy our REST API using the Serverless Framework. At this point, we have not discussed the various configuration options when implementing serverless architectures on AWS. I'll cover different possibilities, and our particular configuration, later on in this chapter.

My pattern of using Docker as a build and deployment tool makes this process a bit easier. You are not required to do this, and there are likely other ways to make the process even simpler.

We will do all package building and deployment from inside a running Docker container, which I start and enter with the following Makefile target:

brianz@gold(master=)$ ENV=dev make shell

This equates to the following Docker command:

docker run --rm -it \
        -v `pwd`:/code \
        --env ENV=$(ENV) \
        --env-file envs/$2 \
        --name=coffee-cupping-$(ENV) \
...