Add generated schema for config entities. about graphql HOT 15 CLOSED

I have been playing with configuration entities support and I have two questions.

I see there is EntityUuid field in graphql_core module. However other fields which make use of EntityInterface (which is common to both content and configuration entities) are located in graphql_content instead of graphql_core module, namely: EntityLabel, EntityLanguage, EntityTranslation, EntityBundle, EntityType, EntityUrl. Is there a specific reason to it or can they be moved (as I tested, they work fine without graphql_content module)?

EntityId field is also located in graphql_content module. In my opinion, it could be moved to graphql_core too, however field type and resolver need to change, since currently the field is Int and resolver is using intval on entity ID, causing the configuration entity ID's (which are strings) to be displayed as 0. Was there a reason for allowing only integer value?

from graphql.

You are right. graphql_core is supposed to handle entities in general and graphql_content content entities. We should move them.

You are right with your second suggestion too. But this is a breaking change if somebody uses a strictly typed client. Although I'm not sure entityId is used too often.
@fubhy Any thoughts?

from graphql.

I agree and I consider it a minor Breaking change. In fact, entity ids are not specifically enforced as ints. Not even for Content entities. Lets move it all to Core and change ids to Strings. We use string args for entityById already anyways by the way and its the right Thing to do. We are in Alpha so this change is fine for me. Can you submit a PR?

from graphql.

PR created: #235

from graphql.

has anyone thought about a schema for plain config? I'm going to need some field api info (the set of values for a list field).

from graphql.

This ticket is about exposing plain config entities with typed data. It's just lacking a proper description.

from graphql.

The main problem is that we can't just add all config entity types because it will blow the schema out into space. We need some way to restrict what to expose.

from graphql.

This can continue now that we have got #235 merged. Do you want to work on this @peterkeppert?

from graphql.

Yes, I will create graphql_config module with basic fields and "Exposed config" screen to restrict which configuration entities will be in the schema.

from graphql.

@peterkeppert Awesome! By the way, do you want to join us in the Drupal Slack and the #graphql channel? Philipp and me are both in there and can provide assistance easily whenever needed.

Maybe we should also schedule a call to discuss the architecture for the config support?

from graphql.

I have created PR #299 with a very basic module, which:

• Introduces support for configuration entities (with fields defined by grahql_core module).
• Adds Exposed configuration table, where admin can decide which config entities to expose.
• Allows to retrieve config entity information by ID.
• Ships with basic tests.

Example:

{
  nodeTypeById(id: "page") {
    entityLabel
    entityType
    entityUuid
    entityId
  }
}

There are two issues/questions:

• Only part of configuration is stored as configuration entities and at this moment, module handles only configuration entities. Should module handle both types of configuration?
• Config entities are not fieldable, so data on configuration entities are stored as arrays or attached like standardized objects (e.g. plugins). However GraphQL is strictly typed, which conflicts with the generic array-based storage + the information which is stored differs per entity type, which in my view prevents reasonable generalization. Should we add all the additional fields as entity type-specific?

from graphql.

When you add support for this, take https://www.drupal.org/node/2653358 into account, which https://www.drupal.org/node/2915539 did for the jsonapi module and https://www.drupal.org/node/2915414 for core's rest module.

from graphql.

This is my config field deriver(maybe it has something useful):

<?php

namespace Drupal\foo\Plugin\Deriver;

use Drupal\Component\Plugin\Derivative\DeriverBase;
use Drupal\Core\Config\TypedConfigManagerInterface;
use Drupal\Core\Plugin\Discovery\ContainerDeriverInterface;
use Drupal\graphql\Utility\StringHelper;
use Symfony\Component\DependencyInjection\ContainerInterface;

/**
 * Derives content entity fields as GraphQL fields.
 */
class ConfigFieldDeriver extends DeriverBase implements ContainerDeriverInterface {

  /**
   * Typed config manager.
   *
   * @var \Drupal\Core\Config\TypedConfigManagerInterface
   */
  protected $typedConfigManager;

  /**
   * ConfigFieldDeriver constructor.
   *
   * @param \Drupal\Core\Config\TypedConfigManagerInterface $typed_config
   */
  public function __construct(TypedConfigManagerInterface $typed_config) {
    $this->typedConfigManager = $typed_config;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, $basePluginId) {
    return new static(
      $container->get('config.typed')
    );
  }

  /**
   * {@inheritdoc}
   */
  public function getDerivativeDefinitions($basePluginDefinition) {
    $this->derivatives = [];
    $types = foo_field_types();

    foreach (foo_exposed_config_entities(TRUE) AS $entity_type_id => $entity_type) {
      /** @var \Drupal\Core\Config\Entity\ConfigEntityTypeInterface $entity_type */
      $exportable = array_diff_key(
        $entity_type->getPropertiesToExport() ?? [],
        array_fill_keys(['dependencies', 'third_party_settings', '_core'], '')
      );
      $config_id = $entity_type->getConfigPrefix() . '.*';
      $fields = $this->typedConfigManager->getDefinition($config_id)['mapping'];
      foreach ($fields AS $field_name => $field_definition) {
        $derived_id = $entity_type_id . ':' . $field_name;
        if (isset($types[$field_definition['type']]) && in_array($field_name, $exportable)) {
          $this->derivatives[$derived_id] = [
            'name' => StringHelper::propCase(isset($field_definition['label']) ? foo_untranslated_string($field_definition['label']) : $field_name),
            'type' => $types[$field_definition['type']],
            'parents' => [foo_get_entity_type_name($entity_type_id)],
            'field_name' => $field_name
          ] + $basePluginDefinition;
        }
      }
    }

    return parent::getDerivativeDefinitions($basePluginDefinition);
  }

}

from graphql.

Does expose field types (email, entity reference, text long, list, etc.) and if a field is a required or would I need to keep using the below? Thanks

{
    __type(name:"NodeArticle") {
        fields {
            name
          type {
            name
          }
        }
    }
}

from graphql.

@sebkamil I don't understand your question. Can you open a new issue?

from graphql.