Opinions on how to integrate with ORM (Doctrine) ?

[PowerKiKi]

I am looking for advices on how to add graphql to an existing app. The project is currently a quite big Zend Framework 1 application with some jQuery on the client side.

We now need to add new features that are logically quite separated from the legacy code, so we are going to adopt a SAP kind of app with Angular and most likely graphql. And I am still trying to evaluate alternatives on how to do that:

1. Conservative, keep Zend_Db and integrate graphql-php in existing ZF1 controllers. That might be the cheapest way to do it, but we are still kind of stuck in the past, notably with ZF1 being not maintained anymore.
2. Replace Zend_Db with Doctrine to benefit from a better defined model and more flexbility to build dynamic SQL/DQL queries.

If Doctrine is introduced, then there would be a possibility to generate GraphQL schema based on Doctrine entities. That way it might be possible to write one single service that take care of Doctrine-GraphQL conversion and also take care of resolving things automatically.

This is where I would need opinions whether it's a good idea, easy to implement/maintain, to automate Doctrine integration, if realistic at all. This could be done by reusing Doctrine annotations or new custom annotations, as suggested in this issue tracker. Or if it would be best to write boiler plate code to configure GraphQL more manually and hence to keep a better control on GraphQL.

Does anybody has any experience integrating with Doctrine ? Or what about other ORM ?

[vladar]

I'll describe our experience. We had similar problem with ZF1 app, but migrating to Doctrine was not an option, since the app was huge and it would mean almost complete rewrite. So we chose conservative approach.

We added GraphQL to the stack, using existing models (based on Zend_Db_Table). Building types and enabling queries was fast and easy, but mutations were way harder: we had part of the logic in ZF controllers and other part in our busniless logic layer, so moving this to mutations took some time, but we approached them sequentially when needed by new client app.

Then we were able to call mutations in ZF controllers where BC was required. In the end we had GraphQL API in place using most of our old backend logic (old app was still in place, waiting when it's obsolete parts would be removed as we build new client app).

When GraphQL API is in place - it is way easier to rework backend separately, because you effectively have an interface between client and server (which is also easy to test by recording-replaying GraphQL queries). So next time we have a chance - we will consider switching to Doctrine/DBAL.

@mcg-web Do you guys use Doctrine internally? Can you share your experience?

[mcg-web]

Yes @vladar the bundle is compatible with doctrine, we using symfony property access component to ease the work... Here the default resolver (method defaultResolveFn) that is use to do that. Next step is to use directly doctrine schema through a plugging to generate the graphql schema...

[sergiohermes]

https://github.com/rahuljayaraman/doctrine-graphql

[PowerKiKi]

Thanks all for the valuable feedback. I've been very busy the past few weeks migrating from ZF1 to Doctrine. But we have yet to introduce GraphQL (opposite migration order of @vladar's). So we are still open to various implementation suggestions.

@sergiohermes, do you have any kind of documentation and/or example of usage for rahuljayaraman/doctrine-graphql ? How did it benefit your project ? Any downside to it ?

[sergiohermes]

@PowerKiKi , I used the idea of abstraction to build my own, soon create a repository solving this problem can add a huge amount, since I did not see much documentation about, or even implementation.

I find it very valid to use the idea of this repository since it serves as a basis for using dbal's doctrine. It is extremely valid, and I think this project should evolve, since such integration is needed.

I have not used it in production environments but rather to reuse the entities I have and abstracted for the REST concept and after that GRAPH.

I hope to help, strong hug.

[rahuljayaraman]

Hey guys, I'm the author of doctrine-graphql. Thanks, @sergiohermes for mentioning it here & @elvismdev for opening up the issue. I plan to put up documentation & add some crucial features in the next couple of weeks. Will ping back here once it's done. Meanwhile, there's a short overview mentioned in the above issue. Please feel free to ping me with questions or feedback. Cheers!

[rahuljayaraman]

I've updated the readme, please do have a look. Would appreciate feedback/feature requests etc. I'm planning to work on the issues listed here over the next few weeks.

[PowerKiKi]

In the last few weeks, I had a look at rahuljayaraman/doctrine-graphql project. I saw interesting things, but it did not exactly fit my needs and back then it lacked documentation. So I started my own version of bridge between GraphQL and Doctrine. The result is MIT licensed and available at https://github.com/Ecodev/graphql-doctrine.

It significantly diverge from rahuljayaraman/doctrine-graphql in the fact that it relies heavily on PHP 7.1 type hinting, and only fall back to Doctrine annotations when necessary. Therefore it does not expose doctrine fields, but rather all entity getter methods (so in most case that would cover all fields in addition to custom getters). Another important point for me is that the project has a test coverage of 100%.

I encourage you to read the docs and try both packages to see whichever fits best your project.

Finally if you have questions or feeback your are welcome to share those on gitter.

[vladar]

Great works guys. I guess we can close this issue now.

[PowerKiKi]

As a follow-up, we just released 1.0.0: https://packagist.org/packages/ecodev/graphql-doctrine

Going forward we'll at least maintain the existing features for our project. We'll also seriously consider to expose the query builder features through graphql. This would reduce boilerplate in repositories and give more possibilities out of the box for frontend developers.