I have a big ASP .NET MVC application which consists of several different widgets. They all display some kind of data related to stock markets, but they're actually pretty separated from one another. I'd like to break the big monolithic app into several smaller services which should be easier to maintain.
It would be pretty simple if I had only server side code written in C#, but actually I also have quite a few javascript components and also some styles and other resources. I don't know where they should be put. From the separation perspective, if some javascript files are used only by one specific widget, they should be part of its service. On the other hand, I don't know how to later integrate all the widgets and their resources, especially when there might be some common scripts used by all components.
So far I've had two ideas, none of which seems ideal:
- Separate only the server side code and leave all the client side components in one common project. Js integration, minimization and management would be easier, but developers still would need to work on two different projects when updating one specific service.
- Create nuget packages for each microservice with both server and client side code. What about common scripts then and files dependent on them? If I made a breaking change in common infrastructure, I would need to manually update all the dependent code. It would be much more difficult that updating files when they all reside in the same project.
Are there any better solutions?
Best Answer
I would separate only the server side code and leave all the client side components in one common project. I'm not bothered by your assertion that developers would have to work on multiple projects; every Visual Studio solution I've ever worked on has multiple projects, and some have many.
The only time you would create Nuget packages would be if you are using the microservices in multiple solutions.