Answer the question
In order to leave comments, you need to log in
How to properly divide a project into microservices or services?
Hey! There is a project-monolith. So far, it consists of logical, separated blocks: CRM and User. As an experience, I want to try to split this project into services using Docker. The code is divided into folders, so moving it to a separate application (service) is not difficult. However, I do not know how to do it correctly in terms of architecture and domains.
Using the toaster, I have long noticed that it has a single authorization center for several services that have recently become one, separated by domains. This is about what I want.
My entire Backend is on Symfony 4.4. For frontend I use Vue.
I see the implementation of the plan as follows:
1. The main UI site.ru is being created, where all the information is placed and with the help of this UI we get into the services. (separate application on VUE)
2. UI interface for a single authorization center, profile and user management. Placed on the account.site.ru subdomain (a separate application on VUE)
3. API for a single authorization center, profile and user management. It is placed on the api.account.site.ru subdomain (a separate application on Symfony) in the public API folder, we place the documentation that will be available at api.account.site.ru/docs
4. UI interface for working in CRM. Placed on the subdomain crm.site.ru (separate application on VUE)
5. API for working in CRM. Placed on the subdomain api.crm.site.ru(a separate application on VUE) in the public API folder we place the documentation that will be available at api.crm.site.ru/docs
Tell me, how correct is this architecture? Do APIs need separate domains? Or split everything a little differently: crm.site.ru , crm.site.ru/api/docs , crm.site.ru/api ? If there are useful links - I will be very grateful. Well, if there is a ready-made example on Github - just super! Thanks for the help)
PS: I do the division into services for experience on an existing project. Therefore, I will forgive you not to ask about the load and expediency. About Microservices in general, I read articles on Habré and other sources. I present the pros and cons of such an architecture. The goal is to learn.
Answer the question
In order to leave comments, you need to log in
The task is to practice on a test application? It will be difficult with such a task, you are doing everything blindly, not knowing the real cases that happen in real applications.
But in any case, you didn’t divide into microservices - as a backend, it remained as a monolith as it was (point 3).
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question