This gives us the possibility to request a page from a route without knowing if it is an article or a channel for example. The Page interface is for all Drupal entities that have a URL, in Thunder that could be nodes, terms, users and similar. We introduce three main interfaces for which interfaces covering all main data types used in Thunder. To get the actual data, you will have to do a route query first, to get the information on what kind of entity you are looking at (plus its ID), and then you would have to do a specific node, term or user query to get the actual page. Usually you just have some URL string, that could be a route to a node, a user, a term or any other entity. This sounds not very likely, and for actual fields it should not happen, but sometimes even plugin names are used to create the schema, and plugins could be exchanged (we had an example of a views-plugin, that was exchanged).įinally, routing with those automated APIs is very often a process that requires two requests, instead of one. Second, since field names are automatically generated out of the machine name, the API would change, as soon as you change the machine name. In GraphQL 3 we have entityUuid instead of uuid and fieldMyField instead of just myField. This leads to two separate problems: First, field names are awkward and again very Drupal specific. The referencing goes unconventionally deep in this case: If you wanted to get the src attribute of an image in such a paragraph, you would have to dereference Article => Paragraph => Media Entity => File Entity (src).Īnother pain point is, that field names are automatically created. For example, we use media entities for images in paragraphs. Especially when working with paragraphs and media entities, you would have to be aware of the entity references to get to the actual data. A consumer would have to know the relationships of entities within Drupal. So why did we manually implement an API? While it is very convenient to have schemas automatically created, it also leads to an API that is very close to the structure of Drupal. Both modules expose all data structures from Drupal as they are. Similarly, version 3 of the GraphQL module is as quickly usable. # Motivation to go with GraphQL 4ĭrupal core provides already a turn-key implementation for JSON-API, which basically just needs to be enabled and configured, and it is good to go. A good starting point for this is the official GraphQl documentation open in new window. To get most of this documentation, you should have a basic understanding of what GraphQL is, and how to do requests against GraphQL endpoints. Instead, it provides the ability to define a schema independent of the underlying Drupal installation, and utilities to map fields defined in that schema to data from Drupal. Version 4 of the GraphQL module does not provide an out-of-the-box API for Drupal, as previous versions did. The thunder_gqls module provides a GraphQL API schema and implementation for Thunder based on the Drupal GraphQL module version 4.
0 Comments
Leave a Reply. |