Get rid of `t3n/graphql` dependency

Flowpack / media-ui

The development repository for the new Neos media management interface

GNU General Public License v3.0

21 stars 16 forks source link

Get rid of `t3n/graphql` dependency #120

Open bwaidelich opened 2 years ago

bwaidelich commented 2 years ago

The t3n/graphql package offers some great tools, especially to get started. But it has some slight drawbacks:

Incompatibilities with current packages (e.g. webonyx/graphql-php ~0.13 vs 14.11.5, via t3n/graphql-tools)
Increased complexity and source of possible bugs
Limited options for (performance) optimizations

For the Media UI package it should be enough to create a really slim layer over (a recent version of) webonyx/graphql-php

Sebobo commented 2 years ago

Sounds great. In the beginning we thought introducing a GraphQL package to the core would also increase usage and more 3rd party GraphQL apis via community packages. We should still keep that in mind a bit.

jonnitto commented 2 years ago

Another point is that the media-ui cannot be tested and used with PHP 8 because t3n/graphql-upload is set to PHP ^7.3

mhsdesign commented 2 years ago

Core GraphQL sounds amazing, but is also not easy to maintain i can imagine

bwaidelich commented 2 years ago

From Slack:

FYI: I think https://graphqlite.thecodingmachine.io/ could be a good replacement for the GraphlQL libraries. It's a layer on top of webonyx/graphql-php that allows to use PHPs type system and annotations to create GraphQL schema and resolvers. I experimented a bit with it and we need some glue code to make it play nicely with Flow. That could go into some kind of small "Neos bundle" package. I'll test some more, but if anyone is interested in a discussion.. anytime! For now I'll try to add that glue code to the flowpack/media-ui package (...) to see if it really works out in practice

bwaidelich commented 2 years ago

The "graphqlite.thecodingmachine.io"-approach didn't really work out for me because:

it comes with quite a lot of additional boiler plate
it's meant to be used as code-first approach
it uses runtime reflection to detect implementation classes

My current idea would be a package that generates PHP classes (i.e. value objects) for a given schema file and the minimal glue code. This should be fairly simple(tm) in general. But it would be nice of course if the generated code could be edited and re-generated without losing changes (maybe with the help of https://getrector.org/)

I currently don't get around working on that, but I didn't forget about this issue.

bwaidelich commented 1 year ago

FYI: In the meantime I have completely rewritten Wwwision.GraphQL It follows a different approach than described above by going a PHP-first approach, but it might be a good fit anyways. I hope that I can give it a go at some point, but please don't rely on it as I still have to iron out some things first

kdambekalns commented 5 months ago

I just opened https://github.com/t3n/graphql-tools/issues/49 when I realized the transitive dependency on webonyx/graphql-php is horribly outdated (~0.13 – current is 15.12)…

Sebobo commented 5 months ago

I actually wanted to check how much effort it would be to switch from GraphQL to REST again. The PHP side should be manageable, but in the JS part I would have to check how well the Apollo RestAdapter works.