Breaking ASP .NET MVC application into microservices

Question

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:

1. 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.
2. 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?

Answer 1

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 users 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.

Answer 2

You might consider merging your UI logic with server-side logic, and segmenting the results into Bounded Contexts that encapsulate Microservices. Here is a tutorial to get started.

Here is the summary:

UI logic should focus on rendering, but not managing, data. Migrating logic from UI to server allows you to group your entire feature-set within the same application tier. Abstract and sufficiently cover core feature logic in terms of unit-tests. This should yield a well-defined set of APIs that your Microservices can leverage. Then split the feature-set into Microservices.

Create a reusable Microservice template. This should be a boiler-plate structure that allows the rapid implementation of Microservices. Core feature logic should be hosted within Microservice templates.

Implement the queue-pooling concept to ensure reliable message delivery. This is a more advanced concept to guarantee reliable message delivery. Remember – you’ll likely leverage a service bus in order to interface your Microservices.