2

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

  • Thanks for sharing, I do something similar like the services you have mentioned but I have called them an APIClient in my question. The point of the question is how can you share real objects with all their behaviour if they're transmitted by HTTP - I know about serialize() & unserialize(), but they don't do the job well in this case as they may have different implementations in one point in time if you don't deploy ALL projects at the same time. – Sergey Telshevsky Nov 10 '15 at 9:27
  • That was a point when I was designing my schema as well, we finally decided that the best way really is not to share the data from the service thought HTTP. I'm unsure about why you really need that service to share about throught HTTP, but I would recommend that you think about the advantages of having the service layer inside of this application. My team did not find a optimal way of making a external service layer and making HTTP request to get data – Borjante Nov 10 '15 at 9:36
  • the whole point of HTTP is to have each of the services on a separate node, that's the real point of microservices, really, to have them separated as much as possible. When you keep everything on one node and in one project, it's still a monolithic application with the only thing being really separated is the class tree. – Sergey Telshevsky Nov 10 '15 at 9:50
  • That's kind of an overhead in my opinion, the best way to send data to and from an Service with HTTP is JSON, you already knew it I guess. There is no other magic way I think. – Borjante Nov 10 '15 at 9:53
  • there are, and yes, it's an overhead. This is not the point of the question. The point is to have consistent objects before and after transfer. – Sergey Telshevsky Nov 10 '15 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.