Question posted in 
Straight to the point. I’m about to start creating a web app using Blazor (chose Blazor due to my collage projects experiences). The idea behind the system is logistics, and I was thinking of creating this system out of separate parts that work and communicate together. For example:
-
Transportation;
-
Inventory;
-
Packaging.
What I want to do is create these parts one by one, and while I’m developing other ones, already made ones could be used by companies (clients). Let’s say I already have those 3 mentioned services, and there are two companies, and I need them to be able to use only those services that are needed for them. E.g. one uses only transportation service to register cargo transportations, and the other one use all of them, and in the meanwhile I am developing an accounting service. Also I would need, as I understand, a separate database for every company that uses the system, so I read something about multi-tenancy.
Now, for the architecture type, I’m thinking about using microservice architecture. To my understanding that would make sense for having those separate services and each of them having their own databases, therefore If one company uses on transportation service, they wouldn’t need the packaging service and it’s database.
For the development tools, I’m thinking about using new blazor template that came with .NET 8, Blazor Web App, that apparently includes both Blazor Server and Blazor WebAssembly.
And for the publishing tools, I’m certain of using Azure, as I feel it’s the best one to use to make sure everything goes as planned, secured and taken care of by Microsoft, even though it might cost quite some money.
My main problems are:
-
Am I correct by selecting microservice architecture?
-
What should the Visual Studio Blazor solution projects/directories structure look like? Simply by creating a Blazor Web App, I get server project and client project (but I can add more projects and reference them in the server one), but I’m not sure where and how I should put all those separate services in there, and how everything should look like from solution (projects/directories) point of view. Should every service come as a separate project in the same solution? Also what about other middle layers between client (as I understand, that’s the users browser part) and a server and/or every single service?
-
What Azure products/services should I use for this type of web application/system besides cloud hosting?
As of now I’m constantly looking for more info and examples for this upcoming project of mine, however everything is still like through the mist. Thanks in advance.
2
Answers
Below are my personal ideas and for reference only, because you are the one who is the most familiar with your business.
-> Am I correct by selecting microservice architecture?
It’s up to you to choose any kind of architecture, but I think Rome was not built in a day，so we’d better to estimate how many users would use this system and if the easiest architecture + minimal servers + poorest performance could afford this system and its users. If yes, then I’m afraid asp.net core MVC + only one server + one database should be the best option because it cost less.
When I saw
having those separate services and each of them having their own databases, what I have in my mind is an Azure service containing multiple web app + several databases…. It might be expensive, and if there’s no so many users, you might waste much resources.Normally speaking, we should adjust the architecture based on the really usage, let’s say
Transportationis used heavily whileInventoryis rarely used, but the whole project is also under control, then you can just scale out the web app. Or changing the architecture to separate outTransportationpart and host it in a separate web app, and only scale up/out this single app. The same for databases. If there’s too many rows data in all off the table, then we can use specific database for specific business part. If only some specific tables contain too much data/be hit very frequently, then we might divide these tables into several tables.The advantages for microservice architecture is that you can divide the business into several parts in advance so that you can drive the whole system easily when any issue occurred in the future. The disadvantages are, expensive, much more codes in the beginning, and the design might not be the most effective.
->What should the Visual Studio Blazor solution projects/directories structure look like?
If I were you, I would choose as simple as possible in the beginning for example, only one MVC app. And since you are good at Blazor, so maybe only one Blazor server app. If you choose to use microservice architecture, then I recommend you using Blazor stand alone web assembly instead of Blazor web app. Because we only need one client for UI, but plenty of services(backend apps) for different business. Then the solution might be, one blazor client app(Blazor wsam) + several API projects.
->What Azure products/services should I use
It depends. If you want to make your users to use microsoft account to sign in your app, or add role-based-access-control for your own API easily, maybe you can use Azure AD(Azure Entra ID). If you want to store database connection strings in the cloud but not your own appsettings.json, Azure key vault can be taken into consideration. If you have many confiugrations, Azure APP configuration is suitable for you. If you have some scheduled tasks, then Azure function is good. If you also want to use memory database, then Azure CosmosDB. Adding telemetric or logs which can be monitored in the cloud, then Azure Application Insights….
It depends on your requirement and business. Based on my understand of you system, Azure web app(host your app) + Azure Database(sql server + CosmosDB) + Azure AD for user & role management + Azure Managed Identity(to allow easy auth between all Azure resources you used) might be helpful/recommended to you.
On the database front, I would not create separate db’s for each function, as tiny wang points out that could create unnecessary expense. I would create separate schemas for each function. That way if you need to scale this out with a new db its easier to separate the one function you want to scale.