2

After reading this great article I thought about migrating our platform to micro-services architecture.

Our stack is Asp.Net Web API (Rest...) on the server. Angular 2 in the front.

I wanted to make a little proof of concept to check if we should continue down this road.

As for my understanding, I need to take some chunks from our web app and slice it into micro services. As for the beginning, I want to take 2 screens I have, "Users" And "Purchase History" (each of them is too big to be micro service but this is just for the POC) and create each one of them as micro service.

I read that the UI should be part of the microservice, so should I create a new angular two app for each one of them?

If so, should I use rest to call for the rendered HTML?

Vertexwahn
  • 7,709
  • 6
  • 64
  • 90
Shaul Zuarets
  • 839
  • 2
  • 10
  • 20

1 Answers1

4

Frontend and backend API, two services (components) – it’s already some kind of microservice architecture. The questions are how big your components, what kind of logic they have, will you have benefits if you split some logic to different services?

Per microservice architecture every service (component) of your system should have some dedicated logic (domain), solves some related problems, persists data to its own data-store, can be developed and deployed separately. In some cases, data-store can be shared between services.

So, the goal of splitting logic into different services is making your application easier to develop, maintenance, support and understand. Too many small services can bring a lot of overheads. To create a service, you need to spend additional development time, a service is also a deployment item, communication between services has network overheads. So, you should careful consider all pros and cons of splitting logic into services. Some balance should be found.

Going back to the question if "Users" and "Purchase History" are totally different, they don’t have common logic, can be stored in different databases and both are complicated enough, so you can split them into two services. The same about UI parts. The main thing is that splitting should bring you benefits - not overheads.

About using rest - it’s up to you, rest architecture is not required for microservice architecture but very often they are used together. Rest is about design of your services, how they expose API and so on.

Vasyl Zvarydchuk
  • 3,789
  • 26
  • 37
  • Thanks for the great response. Just one last thing, let's take the users screen as an example. Should the UI be part of the microservice? In that case, should this microservice need to contain a full angular 2 app? – Shaul Zuarets Jan 20 '17 at 15:12
  • 2
    I thing it's better to separate backend and frontend into different parts. In your case you can have Users backend service (rest API) and Users UI app. – Vasyl Zvarydchuk Jan 20 '17 at 16:03
  • Yes, that is the case. The issue is that I have a monolith angular 2 application for the UI. So the question is if the users needs to be a separate angular 2 app or part of the monolith app? – Shaul Zuarets Jan 20 '17 at 18:05
  • Technically it’s possible http://stackoverflow.com/questions/18571301/angularjs-multiple-ng-app-within-a-page and communication between apps is possible too but harder. To do or not – depends on how many common these screens have. It’s hard to give the strict recommendation without looking at code and knowing future project requirements. – Vasyl Zvarydchuk Jan 20 '17 at 18:58