Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
May 5, 2021 08:41 pm GMT

Sharing data between modules in modular monolith

Recently my team and I are working on a modular monolith. Weve been inspired by Kamil Grzybeks solution available right here. This repository is awesome, and if you havent seen it, I strongly recommend taking a look.

Generally, during development, keeping our boundaries when going through the Command/Write part of our CQRS architecture was quite easy. However, once we started thinking about the Query/Read part, we noticed that we could use some data from module A in module B. Then we thought about different approaches how we could get the data efficiently, but also without crossing logical boundaries, which is quite easy, because of no physical separation.

Querying other modules data meh

As the data is stored in one database, its tempting to just query data from another schema. However, it creates coupling on the database level. We have set a rule, that you shouldnt build a query that touches more than one schema. So we decide to not go with this approach. So even though we have only logical separation right now, if wed decide to physically separate the database as well, it wouldnt be possible with such coupling. Simple, but it wasnt acceptable in our case.
querying other modules' data

Separate Backend For Frontend

Another option was preparing Backend for Frontend approach. The BFF would be responsible for gathering data from different modules and then returning such data to the frontend. The data could be gathered from REST APIs in the backend that hosts the frontend and then converted into a format that is easily useable in the Frontend.

This approach is very reasonable, but I dont like the fact that within one system Id have to introduce such overhead. Also, if the modular monolith will need to separate a Microservice outside of it, and the Microservice goes down, itd be impossible to let the user work with the UI. Even if this is just a different part of the system, that doesnt need anything else besides one piece of information. But if the part of the system goes down you aint gonna get part of the data.
BFF

On the other hand, if the entire modular monolith goes down well, the same story, isnt it? But still, as were owning the frontend we should actually make it easy to work with, right? After all, I feel like I can do more (and quicker) in the backend. So this is definitely the way to go, but perhaps theres something better.

Frontend calls REST APIs and connects the data

This approach would be similar to the previous one. Frontend would call multiple REST API endpoints and put it all together into a view. I dont like this approach because it feels like doing too much on the frontend side. Again, I prefer to prepare the data on the backend and return a view model that can be easily rendered. But thats my personal preference, based on the fact that I prefer working on the backend. This approach is definitely good for developers that feel more confident working in JavaScript. Personally, I dont like to push too much pressure there. So I didnt decide to go with this approach.

Frontend queries

Duplicating necessary data to build Views/Read models

As I said, I prefer to work on the backend side and use the frontend just for rendering the data. Additionally, we are currently using CQRS. So our decision was to build eventually consistent Read Models.

But how to get data?

Okay, it felt weird for me at first glance. But we just duplicate that between modules. So if module A is the technical authority of some data, and module B needs it, we just get it there through integration events. So if module B is interested in some data from module A, it just subscribes to its events. This way, theres no coupling between those modules. The duplicated, cached data is only used for Read capabilities. This data is never modified outside of module A, because module A is a single source of truth.
Duplicating the data

Because of that, were able to cache the data in the modules B database and build Views (the database Views) to be able to provide the data that the frontend needs quickly, through raw SQL queries called from Read side of the application.

Also, this way, if this is ever a separate service or for some reason, part of the app is down, we are still able to get the data from the calling module.

Generally, when I think about it, this approach could be also applied to Microservices/SOA as well. Its not solely for the modular monolith itself.

What do you think about the approach with duplicating the data vs BFF? Which one would you go with?


Original Link: https://dev.to/lukaszreszke/sharing-data-between-modules-in-modular-monolith-50on

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To