Logo
Internal GraphQL Server
Internal GraphQL ServerInternal GraphQL Server

Internal GraphQL Server

Included in the “Power Extensions” bundle

To rozszerzenie instaluje wewnętrzny serwer GraphQL, który może być wywoływany w Twojej aplikacji przy użyciu kodu PHP.

Między innymi możesz wyzwolić wykonanie queries GraphQL za każdym razem, gdy wystąpi jakieś zdarzenie, aby wykonać powiązane zadanie (np. wysłanie powiadomienia, dodanie wpisu do logu, walidacja warunku itp.).

Opis

Dostęp do wewnętrznego serwera GraphQL odbywa się przez klasę GatoGraphQL\InternalGraphQLServer\GraphQLServer, za pomocą trzech metod:

  • executeQuery: Wykonuje queries GraphQL
  • executeQueryInFile: Wykonuje queries GraphQL zawarte w pliku (.gql)
  • executePersistedQuery: Wykonuje utrwalone queries GraphQL (podając jego ID jako int lub slug jako string) (wymagane jest rozszerzenie Persisted Queries)

Oto sygnatury metod:

namespace GatoGraphQL\InternalGraphQLServer;
 
use PoP\Root\HttpFoundation\Response;
 
class GraphQLServer {
  /**
   * Execute a GraphQL query
   */
  public static function executeQuery(
    string $query,
    array $variables = [],
    ?string $operationName = null,
    int|string|null $schemaConfigurationIDOrSlug = null,
  ): Response {
    // ...
  }
 
 
  /**
   * Execute a GraphQL query contained in a (`.gql`) file
   */
  public static function executeQueryInFile(
    string $file,
    array $variables = [],
    ?string $operationName = null,
    int|string|null $schemaConfigurationIDOrSlug = null,
  ): Response {
    // ...
  }
 
 
  /**
   * Execute a persisted GraphQL query (providing its object
   * of type WP_Post, ID as an int, or slug as a string)
   */
  public static function executePersistedQuery(
    WP_Post|string|int $persistedQuery,
    array $variables = [],
    ?string $operationName = null
  ): Response {
    // ...
  }
}

Aby wykonać queries GraphQL i uzyskać treść odpowiedzi:

// Provide the GraphQL query
$query = "{ ... }";
 
// Execute the query against the internal server
$response = GraphQLServer::executeQuery($query);
 
// Get the content and decode it
$responseContent = json_decode($response->getContent(), true);
 
// Access the data and errors from the response
$responseData = $responseContent["data"] ?? [];
$responseErrors = $responseContent["errors"] ?? [];

Obiekt Response zawiera również wszystkie wygenerowane nagłówki (np. jeśli zastosowano Cache Control List, zostanie dodany nagłówek Cache-Control):

$responseHeaders = $response->getHeaders();
$responseCacheControlHeader = $response->getHeaderLine('Cache-Control');

Należy pamiętać, że klasa GraphQLServer nie jest gotowa przed hookiem init rdzenia WordPress.

Konfiguracja schematu

Internal GraphQL Server stosuje własną konfigurację schematu. Na przykład domyślna konfiguracja jest wybierana na stronie Ustawień, w zakładce "Internal GraphQL Server".

Konfigurowanie Internal GraphQL Server w Ustawieniach

Ta konfiguracja ma zastosowanie również wtedy, gdy query wykonane względem internal GraphQL server zostało wyzwolone przez inne queries GraphQL podczas rozwiązywania w endpoincie z inną konfiguracją (np. publicznym endpointem graphql/).

Dla ilustracji: załóżmy, że skonfigurowaliśmy pojedynczy endpoint graphql/ tak, aby stosował Access Control List do walidacji użytkowników po IP, i wykonujemy mutację createPost względem tego endpointu:

mutation {
  createPost(input: {...}) {
    # ...
  }
}

W związku z tym tylko odwiedzający z tego adresu IP będą mogli wykonać tę mutację.

Następnie istnieje hook na publish_post, który wykonuje queries względem internal GraphQL server (np. w celu wysłania powiadomienia do administratora witryny):

add_action(
  "publish_post",
  fn (int $post_id) => GraphQLServer::executeQuery("...", ["postID" => $post_id])
);

To queries GraphQL zostanie rozwiązane przy użyciu konfiguracji schematu zastosowanej do internal GraphQL server, a nie do pojedynczego endpointu graphql/.

W rezultacie walidacja po IP użytkownika nie nastąpi (chyba że ta Access Control List została również zastosowana do internal GraphQL server).

Debugowanie problemów

Aby śledzić wykonanie queries, możemy przeglądać logi.

Sprawdź Rozwiązywanie problemów, aby uzyskać więcej szczegółów.

Przykład

W tym przykładowym przepływie pracy (który wykorzystuje również moduły Multiple Query Execution, Helper Function Collection i Field to Input), gdy na witrynie zostanie utworzony nowy post, wysyłamy powiadomienie do użytkownika administratora.

Podpinamy się pod akcję rdzenia WordPress new_to_publish, pobieramy dane z nowo utworzonego posta i wywołujemy GraphQLServer::executeQuery:

add_action(
  'new_to_publish',
  function (WP_Post $post) {
    if ($post->post_type !== 'post') {
      return;
    }
    // Check the contents of the query below
    $query = ' ... ';
    $variables = [
      'postTitle' => $post->post_title,
      'postContent' => $post->post_content,
    ]
    GraphQLServer::executeQuery($query, $variables, 'SendEmail');
  }
);

...z tym queries GraphQL:

query GetEmailData(
  $postTitle: String!,
  $postContent: String!
) {
  emailMessageTemplate: _strConvertMarkdownToHTML(
    text: """
 
There is a new post on the site: 
 
**{$postTitle}**:
 
{$postContent}
 
    """
  )
  emailMessage: _strReplaceMultiple(
    search: ["{$postTitle}", "{$postContent}"],
    replaceWith: [$postTitle, $postContent],
    in: $__emailMessageTemplate
  )
    @export(as: "emailMessage")
}
 
mutation SendEmail @depends(on: "GetEmailData") {
  _sendEmail(
    input: {
      to: "admin@site.com"
      subject: "There is a new post"
      messageAs: {
        html: $emailMessage
      }
    }
  ) {
    status
  }
}