Build a modern three-tier architecture web application with Cloud Run

Learn about architecting a traditional multi-tier web application and how to transition it to the cloud. Learn about containerizing your frontend and backend for hosting on Cloud Run. Use an in-memory data store (Redis) and a CloudSQL (PostgreSQL) to store the data for a to-do list web application.

This application uses a traditional, multi-tier architecture to implement a to-do application with some user interactivity:

• Presentation: Nginx web server to serve a basic HTML and JavaScript frontend.
• Application: API implemented in and served directly from Golang.
• Data storage: Caching layer provided through Cloud Memorystore for Redis and a CloudSQL for PostgreSQL database layer for storage.

This type of architecture separates concerns into different application layers that are often closely linked. Moving these layers into containers separates their technical needs and enables them to be deployed on platform-agnostic cloud services that can handle the management and scaling automatically, such as Cloud Run.

The frontend and middleware layers are containerized and deployed separately to Cloud Run as serverless services (see more in the "Hosting" step). They communicate directly with each other and can connect to the data storage layer using a Virtual Private Cloud (VPC) network.

Additional tiers (for example, a caching layer for data storage as in this application) can be added to the architecture and deployed independently as needed.

Manually managing such a multi-tier and multi-layer architecture can be complex. However, in a cloud-based environment, a declarative configuration tool can help coordinate multiple services, containers, and the overall architecture. This application uses a Terraform configuration; see the code on GitHub for details .

Learn more about designing the backend for a multi-tier web application and selecting technologies to run your application in the cloud.

The data storage layer in this multi-tier web application is backed by a Cloud SQL database accessed from the application layer. A Memorystore for Redis caches frequently accessed data, which the application layer manages.

For a content-driven application that includes interactivity such as this to-do list application, consider the type of data the application needs to store and how it will be accessed.

• A relational database management system offers strong assurances for data integrity and consistency, transactions, and options for searching and querying well-defined and structured data.
• NoSQL databases offer scalability while supporting more flexible data structures, which may be beneficial during development and prototyping or when more flexible data is stored.

Consider additional caching for frequently accessed (or written) data to improve your application's performance. For example, an in-memory database such as Memorystore for Redis improves access speeds by reading data from faster memory rather than storage that uses a system optimized for quick data retrieval.

Learn more about data storage options for a layered, multi-tier web application, including choosing the best database type for a content-driven application. Consider the approach to scaling and improving the performance of the storage layer, in addition to any regulatory requirements and security concerns.

The frontend of this application uses client-side rendering and a minimal HTML and JavaScript interface to render data provided by the application layer API backend. This client-rendering approach separates the presentation (frontend) from the data processing (backend) layer.

For any content-driven application that provides for interactivity, frontend performance and low latency is critical for getting users to stay engaged with the application. Use a tool like PageInsights or Lighthouse to assess your application against well-established performance metrics, including the Core Web Vitals.

Accessibility is also important to design for inclusive web experiences that target users all around the world.

Learn more about designing and building the frontend for a multi-tier web application with interactive elements.

In a multi-tier architecture, the application is divided into separate layers. With a cloud-focused approach, the layers containing application code, such as the front and middleware layers, can be moved into containers. These containers can then be hosted on a serverless service such as Cloud Run that automatically handles scaling and manages the infrastructure required to run them.

This to-do list application includes interactive elements, making it unsuitable for static site generation, where static HTML files are generated at build time. Instead, the application uses client-side rendering, where the Javascript interpreted in the client's browser accesses the middleware API layer directly to fetch data based on the traditional presentation-processing abstraction model.

Users directly access the web server deployed in the frontend container, which serves static HTML and Javascript files. However, to take full advantage of a cloud-centric approach, this could be scaled further to improve performance by providing an additional caching layer for incoming requests or serving static data through a content delivery network and from a service optimized for static data, such as Cloud Storage with Cloud CDN or Firebase Hosting.

Similarly, the application layer, which exposes an API server written in Golang, could be abstracted further through an API gateway cloud service (such as API Gateway or Apigee ). Such a service provides additional security, management controls, caching, analytics, and performance while providing useful development abstractions to make it easier to build with the APIs.

Learn more about hosting and serving options for a multi-tier web application.

Explore the sample to-do list application through the jump start solution "Three-tier web app."

As you explore the application, consider the key parts of the application discussed in this pathway and how the presentation, application, and data storage tiers are split up and connected. The Terraform configuration shows how these containers and services are deployed and configured.

Deploy and run it directly on Google Cloud and see how to structure and build a multi-tier web application that includes interactive elements with Golang, Cloud Run, Memorystore, and Cloud SQL.

To get started, open the article and deploy the application. Alternatively, you can explore the Terraform configuration on GitHub or try it out directly in your Google Cloud project .