Breaking down a large monolithic project structure – Part 1: Why we are doing it



Over the last year, we have been busy modernizing the internals of the HQ, the project structure and much of the business logic. One of the major goals was to provide an API for our new Angular front end and thereby separate the UI from the backend.

In this series of posts, I am going to share what we did, how we did it and what we learned. This is the first of a series of posts and will focus on our motivation to break down the project structure.

The HQ is a large but modular, web-based business software. Its modularity lies in the way the SaaS application can be configured for each customer individually. The underlying project structure and code, however, were rather monolithic and interdependent. For example, the frontend and backend shared the same code and project, which is typical for ASP.Net applications. This way, much of the business logic was intertwined with UI and display code.

This led to several problems. For one, changes to the frontend always required us to recompile the entire application. On a dedicated build server, this would take several minutes and it would slow us down during development. Also, we were not able to deploy hotfixes in the UI without a significant downtime of the application. But most of all, we were not able to write automatic unit tests for this mix of UI and business logic.

Also, the application used to be hosted as one single monolithic piece in one process. Changes to one feature of the application required a redeploy of the entire application and would result in a downtime even for customers that did not use that particular feature.

Breaking the process boundaries was difficult for us for a long time, since our previous ORM used an in-memory query cache. Changes to the underlying database would therefore not be reflected in another part of the application running in a different process or on a different machine. In order to host parts of the application separately, we needed to replace the ORM and use a distributed cache that would be available to and consistent across multiple applications.

A distributed cache keeps data consistent across multiple instances of the application.

One of those new applications is our API. We wanted to host the API separate from the web application and therefore needed a cache that would be shared by both. Since the API would need access to the same database layer and business logic as the web application, they would still reside in the same project structure and share the same core.

Read more about what we did and how exactly we did that in the upcoming post.

Get Angularity updates



Schreibe einen Kommentar!

Your email address will not be published. Required fields are marked *