API and a shared API client

Question

We are a startup kind of a project that fired pretty well and as all startups the main goal was to start ASAP. We made our project as a monolith application (PHP) that has 4 sub-applications, but will require more than that in a couple of months. We decided it's time to move to microservices before it's too late, so we try to separate this application into small pieces like:

• API
• CRM
• Workers
• Frontend
• other sub-projects, something between frontend and CRM.

Currently the project is something similar to the MVC (I understand it's not an MVC in PHP, but lets say it's like that). We have Routing, Controllers, Views and on the domain layer we have Repositories & Entities.

Entities are not used as raw value objects, but as well know about their children, let's say if we have a $user entity, it knows how to $user->getArticles() retrieve articles belonging to that user. (It uses repositories here).

Services will communicate using the JSON format and HTTP protocol and not AMQP.

Each service will reside on it's own node, all nodes will be on one network and this question is not about performance so I will not discuss about it any longer.

The problem is that all services must communicate with the API and we would really like to stick to working with entities.

Personally, I think the right way would be to migrate entities to a shared sub-project like APIClient and use that as a composer package in all of the project parts.

Despite that, I think there are many nuances here, like maintaining the correct version of the API client for each project.

Question: What is the proper way to share entity objects and use an API as the only part of the project that communicates with the DB?

Maybe I am overthinking and it's easier to create separate entities for each project, that is, only entities and functionality it needs and make the API Client return only JSON/array/stdClass?

Maybe someone may link to a "success story" on this topic, but PHP related?

_{I really hope I did ask the question clearly. If not, let me explain the parts you didn't understand.}

 

 

Edit: I have drawn this diagram, maybe it will be clearer why I'd like to have entities shared.

  DB
   |
Repository
   |
 Entity ----|
   |        |
  API       |
   |        |
   |        |--------|
[ HTTP ]    | Shared |
   |        |--------|
   |        |
API CLI     |
   |        |
 Entity ----|
   |
do stuff

Answer 1

I'm starting a similar project which involves handling data from diferent clients (administrator, client's intranet, front-end and API)

In my design, me have moved ALL of the logic to a layer called service, which is gonna be instantiated in each off the clients.

We are not comunicating with the service layer throught http, but instantiating the "userService" / "authenticationService" everywhere and on every client that needs it.

All 4 apps are are in the same project so that performance wise it is amazingly fast.

With these structure, the UserController on the front-end app just instatiates the UserService and calls a method like -> UserService->getUser();

The good thing is that none of the client have to care about how to get data, because all logic is mantained in the service.

Not sure if I explained myself well, at least I tried.