Next steps for GraphQL and Drupal
In the last three blog posts, you learned about the current palette of features of the GraphQL module and how you can further extend and adapt it according to your needs. In this blog post, we want to shed some light on our future plans for the of the module and show you where we are headed and how you can get involved.
Currently, we only support Content Entities within our Schema. There are multiple reasons for this. The most important, however, is quite simply explained: We wanted to focus our energy on the parts of the Schema that seemed most important to us, which are Content Entities. However, with Content Entities there are also technical challenges to overcome. Exposing the whole configuration data graph in our Schema would inflate our Schema by a significant margin. Hence, we will need a user interface and a configuration structure (inception) to allow users to choose which parts of the configuration should be exposed. As a first step, we will focus on exposing Configuration Entities only.
Expand support for Views
While we do already support Views through a special Display Plugin that allows for reuses of the existing schema for any exposed any entity types we currently do not support custom field configuration in Views. This means that currently, you cannot leverage the full flexibility of field based displays in Views. We are planning to add this capability to the Views integration module. Each View configured this way would generate its own type within the Schema where every configured field would simply be exposed as a string.
Improve Test Coverage
While we already do have relatively good test coverage compared to most contribute Drupal modules, we want to further improve on this. Philipp wrote a significant amount of test cases for the various integration modules (a round of applause for that). However, big and important parts of the core APIs of the base GraphQL module are currently not covered by any tests. There are various issues in our issue queue which aim to address this problem. Recently, we’ve also added test coverage reports. If you are interested in lending a helping hand to work on this, just find a part of the code base that is currently not tested and add a test case for it.
Expose Actions as Mutations
Drupal has a Core concept for Actions. While the Trigger module has been removed during the Drupal 8 release cycle, the concept of Actions and the backing code is still sitting around in Core. Exposing Actions should be a fairly simple undertaking and would allow us to expose a range of simple and specialized mutations instead of having to write custom Mutations using our internal APIs and adding the to the schema manually.
Expose Rules components as Mutations
This is another exciting feature I am looking forward to. Adding configured Rules components as Mutations would allow site builders to quickly configure and expose fully customized operations of any sort. This feature would prove especially useful to create more specialized
Mutations where exposing the full Schema of the underlying model would add unnecessary weight to the Schema or complicate the implementation on the consumer side. This feature is planned for the future but currently not on the roadmap for our first stable release.
Add a full graph based configuration interface and schema
This is by far the most exciting gem on our long term roadmap. More on this in a separate post.
First stable release
We are going to work on stabilizing the module further while also working on some of the aforementioned features during the upcoming days and weeks. We’ve scheduled the release of the first stable version of the module for the 25th of September. This is one day before the official start of DrupalCon Vienna and the day on which Philipp and I will be presenting about the GraphQL & Drupal Lovestory at the Drupal Publishing Summit.
Let’s talk about it in Vienna
Both Philipp and I are going to attend DrupalCon, at least partly. Sadly, I have to head back to Zurich on Tuesday, 26 September already. Philipp, however, is going to be around for the whole conference. If you are interested in chatting with us about GraphQL, React or Decoupled Drupal in general, feel free to get in touch!
We are always looking for fresh contributors who are equally excited about GraphQL as we are. If you are interested in helping out with code, documentation or otherwise, please get in touch. You can find us on GitHub or in the Drupal Slack community in the #graphql channel. We are also likely going to host and moderate a code sprint at DrupalCon.