Understand the modular design of a monolithic application architecture that uses a single codebase along with the implications when scaling and deploying a monolithic application. Implement applications with multiple modules and design the module APIs so they can be reused within the app.
Examples
Exercises
Context
A simple client-server architecture is often referred to as a two-tiered architecture. Functionality can be shifted towards both the client and the server. If the server is responsible for almost all of the functionality, we can say that we have a thin client. Conversely, if the client does most of the work, we can say that we have a rich client.
A server can also act as a client to another server. For instance, web servers frequently store data in a database server and, as a result, function as clients of the database server. This design is known as a three-tiered architecture and is quite common in typical web applications. The term was originally coined by John J. Donovan, who described them as presentation tier, logic tier and data tier - browser, web server and database.
The monolithic architecture is a software architecture pattern where an application is designed as a single, self-contained unit. This means that all the functionality of the application is contained within a single codebase and all the modules (M) of the application are tightly coupled. Both, the deployment and scaling of a monolithic application must happen as a single unit. Modules can not be deployed individually.
To ensure multiple teams can work on a big project with a single codebase, a monolithic application is often divided into modules where each module is responsible for a certain domain, such as customers, invoicing, reporting and more. Typically each module is then maintained by a distinguished team of engineers.
As an example, we will build a simplified version of an Instagram clone where a user can login into the application and view her feed of posts.
