Motivation for having to specify the schema yourself

[angry-dan]

Hello - I wonder if you could provide a bit more context for the decision from version 3 - > 4 to switch the architecture to one that requires developers to specify their own schema?

I've done a couple of headless Drupal builds in the past 12-18 months and for both of them we ended up rolling our own GraphQL implementation, but I think we've have found this module significantly more compelling if it was providing an API out of the box. A number of other CMS'es are doing this these days: https://craftcms.com/docs/3.x/graphql.html, https://our.umbraco.com/documentation/Umbraco-Heartcore/API-Documentation/GraphQL/ and https://prismic.io/docs/technologies/intro-to-the-graphql-api are all examples where the CMS is opinionated and generates the schema for you.

Do you have any thoughts on how people should get an automatically generated schema? Is it an ambition for this project to bring them back perhaps? Or do you think there's a space for another GraphQL module to live alongside this one in the Drupal contrib space?

[Kingdutch]

I wasn't involved in making the v4 module but I've provided some of my thoughts on why I think it's a good thing here: https://github.com/drupal-graphql/graphql/issues/1021#issuecomment-644608443

There's also already some more discussion on what you're asking in that ticket :)

[MurzNN]

Our project, that uses Drupal GraphQL 3.x actively, now is in moving from Drupal to Keystone CMS because lacking of automatic GraphQL schema generation support in 4.x

In Keystone we just describe the entity schema, all other (queries and mutations) are generated automatically.

[jmolivas]

Adding my reply/comment originally posted here https://github.com/drupal-graphql/graphql/issues/1021#issuecomment-1060820017

I decided to give a try this weekend and took one of the the examples at the GraphQL module to programmatically register queries and resolvers and so far I was able to:

• Write a DataProducer Plugin that take advantage of a Plugin Derivative to register multiple DataProducer plugins depending on the number of ContentTypes on a site
• Programmatically register queries (singular & plural) for multiple ContentTypes
• Programmatically register resolvers for Connections on those ContentTypes
• Programmatically register resolvers for multiple Fields within a ContentType using addFieldResolver and providing support for composing Producers.

NOTE: I did hardcoded an Array containing the data that was used for the automation mentioned below :point_up:

What will be next?

• Find a way to get all the required data from Drupal via _entitytype.manager, _entityfield.manager and/or from the SDL definition using directives.
• Take advantage of some code at _socialgraphql from OpenSocial and use it programmatically.

[laurencefass]

I closed https://github.com/drupal-graphql/graphql/issues/1285 to follow this conversation.

[Kingdutch]

For anyone else coming across this. @jmolivas published his work on this in https://www.drupal.org/project/graphql_compose

[ayalon]

Because we heavily depend the auto generated schema of GraphQL 3, we decided to implement our own schema generator for GraphQL 4. It does not rely on intermediate "twig template" generation and things like GraphQL Compose. It is fully configurable with an UI. You can choose which entity to expose and which fields. It support a lot of special cases and related related modules and can selectively expose entities and fields and their configuration. You can have a look at it here: https://www.drupal.org/project/graphql_core_schema