Skip to content

Modular Monolith Solution

This document explains how to start PSS®X platform application as modular monolith solution.

Pre-Requirements

The following tools are required in order to run the solution;

Other dependencies (like Valkey and RabbitMQ) comes with a docker-compose configuration, so no external installation required.

Overall Diagram

This section introduces the solution structure and briefly explains the solution components. The following diagram is an overview of the applications, services, databases, and other components;

  • The Authentication Server is a web application serves as openid-provider (can be replace by Keycloak) that is used as a single sign-on authentication server. It hosts the login, register, forgot password, two-factor authentication, profile management pages, OAuth endpoints and authentication-related APIs. All applications and services use this application as a central authority for authentication.

  • There are two web applications in the solution

    • The Web Application is the main UI of the system. It uses the Authentication Server to make users login to the application. UI development can be done MVC (Razor Pages), Angular and Blazor technology.
    • The Public Website is a second web application that can be used as landing page for the application. It uses the Authentication Server to make users login to the application.

  • There is only one modular monolith Service is coming with the solution. This monolith application consists of the following modules;

    • Identity Module is used to manage users, roles, clients, resources... in the system.
    • Tenant Management Module is used to manage tenants for a multi-tenant system.
    • Audit Module is used to persists audit logs to a database.
    • Feature Module is used to persist and manage the features of the PSS®X platform.
    • Permission Module is used to persist and manage the permissions of the PSS®X platform.
    • Settings Module is used to persist and manage the settings of the PSS®X platform.
    • ....

  • There are two databases, each is owned by the application. Databases are SQL Server with EF Core integrated in the applications. You can switch to another RDBMS or MongoDB for any of them.

  • There are some infrastructure services are configured in the solution (they are configured to run with docker-compose);

    • Valkey is used as a distributed cache server.
    • RabbitMQ is used as a distributed event/message bus.
    • Sql-Server-Linux is used for running the database in a container. The default exposed port is 1434.

Database Migrations

Before Running The Application

For front-end projects the following extra steps need to be taken if client-side package dependencies are missing. You should run it yourself if you have first cloned this solution from your source control, or added a new client-side package dependency to your solution.

Install the ABP CLI utility:

dotnet tool install --global Volo.Abp.Studio.CLI --version X.Y.Z

To use it as a local tool, restore the dependencies of a project that declares it as a tooling dependency using a tool manifest file.

dotnet tool restore
  • Run abp install-libs command on your solution folder to install client-side package dependencies. This command will copy client side packages from node_modules folder to wwwroot/libs.
  • Run GridLab.PSSX.DbMigrator to create the initial database. This should be done in the first run. It is also needed if a new database migration is added to the solution later.

Run the Solution on IDE

The solution has a few host (GridLab.PSSX.AuthServer, GridLab.PSSX.HttpApi.Host, GridLab.PSSX.Web and GridLab.PSSX.Web.Public) applications to run your modules. Host applications are used to run your modules in a fully configured application.

  • GridLab.PSSX.AuthServer application is an authentication server used by other applications. It has its own appsettings.json that contains database connection and other configurations.
  • GridLab.PSSX.HttpApi.Host hosts the HTTP API of the module. It has its own appsettings.json that contains database connections and other configurations.
  • GridLab.PSSX.Web host the UI of the module. This project contains an appsettings.json file, but it does not have a connection string because it never connects to the database. Instead, it mainly contains endpoints of the remote API server and the authentication server.
  • GridLab.PSSX.Web.Public host the Public UI of the module. This project contains an appsettings.json file, but it does not have a connection string because it never connects to the database. Instead, it mainly contains public endpoints of the remote API server which doesn't require authentication.

You should run the application with the given order:

  • First, you need to run GridLab.PSSX.DbMigrator application for creating the database of identity server and run the GridLab.PSSX.AuthServer project since other applications depends on it.
  • Then, you need to run the GridLab.PSSX.HttpApi.Host project since it is used by the GridLab.PSSX.Web application.
  • Finally, you can run the GridLab.PSSX.Web project and login to the application using platon as the username and 1qaz2WSX90-= as the password.
  • Optionally, you can run GridLab.PSSX.Web.Public project which serves as a landing page of the application.

Infrastructure services must be up and running in order to run the application. You can use the docker-infrastructure-run.ps1 script to run the infrastructure on the Docker engine.