Making sense of monolith structure and modularity
Hello, I am mainly frontend developer (working on mac, so using vscode), but on my personal project im working on dotnet core web api. It kinda exploded with functionality and i got stuck.
I need to shed a light and figure out what is the correct easy way for my structure for the future.
I have now monolith with Main project - controllers with swagger, Logic project - services, Models project -models with EF, typical backend in monolith. Now i need to have notification system and aggregator when activity happens like Liked post, commented post. I have tried to create separate service for this, which would have separate database and save only important things (entityid, actor, ...) using activity streams spec, Push notification can be created from activity spec, but i dont want to save names and stuff if something changes.
The backend itself has: users, posts, pages, general things(alerts, badges,..) so i guess it can be afterwards split by these to modules
So the structure now is:
client -> backend
the ideal way would be to have one "endpoint" for client, so:
client -> backend -> notification service
But the notification service has only ids, so i need to hit backend to get actual data (post name,...)
how can i deal with this? I want it easy and simple and to be ready later on to split it to microservices for better scaling and of course there could be more services added later.
Also client has generated api from swagger, so swagger is very important for me.
I hope it makes sense to you, what my structure is, if not, i can explain more or with images.
3 Replies
why use relational database for everything, you could have a denormalized faster data source too
also i wouldn't necessarily use backend service just for proxying events to an event queue/stream
especially considering it could be through a sse/websocket (then that service dispatches to backend, you maange auditing, and so on)
apart from that there are the usual practices: having caches, making sure the event handlers touch the db only when necessary, etc
my 1.99 cents
one of the approaches for microservices architecture would be client -> notification service ->
backend http request for actual data -> client. And it should be fine
if for some reason u dont want to call ur notification service from client u can just pass all necessary data from backend, but depends on ur conditions
maybe u wanna do it like this client -> backend -> queue message sent
notification service takes message and enriches model from backend with http request
or u can supply all necessary data in ur queue message
I understand now a bit more, my failure was that i wanted to do modular design, but wanted notification service completely outside from the get go.
I use relational database because its easier at start, splitting up can be done later.