I’m looking for best practises to design my Application. I have one ASP.NET-Core Frontend-Application and one ServiceStack API.
Both applications don’t need to communicate, they both access the same DB in the background.
My questions are, should I combine them both into one Application or separate them in two (and have 2 Kestrel Servers running)?
What would be potential caveats according authentication and session management? Are these even issues?
What would be the pros and cons of the two solutions?
For simplicity I’d start with one unless you have a good reason to separate them as it adds complexity, especially if they’re sharing the same Database, from an SOA POV there really should only be a single App/Layer that manages/encapsulates a database.
On the other side if both Apps are unrelated with each other it suggests that the Database should be decoupled and the Apps should be isolated. If you’re going to keep them using the same database then they should be in the same App.
Basically there are lot of factors that go into deciding what to use: modularity and whether they can be easily de-coupled, dev cycle, i.e. whether they’re expected to both be worked on and deployed together, the size of the code-base (small/medium stick to monolith), expertise of dev team, i.e. if all devs frequently work on both keep them together, if devs are assigned to work on different Apps then there will be less friction if they’re working on different code-bases.
Thanks for your great reply. Even as a seasoned programmer one often forgets one of the basic rules: “pick the right tool for the problem” :-). The first article about the Majestic monolith precisely hits that spot.