SOLID

Gato GraphQL stosuje podejście SOLID w architekturze oprogramowania, dostarczając różne encje do obsługi różnych odpowiedzialności, aby kod był łatwy w utrzymaniu, rozszerzalny i zrozumiały.

W ten sposób encja użytkownika jest już dostarczana przez wtyczkę. Typ User jest dostarczany za pomocą tego kodu:

class UserTypeResolver extends AbstractTypeResolver
{
  public function getTypeName(): string
  {
    return 'User';
  }
 
  public function getSchemaTypeDescription(): ?string
  {
    return $this->translationAPI->__('Representation of a user', "users");
  }
 
  public function getID(object $user)
  {
    return $this->usersAPI->getUserId($user);
  }
 
  public function getTypeDataLoaderClass(): string
  {
    return UserTypeDataLoader::class;
  }
}

Type resolver nie ładuje bezpośrednio obiektów z bazy danych, lecz deleguje to zadanie do obiektu TypeDataLoader (w powyższym przykładzie, z klasy UserTypeDataLoader).

Dodanie pól username, email i url do typu User odbywa się za pomocą obiektu FieldResolver z tym kodem:

class UserFieldResolver extends AbstractDBDataFieldResolver
{
  public static function getClassesToAttachTo(): array
  {
    return [
      UserTypeResolver::class,
    ];
  }
 
  public static function getFieldNamesToResolve(): array
  {
    return [
      'username',
      'email',
      'url',
    ];
  }
 
  public function getSchemaFieldDescription(
    TypeResolverInterface $typeResolver,
    string $fieldName
  ): ?string {
    $descriptions = [
      'username' => $this->translationAPI->__("User's username handle", "users"),
      'email' => $this->translationAPI->__("User's email", "users"),
      'url' => $this->translationAPI->__("URL of the user's profile in the website", "users"),
    ];
    return $descriptions[$fieldName];
  }
 
  public function getSchemaFieldType(
    TypeResolverInterface $typeResolver,
    string $fieldName
  ): ?string {
    $types = [
      'username' => SchemaDefinition::TYPE_STRING,
      'email' => SchemaDefinition::TYPE_EMAIL,
      'url' => SchemaDefinition::TYPE_URL,
    ];
    return $types[$fieldName];
  }
 
  public function resolveValue(
    TypeResolverInterface $typeResolver,
    object $user,
    string $fieldName,
    array $fieldArgs = []
  ) {
    switch ($fieldName) {
      case 'username':
        return $this->usersAPI->getUserLogin($user);
 
      case 'email':
        return $this->usersAPI->getUserEmail($user);
 
      case 'url':
        return $this->usersAPI->getUserURL($user);
    }
 
    return null;
  }
}

Jak można zauważyć, definicja pola dla schematu GraphQL i jego rozwiązanie zostały podzielone na szereg funkcji:

getSchemaFieldDescription
getSchemaFieldType
resolveValue

Inne funkcje obejmują:

getSchemaFieldArgs: do deklarowania argumentów pola (w tym ich nazwy, opisu, typu oraz tego, czy są obowiązkowe)
isSchemaFieldResponseNonNullable: do wskazania, czy pole jest non-nullable
getImplementedInterfaceClasses: do definiowania resolverów dla interfejsów implementowanych przez pola
resolveFieldTypeResolverClass: do definiowania type resolvera, gdy pole jest połączeniem
resolveFieldMutationResolverClass: do definiowania resolvera, gdy pole wykonuje mutations

Ten kod jest bardziej czytelny niż wtedy, gdy cała funkcjonalność jest realizowana za pomocą jednej funkcji lub tablicy konfiguracyjnej, co ułatwia implementację i utrzymanie resolverów.