Nexen
Explore posts from serversMaking 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.
7 replies