Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are building a Microservice architecture for our projects, with mostly front-end Symfony applications interacting with back-end RESTful APIs.

The problem is this approach is breaking the Symfony entity management relying heavily on Doctrine with database. Where Symfony usually handle entities with Doctrine, automating most of the work, this cannot be reproduced easily when we have to access external data from the APIs.

For example, with a Client entity:

  • Using Doctrine, we just have to define our Client class, and it is now easy to create, update, retrieve our clients
  • Using the REST API approach, clients are accessible through the API, but we have a lot of work to define how the client is created (POST), updated (PUT), retrieved (GET), etc.

To be noted clients are used by several applications, not only the front-end app, hence the dedicated API.

Should we create classes with entity-like methods hiding the API calls complexity, importing all the API data locally and access them through Doctrine, or any other way?

share|improve this question
    
I'm in the same boat as you are. Consuming external API's with clients generated from OpenApi / Swagger specifications. Wondering about best practices for consumption 'life cycle', crud operations, parameters and filter form generation. Currently expanding my search to include any approaches, regardless whether it's Symfony specific or not. – upstream Dec 9 '16 at 15:41

Doctrine is a database access layer. You don't want to access a database, but apis. You can still create an Entity, but then as a simple object that doesn't have to extend our implement anything (a popo). It should have a Repository that implements all the CRUD methods. In this case calls to the API instead of the database. I'd create an interface for that. It doesn't have to feel different for your application to use, except that you must take into account everywhere that a micro service might not respond.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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