Add graphQL as an API option

[pixelmord]

As discussed already in slack #contenta, it would be good to also provide alternative APIs for a proper demo of an API first Drupal.
GraphQL would be a good candidate to be provided as alternative to jsonAPI, because it is widely adopted and is opinionated in a different way.

What I can tell from the discussion in the channel is that it would make sense to integrate that into contenta as an OPTION so people can choose to use this alternative.
However it makes sense to not open a separate distribution/install profile project because a lot of the API agnostic does not make sense to be duplicated.

I would like to start a discussion on how to best integrate that in this issue and will then at least kick off development in a PR that goes with that.

[dawehner]

Thank you for opening an issue. Its important to have this discussion!

Maybe we should put all the graphql integration into a module, contenta_graphql, you enable, and you get the experimental feature.

As a starting point I get this module would just contain all the submodules of the graphql module, you actually need. Contenta should make this easier!

[dawehner]

Earlier @fubhy mentioned https://apis.guru/graphql-voyager/ we could maybe include as well.

[pixelmord]

I know I might be sticking my arm into a bees nest, but it might be important to get that discussion out of the way:
What if somebody is wanting to use contenta only with graphQL and disable jsonAPI? Would that be possible? Would jsonAPi also be encapsulated into one module (that could be potentially disabled)?
Would than the name contenta_jsonapi still be the best and not contentaCMS?
That also raises another question: What about the tutorial content? It would need to be amended with tutorials for graphQL as well and also here the question would be on how to organize that in a SANE and SIMPLE way.
I really do not want to complicate things, but from project work with our client projects I know that this is better thought through early to not later regret and refactor.
Let me know what you think! @e0ipso @dawehner

[dawehner]

I think these are all questions which should be answered over time, which is why I like labeling graphql support as experimental first. Then we can iterate over time.

For the knowledge hub for example we could tag the tutorials by #jsonapi/#graphql and by that provide some nice filter mechanism.

[fubhy]

@dawehner I think we should add voyager (or something custom, it's actually easy to build yourself!) to the graphql module itself. Much like we have "graphiql" in there too.

[dawehner]

Fair point :) I'm cool with whatever works. To be honest, I think graphiql is actually more useful on a day to day base, while voyager gives you an initial overview

…

On Tue, 4 Jul 2017 at 15:05 Sebastian Siemssen ***@***.***> wrote: @dawehner <https://github.com/dawehner> I think we should add voyager (or something custom, it's actually easy to build yourself!) to the graphql module itself. Much like we have "graphiql" in there too. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#101 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABz7tk0ASC5_LEWU67Uz22nObGi8K-dks5sKkaTgaJpZM4ONR9O> .

[e0ipso]

For the knowledge hub for example we could tag the tutorials by #jsonapi/#graphql and by that provide some nice filter mechanism.
👍 2

Filters are in place now for tutorial topics. However the topic is a text list, and we should add a GraphQL option there. @pixelmord can you create an issue to add GraphQL as an option for a topic in a tutorial node?

[e0ipso]

@dawehner I think we should add voyager (or something custom, it's actually easy to build yourself!) to the graphql module itself. Much like we have "graphiql" in there too.
👍 2 🎉 1

That's great to hear @fubhy! Is there any issue you have to track that? I'm sure someone can create one if not.

[pixelmord]

Here is the branch of my fork that at this moment just requires the graphQL module:
https://github.com/pixelmord/contenta_jsonapi/tree/feature/101_contenta_graphql

[pixelmord]

Regarding GraphQL voyager:
See this PR against the graphql module with a very basic POC implementation of it: drupal-graphql/graphql#190

[fubhy]

Voyager has been merged.

[tarekdj]

So what's the plan for GraphQL integration? And how can I help?

[pixelmord]

Hi, I got totally blocked by client work and will be until late november. So far I did nothing but a custom module that requires GraphQL and its submodules and added that to the contenta profile. So basically nothing much more that anybody would do to switch on GraphQL....
In my mind the roadmap would be sth like this:

• select the minimum of the submodules that would be needed to get feature parity with what jsonAPI gives us for contenta and require those with an optional custom module added to contenta profile
• Look into creating graphQL plugins that would make querying the data special to the umami use case a bit more convenient.
• Integrate with the other parts of contenta like Oauth etc.

But @tarekdj and every body else that wants to contribute just go ahead and do what you can, I will see that I can join your efforts later this year!

[tarekdj]

Clear! Thank you @pixelmord !

[e0ipso]

One of the things I'd like to come out of this investigation is if we can have a zero-config GraphQL server for our entity system. Much like jsonapi is zero-configuration.

[tarekdj]

@e0ipso sounds good for me

[tarekdj]

#195 Ready for review

[tarekdj]

@e0ipso any update on #195 ?

[e0ipso]

@tarekdj still some work to do. Please check the comments there.

[tarekdj]

@e0ipso thanks for the review. I understand your point and I update PR soon.
Thanks

[fubhy]

We are done with most of our refactoring now and simplified the module drastically. We deprecated a lot of the submodules and made the module zero-config by default. We are adding a new configuration screen with optional configuration to fine-tune and narrow down the schema later but that won't affect the module's API anymore. You should be good to go now. I am publishing 8.x-1.0-alpha-8 as I am writing this and we are going into beta this week.

[wimleers]

I met with @fubhy and @pmelab at DrupalCon Vienna. We discussed my criticism/feedback that the GraphQL module needed to become simpler. Because for:

• this to be usable by Drupal users that aren't experts
• this to eventually be committable to Drupal core
• this to be maintainable

this simplification was IMHO essential. (See acquia/reservoir#59 (comment) for the detailed original concerns.)

@fubhy and @pmelab took this feedback and then made an incredible push forward.

I'm happy to say that in alphas 7 and 8, they addressed all of the above: https://twitter.com/wimleers/status/922472920626204673. This also came up during Monday's API-First Initiative meeting. During that meeting, @e0ipso also confirmed those same concerns: that's the reason why Contenta hadn't yet adopted GraphQL (this issue). (I think @e0ipso was referring to #101 (comment) in particular.)

And just a few hours ago, they released https://www.drupal.org/project/graphql/releases/8.x-3.0-beta1 — which further cleaned things up!

The situation today is:

• no more special "GraphQL" view mode to be configured for every entity type + bundle, instead it respects the TypedData definition
• after installing, you should be immediately able to make GraphQL queries
• no more dozen separate modules to install (for BC, https://github.com/drupal-graphql/graphql-legacy exists): just install graphql + graphql_core (the latter to implement various plugins on behalf of core modules)
• rather than having one monster module with lots of submodules for various edge cases, move those submodules into their own projects. Especially because they would take a very long time to become stable, if ever. Separate modules now exist for graphql_xml, graphql_json, graphql_twig and graphql_views

Very exciting!

[handrus]

shouldn't we close this issue already? I guess #195 solved it.

[e0ipso]

Yes @handrus, you were right!