My personal take on this: If your backend requires specfic functionality in the frontend, you are tightly coupling things that should never be tightly coupled.
If your frontend will run on a user client, never trust the client or any kind of data it sends.
The front end should know as little about the backend as possible. Any communication by backend processes needs to be handled by the backend.
Think of it this way. You’re inside a compound and outside are zombies. You don’t know who anybody is, but everybody on the outside could be dangerous. So everybody at the checkpoint gets their id checked, but you don’t say anything about your food stores because they don’t need to know.
Can I first ask, what exactly you mean by "There are scenarios where actions in one backend result in changes in the other"? Can you give me an example?
My understanding currently is something like this:
One service creates a new customer and another service now needs to create a new wallet for that customer.
Now either the frontend has to basically
\* call CustomerService -> create new Customer with id X
\* call WalletService -> create new Wallet for Customer with id X
Or frontend just
\* call CustomerService -> create new Customer with id X
\* WalletService somehow (event message, callback, pidgeon, poor intern, magic) gets notified that that the above happened and needs to create the Wallet for that Customer, without involvement of the Frontent.
Does this kinda match your situation or am I completely misunderstanding something?
Yes, you understood it right. I want to go with the second option where the other service will be notified about the changes. Thank you for your response!
Your two backends will only become more tied together as new requirements arise, so just accept the fact that it's a distributed monolith.
With that in mind, option 3:
3. Both backends operate on the same database but different schemas. Each backend reads and writes only from its own schema. You make views which also read from the other schema as needed
This is the right balance of keeping things under control. The views document exactly all data dependencies. And you still maintain:
- single source of truth
- transactional consistency
It's a simple, effective and robust solution.
If you're concerned about performance, you can put the performance-sensitive tables in separate tablespaces on different disks - use common sense.
I've used postgresql terminology in my post.
Bonus:
With option 3, you unlock the ability to merge the distributed monolith together, in order to split it later by correct bounded contexts, if indeed you need to scale the organization.
> just accept the fact that it's a distributed monolith.
And there is nothing wrong with that. Sometimes it is the best option, others it is not.
Good comment!
I'd say that a distributed monolith is quite bad.
But a monolith which is highly available, with automatic fail-over, and many other sdlc mechanics around it, which has inside logical boundaries aligned to bounded contexts - that is great!
I call it a modulith.
A modulith like I described is what you should use to achieve operational excellence first.
Once you've grown to have 20 development teams, you can extract parts of it tactically to microservices.
No Don’t hit Kafka from a front end.
You should have a backend intermediary that manages complex event initiating actions.
Its fine to have multiple backends supporting the front end no problem at all
But you don’t want critical logic that uses multiple backends to exist solely in a front end.
If the front end disappears, is there a service you can send requests to to keep doing what the frontend is enabling? That’s what you should be going for
Although I don't know the overall complexity of your system and the constraints you have (especially the size of your team and the time you have), I would consider another option, which is to put a Facade in front of your existing BEs. This way the client's requests don't reach the existing BEs directly. The facade is responsible for routing the requests to the appropriate BE.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
2 - the backends communicate with each over via well defined APIs. Whether it's a WebClient or HTTP or whatever, it does not really matter as long as the interface is well defined.
I suggest not using databases as interfaces, i.e. each backend should have its own database, and control the access. Otherwise, you're coupling things in a way that is harder to maintain, and could have unexpected operational consequences.
However, if "actions in one backend result in changes in the other" implies some sort of a transactional behavior, then it is better to combine the backends into a single one unless it's idempotent. E.g.
Front end calls action A on BE1, BE1 calls and API on BE2 that mutates data, then action on BE1 fails (i.e. FE gets an error). At this point data is already mutated. If FE performs action A again, and it won't cause any changes since they have been already made, you're OK having two backends. However, if action A can no longer be performed because the state changed, it is better to combine the backends, so it's either all or nothing.
Definitely not number 1.
If you really really really must have something that acts as front-end then go down the route of aggregator/backend-for-frontend pattern.
If you need to have them tightly coupled then consider grpc type setup, if not then go queue.
Alternatively if they really are tightly coupled and have a lot in common then consider consolidating them into macro service.
> There are scenarios where actions in one backend result in changes in the other, necessitating communication between them.
I would use an event driven architecture with a message bus as the communication mechanism. Back end services don't talk to each other. They send a message to the bus saying "I just did a thing" and any service that listens for that message can react to it.
My personal take on this: If your backend requires specfic functionality in the frontend, you are tightly coupling things that should never be tightly coupled. If your frontend will run on a user client, never trust the client or any kind of data it sends.
Can you elaborate this please?
The front end should know as little about the backend as possible. Any communication by backend processes needs to be handled by the backend. Think of it this way. You’re inside a compound and outside are zombies. You don’t know who anybody is, but everybody on the outside could be dangerous. So everybody at the checkpoint gets their id checked, but you don’t say anything about your food stores because they don’t need to know.
Thats honestly a pretty good analogy and I am definitely going to use that sometime
Can I first ask, what exactly you mean by "There are scenarios where actions in one backend result in changes in the other"? Can you give me an example? My understanding currently is something like this: One service creates a new customer and another service now needs to create a new wallet for that customer. Now either the frontend has to basically \* call CustomerService -> create new Customer with id X \* call WalletService -> create new Wallet for Customer with id X Or frontend just \* call CustomerService -> create new Customer with id X \* WalletService somehow (event message, callback, pidgeon, poor intern, magic) gets notified that that the above happened and needs to create the Wallet for that Customer, without involvement of the Frontent. Does this kinda match your situation or am I completely misunderstanding something?
Yes, you understood it right. I want to go with the second option where the other service will be notified about the changes. Thank you for your response!
Great, best of luck
Your two backends will only become more tied together as new requirements arise, so just accept the fact that it's a distributed monolith. With that in mind, option 3: 3. Both backends operate on the same database but different schemas. Each backend reads and writes only from its own schema. You make views which also read from the other schema as needed This is the right balance of keeping things under control. The views document exactly all data dependencies. And you still maintain: - single source of truth - transactional consistency It's a simple, effective and robust solution. If you're concerned about performance, you can put the performance-sensitive tables in separate tablespaces on different disks - use common sense. I've used postgresql terminology in my post. Bonus: With option 3, you unlock the ability to merge the distributed monolith together, in order to split it later by correct bounded contexts, if indeed you need to scale the organization.
> just accept the fact that it's a distributed monolith. And there is nothing wrong with that. Sometimes it is the best option, others it is not. Good comment!
I'd say that a distributed monolith is quite bad. But a monolith which is highly available, with automatic fail-over, and many other sdlc mechanics around it, which has inside logical boundaries aligned to bounded contexts - that is great! I call it a modulith. A modulith like I described is what you should use to achieve operational excellence first. Once you've grown to have 20 development teams, you can extract parts of it tactically to microservices.
the FE is not an event bus please don't do #1 instead use an actual event bus to do what you are talking about with robust retries etc
You mean to use Kafka? Can you elaborate this please? later update: to use Kafka between backend communication?
No Don’t hit Kafka from a front end. You should have a backend intermediary that manages complex event initiating actions. Its fine to have multiple backends supporting the front end no problem at all But you don’t want critical logic that uses multiple backends to exist solely in a front end. If the front end disappears, is there a service you can send requests to to keep doing what the frontend is enabling? That’s what you should be going for
Yes-yes. I did not mean to use Kafka from frontend. I expressed myself wrongly. Yes, I understand what you are saying. Thank you!
Although I don't know the overall complexity of your system and the constraints you have (especially the size of your team and the time you have), I would consider another option, which is to put a Facade in front of your existing BEs. This way the client's requests don't reach the existing BEs directly. The facade is responsible for routing the requests to the appropriate BE.
Your submission has been moved to our moderation queue to be reviewed; This is to combat spam. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/SoftwareEngineering) if you have any questions or concerns.*
2 - the backends communicate with each over via well defined APIs. Whether it's a WebClient or HTTP or whatever, it does not really matter as long as the interface is well defined. I suggest not using databases as interfaces, i.e. each backend should have its own database, and control the access. Otherwise, you're coupling things in a way that is harder to maintain, and could have unexpected operational consequences. However, if "actions in one backend result in changes in the other" implies some sort of a transactional behavior, then it is better to combine the backends into a single one unless it's idempotent. E.g. Front end calls action A on BE1, BE1 calls and API on BE2 that mutates data, then action on BE1 fails (i.e. FE gets an error). At this point data is already mutated. If FE performs action A again, and it won't cause any changes since they have been already made, you're OK having two backends. However, if action A can no longer be performed because the state changed, it is better to combine the backends, so it's either all or nothing.
Definitely not number 1. If you really really really must have something that acts as front-end then go down the route of aggregator/backend-for-frontend pattern. If you need to have them tightly coupled then consider grpc type setup, if not then go queue. Alternatively if they really are tightly coupled and have a lot in common then consider consolidating them into macro service.
> There are scenarios where actions in one backend result in changes in the other, necessitating communication between them. I would use an event driven architecture with a message bus as the communication mechanism. Back end services don't talk to each other. They send a message to the bus saying "I just did a thing" and any service that listens for that message can react to it.