New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GraphQL Support #3065

Open
julmot opened this Issue Jul 11, 2018 · 21 comments

Comments

@julmot
Copy link
Contributor

julmot commented Jul 11, 2018

I'm currently looking at Pimcore for a decoupled frontend application, usually with React. Until now (with other systems) I've been using GraphQL instead of REST APIs to avoid multiple API calls and only transfer data that I actually need.

Beside of the fact that I don't know if the documented REST API of Pimcore was built for decoupled applications, I haven't found anything about GraphQL.

Therefore, please take this issue as feature request.

@brusch brusch added the New Feature label Jul 18, 2018

@brusch brusch changed the title [Feature Request] GraphQL Support GraphQL Support Jul 18, 2018

@cgpro

This comment has been minimized.

Copy link

cgpro commented Jul 24, 2018

Would be very nice for GatsbyJS :)

@milanbolland

This comment has been minimized.

Copy link

milanbolland commented Jul 30, 2018

That would be awesome!

@ApolloLV

This comment has been minimized.

Copy link

ApolloLV commented Jul 30, 2018

This feature would be very helpful for an application we are currently building, please consider implementing a GraphQL interface.

@brusch

This comment has been minimized.

Copy link
Member

brusch commented Jul 31, 2018

I think that would be quite easy to provide as an additional bundle. Anyone willing to contribute?

@mingfang

This comment has been minimized.

Copy link

mingfang commented Jul 31, 2018

The doc here https://pimcore.com/docs/5.x/Development_Documentation/Web_Services/index.html states

The Pimcore REST API is not intended to be used as a data provider for frontend applications (Vue.js, React, Angular, ...), please build your own actions for that purpose or use any existing bundles.

Has that changed?

If not then is the proposed GraphQL intended for frontend applications?

@brusch

This comment has been minimized.

Copy link
Member

brusch commented Jul 31, 2018

No that hasn't changed, this was already always the case, but obviously not communicated explicitly enough.

GraphQL is designed for frontend applications, yes.

@julmot

This comment has been minimized.

Copy link
Contributor

julmot commented Aug 21, 2018

Since GraphQL isn't supported and the REST API isn't meant for decoupled applications, what do you mean with "React" and "Vue" in this graphic:

https://github.com/pimcore/pimcore/blob/master/doc/Development_Documentation/img/pimcore-technology-architecture.svg

These applications are usually built decoupled, but even vue-storefront is only implemented with another backend with totally separated REST API.

@brusch

This comment has been minimized.

Copy link
Member

brusch commented Aug 21, 2018

@julmot that building custom REST endpoints is very easy

@julmot

This comment has been minimized.

Copy link
Contributor

julmot commented Aug 22, 2018

@brusch Thanks for this clarification 👍 I'm looking forward to this feature. If you need any help from a front-end side, you can let me know.

@brusch brusch added this to To do in 03/09/2018 - 14/09/2018 via automation Sep 3, 2018

@brusch brusch removed this from To do in 03/09/2018 - 14/09/2018 Sep 14, 2018

@brusch brusch added this to To do in 17/09/2018 - 28/09/2018 via automation Sep 14, 2018

@brusch brusch removed this from To do in 17/09/2018 - 28/09/2018 Oct 1, 2018

@brusch brusch added this to To do in 01/10/2018 - 12/10/2018 via automation Oct 1, 2018

@brusch brusch removed this from To do in 01/10/2018 - 12/10/2018 Oct 10, 2018

@brusch brusch added the Prio-Backlog label Oct 10, 2018

@brusch brusch added this to To do in 15/10/2018 - 26/10/2018 via automation Oct 15, 2018

@brusch

This comment has been minimized.

Copy link
Member

brusch commented Oct 30, 2018

UI idea

20181030_154133

@brusch brusch added this to To do in 29/10/2018 - 09/11/2018 via automation Nov 2, 2018

@brusch brusch moved this from To do to In progress in 15/10/2018 - 26/10/2018 Nov 2, 2018

@weisswurstkanone weisswurstkanone moved this from To do to In progress in 29/10/2018 - 09/11/2018 Nov 6, 2018

@brusch brusch added this to To do in 12/11/2018 - 23/11/2018 via automation Nov 7, 2018

@brusch brusch added this to To do in 26/11/2018 - 08/12/2018 via automation Nov 26, 2018

@not4fame

This comment has been minimized.

Copy link

not4fame commented Nov 26, 2018

Hi guys, at Divante we are currently working on graphQl solution for Pimcore, it is still work in progress on quite early stages, but it is already usable for us in less demanding situations. please have a look at it, if You are still interested (solution is based on ClassDefinition, with a recursive approach, for generating type schemas) https://github.com/DivanteLtd/pimcore-graphql

@brusch

This comment has been minimized.

Copy link
Member

brusch commented Nov 26, 2018

@not4fame thank you very much for the hint!
Currently we're just evaluating if we should go with API Platform or directly with Webonyx (which is used by API Platform as well).

@dpfaffenbauer

This comment has been minimized.

Copy link
Contributor

dpfaffenbauer commented Nov 26, 2018

API-Platform 👍

@not4fame

This comment has been minimized.

Copy link

not4fame commented Nov 26, 2018

I'm not quite familiar with API Platform , it looks for me a little bit like overklill (just first impression, it can change), espesially that, in my opinion, our only (except validation, and permissions, which are totally different topics) task, is to map class definitions to correct graphQl schema. Thank You for Your feedback, I will dig more in to the API platform, to have better understanding of it.

@dpfaffenbauer

This comment has been minimized.

Copy link
Contributor

dpfaffenbauer commented Nov 26, 2018

The thing about API-Platform is: it gives you complete freedom over the API you wanna use. Either XML or JSON Responses and you could also finally extend Pimcore's API with custom API's which is currently not really possible (I mean, sure it is, but tricky).

And it also generates nice looking and usable API-Docs.

@dkarlovi

This comment has been minimized.

Copy link

dkarlovi commented Nov 26, 2018

Hello,

I'm a long time API Platform user (there wasn't even a 2.x branch yet when I started) and a rather recent Pimcore user.

I'd like to weigh in here: having API Platform as your outward layer would mean the end user (ie. the developer) would be in full control over the behavior the API has, which is of course very handy.

But also, this means all the benefits API Platform provides are automatically available to Pimcore users.

These are only some of the things APIP gained after I started using it and, by extension, now have access to:

This means Pimcore core team could focus their effort on building Pimcore and not infrastructure supporting it. If you're planning to stay on PHP, API Platform is probably the best API framework available, not just for Symfony.

@dkarlovi

This comment has been minimized.

Copy link

dkarlovi commented Nov 26, 2018

BTW the HTTP/2 + push thing basically makes GraphQL not needed since it allows the server to just push all the required data as separate responses while still keeping all the data cacheable.

@julmot

This comment has been minimized.

Copy link
Contributor

julmot commented Nov 26, 2018

@dkarlovi I'm not sure how this would replace GraphQL? It is intended to not make multiple requests necessary, to reduce data transmission by only responding the actually requested data and reducing development complexity by directly responding in the specified schema.

@dkarlovi

This comment has been minimized.

Copy link

dkarlovi commented Nov 27, 2018

@julmot GraphQL is not without issues and some problems it solves are more easily solved by something else:

not make multiple requests necessary

This is done by HTTP2+push too:

  1. you create the first request GET /foo
  2. server responds with a list, saying you need to GET /foo/1, GET /foo/2, GET /foo/3
  3. but then, it actually sends you those too, as if you've requested them yourself

This allows the app to respond N times for a single request, getting pretty much the same effect, only way better since each additional response can be cached at any level. This means you no longer need to fetch GET /foo/2 again when you click on a link in the listing, you already have it.

reduce data transmission by only responding the actually requested data

GraphQL wins here, for the first request. On average, you transfer less data with the approach described above since it transfers more data per requests, but does less requests overall (since most of them can be cached by you, the server and everything between).

reducing development complexity by directly responding in the specified schema

This is also debatable. I feel GraphQL is like old "no SQL" databases: it's easier to not have any structure which allows you to build your current requirement, but as you add additional requirements, the app at your end gets ever so complex and it turns out the structure actually had some desiredable attributes you wish you had right now. 👍

This and more is described in a series of articles called You Might Not Need GraphQL.

@dpfaffenbauer

This comment has been minimized.

Copy link
Contributor

dpfaffenbauer commented Nov 27, 2018

I agree with @dkarlovi, thats why I also think Pimcore should implement API Platform and not GraphQL directly. That way GraphQL is implemented in a more abstracted way and could be swapped out with a new trendy thing in a few years.

@not4fame

This comment has been minimized.

Copy link

not4fame commented Dec 7, 2018

Hi, guys, I agree that API Platform is a great tool, but in my opinion, without changing DataObjects to use Doctrine it doesn't make too much sense to use it with them. I think it is a great discussion and we should continue with it, but we can also do that:
graphql

@brusch brusch added this to To do in 10/12/2018 - 04/01/2019 via automation Dec 10, 2018

@brusch brusch removed this from To do in 26/11/2018 - 08/12/2018 Dec 10, 2018

@weisswurstkanone weisswurstkanone moved this from To do to In progress in 10/12/2018 - 04/01/2019 Dec 21, 2018

@brusch brusch added this to To do in 07/01/2019 - 18/01/2019 via automation Jan 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment