A SPA is a client application that runs entirely in the browser. The web apps load into a single HTML file (or fragments of it), which loads JavaScript and CSS to enable a reactive experience. The browser can then use Ajax to send and receive data from the server and update the view without reloading.

Here's an example of how a client application and server interact through Ajax:

The benefit here is that, without the constant reloading, we get better performance, making for a better overall user experience.

In the serverless world, we split out the traditional server component into two main components:

• The hosting components provide our static HTML through a distribution network, backed by S3 storage.
• The API component provides the dynamic content through a RESTful interface.

Splitting the components allows us to logically separate the code base as well. Now, there is a clear definition between the frontend code and the backend code. The deployment of new frontend code is simply a copy into the S3 bucket that is storing the HTML, and potentially a cache invalidation request sent to CloudFront.

The following is a high-level diagram of how we represent the frontend and backend components using serverless services:

By using API Gateway and Lambda as the backend for our SPA, we can obviate the need for a server altogether. If we need to save some state or add persistence, we can use Amazon DynamoDB as well. Because these services are serverless, we're only paying for them when our website is in use and so the cost of development can dramatically reduce.

Okay, so there are some circumstances where you would need to add some server infrastructure to your solution, such as if you were serving up specific dynamic content or performing server-side rendering of the fully structured HTML. If you find yourself in that situation, the SPA pattern does support being extended by adding a traditional server tier. We can add an application load balancer fronting an EC2 auto scaling group, and add the routes accordingly using our CloudFront distribution. The root path still makes its way to the S3 bucket, while everything under /traditional is routed to the load balancer fronting the server components and relational database.

The following is our new route (/traditional), which is required to provide some specific dynamic content that can't be delivered by API Gateway. The backend application is running on EC2 instances in an auto scaling group, and they all have access to data stored in an Relational Database Service (RDS) database:

So, now we've seen a high-level overview of the architecture, let's drill into some of the components and see what considerations we need to give for each.