Summary

The CAT (Clients-ApiResouces-TokenService) architecture pattern is introduced as a modern approach for structuring software applications to promote modularity, scalability, and maintainability, particularly for SPAs (Single Page Applications) and mobile apps.

Abstract

The CAT architecture pattern is proposed as a solution for modern application development, drawing inspiration from the US Federal Government's separation of powers. It consists of three modular services: Clients (web, mobile, or desktop apps), ApiResources (REST API or GraphQL services), and TokenService (for JWT and SSO management). This pattern extends the traditional 3-tier architecture to better suit the needs of SPAs and mobile applications by enforcing a clear separation of concerns. The CAT pattern facilitates logical and physical organization of code, aids in the engineering of scalable and maintainable enterprise applications, and aligns with SOLID principles for software design. It also simplifies security management by centralizing authentication and authorization through a single TokenService.

Opinions

The author suggests that the CAT pattern is an evolution of the traditional 3-tier architecture, tailored for modern web and mobile applications.
The pattern is seen as beneficial for organizing source code into a structure that is easy to navigate and manage across multiple projects.
The CAT pattern is considered to be particularly useful for enterprise applications that require scalability and maintainability.
The author believes that the CAT pattern's centralized TokenService reduces the amount of security-related code developers need to write.
The pattern is thought to align well with SOLID principles, particularly the Interface Segregation Principle and Single Responsibility Principle.
The author provides a range of tools and tutorials to support the implementation of the CAT architecture pattern, indicating a preference for certain technologies and frameworks.
The analogy between the US Federal Government's separation of powers and the CAT pattern's separation of concerns is used to illustrate the pattern's effectiveness in managing complex interactions between different parts of an application.
The author implies that while the CAT pattern is powerful, it may not be necessary for simple applications where its benefits might be overkill.

CAT architecture pattern for modern app SPA/Mobile

Another software pattern? Don’t we have enough patterns out there already? Please, hear me out. The purpose of this story is to make an introduction to the CAT (Clients- ApiResoures-TokenService) pattern to promote tightly integrated but loosely coupled modular software components.

Prelude

For those who are into political science and programming, you can draw similarities between the US Federal Government and the CAT architecture pattern. Check this out.

The US Federal Government: To ensure a separation of powers, the U.S. Federal Government is made up of three branches: Legislative, Executive, and Judicial. To ensure the government is effective and citizens’ rights are protected, each branch has its own powers and responsibilities, including working with the other branches.

The CAT architecture pattern: To ensure a separation of concerns, the CAT pattern is made up of three modular services: Clients, Api Resources, and Token Service. To ensure the application is effective and users’ rights are protected, each modular service has its own powers and responsibilities, including working with the other modular services.

Don’t laugh!

CAT Architecture Pattern Introduction

Many full-stack developers, including myself, have had experiences with the 3-tier architecture pattern, consisting of Presentation, Business, and Data layers. The 3-tier architecture is a software design pattern and a well-established software architecture. Would it be possible to continue using the 3-tier architecture for SPA and Mobile? The answer is “force fit”.

My first real-world SPA application is the Angular 4, ASP.NET 4.x WebApi, and Oracle backend. At first, I was struggling to figure out how to apply 3-tier to SPA. I did a mental map of the SPA to the 3-tier architecture as following

Angular to the Presentation layer
ASP.NET WebAPI 2 to the Business layer
ORM Dapper to the Data layer

On the coding side, I correlated techniques such as

Ajax to Angular HTTP client library
MVC Controler to ApiController
Security Cookies to JSON Web Token (JWT)

As I have continued to work on additional Angular apps and other types of clients such as React and Mobile, a NEW pattern has emerged where modular components can be structured into three distinct service categories, facilitating Separation of Concerns (SoC).

Clients — this service category can be desktop, web, or mobile app
ApiResources — this service category provides JSON data via REST API, GraphQL, etc.
TokenService — this service category issues JWT and can facilitate Single-Signon using identity providers such as Azure AD, Okta, etc.

Figure 1 is an illustration of the CAT architecture pattern supporting three types of Clients — Angular, MVC, and Postman testing tool. The ApiResources service category has two REST API projects. The Token Service category consists of IdentityServer4, integrated with AzureAD to support Single-Sign-On. To scale, Mobile or Device/TV apps can be added to the Clients box and additional WebAPIs can be added to ApiResources box.

Figure 1- CAT Architecture Pattern Example

How can the CAT pattern help developers with software engineering?

First, the CAT pattern helps developers to logically bridge the knowledge of traditional 3-tier architecture to the new way of building SPA/Mobile. Although the layers are not mapped one-to-one, the concept of separation of concerns is still the same. Additionally, we can relate new techniques such as HTTP Client, JWT, REST API to legacy Ajax, Cookies, MVC controller respectively in our day-to-day work.

Second, the concept in the CAT pattern can help developers to physically organize source code so we can find them easier. Imagine you work on multiple projects and need to find where is the Angular app on your local drive if you have not touched it for a while. When starting a new project, developers can organize the source code into three folders

Clients — this folder is for storing source code for Angular, React, Mobile, or MVC apps
ApiResources — this folder is for storing source code for APS.NET Core WebAPI (or Express JS, etc.)
TokenService — this folder is for storing source code for IdentityServer4/Admin UI (or NPM jsonwebtoken, etc.)

Figure 2 is an example of the folder structure in the project DevKit API Security tutorial series that I published on medium.com. Notice that in the root folder, I included the readme.txt file to describe the project structure so other developers can find information to Get Started.

Third, by following the CAT architecture pattern, developers can engineer enterprise applications that can scale and are easier to maintain. The security of multiple client applications is handled by one centralized Token Service, resulting in less code to write. When it is time for DevOps, the application modular component services can be deployed and scaled independently, whether the infrastructure is the traditional IIS websites, Azure App Services, or Docker container.

The $64,000 Question: Is CAT really an Architecture Pattern?

The Cat Pattern has been around for a long time. I now wish to extend the concept into the Software Development cosmos and give you a chance to decide for yourselves (:

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. — Wikipedia

Modern applications are distributed and communicated over standard HTTPS. The application sub-components can run on thermostat, TV, mobile, desktop, tablet, server/serverless/docker on-premise or in the cloud. The CAT architecture pattern helps to group/sort components into three major categories: Clients, Api Resources, and Token Service, and establishes the HTTPS communication boundaries between them. When applying SOLID principles such as Interface Segregation Principle and Single Responsibility Principle, the architecture can achieve modular design, scalability, and maintainability.

When following the CAT pattern, application sub-components can be upgraded/swapped out without rewriting the whole app.

CAT Toolbox

What tools out there to support the CAT architecture pattern? I am going to list a collection of tools in my CAT toolbox which has both opensource and personally created, for building fast, robust, and modular applications. These tools adhere to the Single Responsibility Principle (SRP) at the software components and microservices level.

Tools for Clients

Ngx-Rocket — scaffold SPA/Mobile app. Click here for the tutorial
New React App — Create a New React App

Tools for ApiResources

OnionAPI template — scaffold ASP.NET Core WebAPI with clean architecture based on EntityFramework. Click here for the tutorial.
KissAPI template — scaffold ASP.NET Core WebAPI with clean architecture based on Dapper/SQLKata. Click here for the tutorial.

Tools for TokenService

IdentityServer4 — the #1 opensource project for securing enterprise ASP.NET WebAPI. Click here for the tutorial
IdentityServer4 Admin UI — the best Admin UI of the IdentityServer4 and Asp.Net Core Identity. Click here for the tutorial

CAT Tutorials

I have published CAT-related tutorials under Scrum and Coke publication on Medium. These tutorials come with source code, screenshots, and Youtube videos so that developers can try them out on a local desktop.

Tutorials for Clients

Tutorials for ApiResources

Tutorials for TokenService

Summary

The CAT pattern is applicable in enterprise environments where scale and maintainability are the goals. Be aware that it may be overkilled for a simple app. I hope you enjoy the analogy of US Government vs CAT vs. 3-tier architecture.

Dogs may be man’s best friend but CATs rule the world!