🥊 Gato GraphQL vs WPGraphQL: 대결!

2024년 05월 01일 업데이트: Gato GraphQL vs WPGraphQL 비교를 확인해 보세요.

신사 숙녀 여러분.

경기 발표

세기의 대결이 펼쳐지는 MGM 그랜드 가든 아레나에 오신 것을 환영합니다! 오늘 밤, 우리는 역사를 만들어 갑니다. 두 젊은 파이터가 링 위에서 맞닥뜨려, 이토록 열심히 싸워온 그 상을 놓고 겨룹니다:

"WordPress의 GraphQL" 세계 챔피언 🏆 의 타이틀을 차지하기 위해

오른쪽 코너에는 현 챔피언이 있습니다. 이제 겨우 4살이지만 이미 풍부한 경험을 갖추고 있으며, 최근 버전 1.0에 도달하여 wp.org 디렉터리에 게시되었고, 대중들에게 매우 인기가 높습니다.

🥁 뜨거운 🥁 박수로 🥁 맞이해 🥁 주세요오오오 🥁 ...... WPGraphQL!

현 챔피언, WPGraphQL

왼쪽 코너에는 도전자가 있습니다. 세상에 나온 지 겨우 한 달이 되었지만 에너지 넘치고 야심 차며, 첫날부터 자신의 강점을 뽐내고 있습니다. 오늘의 대결을 요청한 것도 바로 그였습니다. 오늘 밤이 그의 기회이며, 전 세계가 주목하고 있습니다.

🥁 뜨거운 🥁 박수로 🥁 맞이해 🥁 주세요오오오 🥁 ...... Gato GraphQL!

도전자, Gato GraphQL

오늘 밤, 두 선수는 처음으로 얼굴을 맞대며 12라운드 경기를 치릅니다. 링 중앙에 자리를 잡고 개시 벨을 기다리면서, 서로를 살피며 상대방의 약점을 찾으려 합니다. 그러나 두 선수 모두 자신감 넘치는 표정을 보일 뿐입니다.

두 용사가 서로를 탐색하다

누가 승리할까요? WPGraphQL이 지지자들의 응원을 바탕으로 우위를 유지할까요? 아니면 신참 Gato GraphQL이 방심하고 있던 대중을 놀라게 하며 군중을 자기편으로 만들까요?

오늘 밤, 여러분, 우리는 그 답을 알게 될 것입니다.

베팅하세요. 그리고 경기를 즐기세요!

🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣

최근 저의 플러그인인 Gato GraphQL과 WPGraphQL의 차이점을 설명해 달라는 요청을 받았습니다.

두 플러그인 모두 WordPress용 GraphQL 서버이므로 같은 목적을 수행합니다. 하지만 내부적으로는 서로 다른 특성을 가지고 있어, 특정 요건을 충족하는 데 있어서 하나가 다른 하나보다 더 나을 수 있습니다.

제 플러그인에 편향이 있다는 것을 인정하지만, GraphQL과 WordPress 모두에 중요하다고 생각하는 주제를 바탕으로 공정한 비교를 하려고 노력했습니다. (다른 주제에 대한 비교를 원하시면 기꺼이 응해 드리겠습니다.)

이 비교는 완전하지 않습니다. 예를 들어, 두 서버에서 동일한 GraphQL 쿼리를 처리하는 속도를 측정하는 벤치마크도 하고 싶습니다. (독자 여러분이 이 제안에 흥미를 느끼신다면, 다음 글에서 다룰 수 있습니다.)

비교를 4개의 주요 영역으로 나누었습니다: 인기도, 코드 스타일과 표준, 핵심 사안, 범위 확장. 각 영역에 3개의 항목이 있어 총 12개의 "라운드"가 됩니다. 마지막에 심판이 판정을 내려 챔피언을 가립니다.

아래를 클릭하여 특정 주제로 바로 이동하세요:

인기도
코드 스타일과 표준
인터미션
핵심 사안
범위 확장
판정!

🔔 딩 🔔 딩 🔔 딩~...

개시 벨이 울렸습니다...

경기가 시작되었습니다!

코드 스타일과 표준

코드 이야기를 해 봅시다!

GraphQL을 사용하고 있다면, 아마도 헤드리스 WordPress를 하면서 JavaScript 프레임워크를 사용하여 웹사이트를 렌더링하고 있을 것입니다. 그것은 모던한 패러다임입니다. 게다가 WordPress는 오래된 CMS일지 모르지만, GraphQL은 사이트에서 데이터에 접근하기 위한 모던한 인터페이스입니다. 따라서 여러분이 우아한 코드를 작성하는 데 열정적이며 최적이 아닌 솔루션을 받아들이지 않을 현명한 개발자라고 안전하게 가정할 수 있습니다.

이 두 플러그인의 코드(자체 코드베이스와 커스텀 구현에서 기대되는 코드)는 얼마나 우아할까요?

라운드 4: PHP 요구 사항

WPGraphQL과 Gato GraphQL 모두 PHP 7.1 이상을 요구합니다.

하지만 차이점이 있습니다: Gato GraphQL은 실제로 PHP 7.4를 사용하여 코딩되며, 그 후 프로덕션 환경에서 PHP 7.1로 트랜스파일됩니다.

따라서 Gato GraphQL 코딩은 훨씬 더 즐겁습니다: object 타입, 타입 지정 프로퍼티, 화살표 함수 등 새로운 PHP 기능을 사용할 수 있습니다. PHP 8.0 지원이 추가되면(Lando의 새 버전이 출시될 때), 유니온 타입, match 표현식 등도 사용할 수 있게 됩니다.

라운드 승자: Gato GraphQL.

Gato GraphQL이 흔적을 남기다!

라운드 5: 코딩 관행

먼저 WPGraphQL부터 시작하겠습니다. wp-graphql/wp-graphql 저장소를 살펴보면, 제 눈에 두드러지는 것이 있습니다:

저장소에 저장된 vendor 폴더

확대하면:

vendor 폴더의 내용

죄송하지만, 이에 대해 제가 반응할 수 있는 방법은 하나뿐입니다:

인생에서 많은 것을 용서할 수 있지만, 이것만큼은 용서할 수 없다

Composer의 vendor 폴더를 저장소에 커밋하는 것은 나쁜 관행이며, Composer는 명시적으로 이를 권장하지 않습니다.

이 문제를 수정하는 것은 어렵지 않습니다(GitHub actions에 기반한 방법을 설명한 적도 있습니다), 그래서 왜 그렇게 되어 있는지 궁금합니다.

이 라운드에서는 WPGraphQL이 스스로를 치고 있다고 말할 수 있겠습니다!

아야!

계속하겠습니다. WPGraphQL 개발에는 매우 광범위한 훅(액션 및 필터) 컬렉션을 알아야 합니다. WPGraphQL의 개발자 참조를 보면 그 규모를 알 수 있습니다.

액션 목록의 스크린샷을 찍기 위해 브라우저를 50%까지 축소해야 했습니다:

WPGraphQL 확장을 위한 액션 훅

필터 목록의 경우, 30%(Firefox가 지원하는 최솟값)까지 축소해도 전체 목록을 볼 수 없었습니다:

WPGraphQL 확장을 위한 필터 훅

GatoGraphQL/GatoGraphQL 저장소(Gato GraphQL을 포함한 모노레포)로 전환해 보겠습니다.

코드의 몇 가지 특징을 소개합니다:

✅ 표준 PSR-1, PSR-4, PSR-12 준수.

✅ 모든 코드가 여러 개의 원자적 패키지로 분리되어 있으며, 그 모두(플러그인에 100개 이상, 전체 프로젝트에 200개 이상)가 동일한 모노레포에 호스팅됩니다.

✅ Composer를 사용하여 모든 의존성을 관리합니다.

✅ 애플리케이션의 모든 서비스를 관리하기 위해 Symfony Dependency Injection을 사용합니다. 새로운 타입 리졸버, 필드 리졸버, 디렉티브 리졸버를 등록하려면 컨테이너에 새 서비스를 등록하기만 하면 됩니다.

✅ 모든 클래스가 서비스이며, Symfony Dependency Injection이 전체 애플리케이션의 자동 연결을 처리합니다.

✅ 기반이 되는 GraphQL 서버는 CMS에 종속되지 않습니다. Gato GraphQL은 WordPress용 계약을 구현하고 약간의 커스텀 로직(예: 클라이언트 제공)을 추가합니다.

WordPress 전용 코드는 전체 코드의 약 10%에 불과합니다. 이 10%를 다른 프레임워크나 CMS(Laravel/Drupal 등)용으로 복제하면 해당 환경의 GraphQL 서버 구현을 제공할 수 있습니다.

✅ CMS에 종속되지 않는 결과로, 리졸버를 코딩하는 것은 재사용 가능한 서비스로 지원되는 일반적인 비즈니스 로직을 코딩하는 것을 의미합니다. WordPress 코드 관점에서 생각할 필요가 없으며, 그 기술 부채를 처리해야 할 일이 거의 없습니다.

✅ 마찬가지로, GraphQL 스키마는 WordPress 데이터 모델의 1:1 복제본이 아니며, WordPress가 데이터 레이어에서 축적한 기술 부채를 우회하고 깔끔한 인터페이스를 제공합니다.

✅ GraphQL의 N+1 문제는 아키텍처 설계에 의해 개발자에게 부담을 주지 않고도 발생할 수 없습니다.

✅ 서버는 단순한 GraphQL 서버가 아닙니다: 실제로는 API 서버로, 단일 소스 오브 트루스에서 다른 형식이나 사양(예: REST)으로 응답을 출력할 수 있습니다. (이에 대해서는 라운드 11에서 자세히 설명합니다.)

✅ vendor 디렉터리는 커밋되지 않습니다. 대신 소스 코드는 배포 코드(WordPress 사이트에 설치할 최종 플러그인)로 변환되어 GitHub actions를 통해 vendor 폴더가 포함된 dist 저장소에 배포됩니다.

✅ 배포 코드를 생성할 때 PHP-Scoper로 범위가 지정되며, PHP 7.4 코드가 포함된 소스 코드는 PHP 7.1로 트랜스파일됩니다.

✅ 범위 지정 문제를 해결했기 때문에, 플러그인은 모든 서드파티 의존성을 활용할 수 있습니다. 현재 Symfony의 DependencyInjection, Cache, Dotenv, Guzzle(외부 API 연동용), The League의 Pipeline 등을 사용합니다.

이는 현재뿐만 아니라 미래를 위해서도 중요합니다: Packagist 저장소의 모든 의존성을 사용할 수 있다는 확신이 있으므로 바퀴를 재발명할 필요가 없습니다.

✅ 필드는 타입에 구독되어 있어 GraphQL 스키마를 쉽게 확장할 수 있습니다.

라운드 승자: Gato GraphQL (크게 앞선다고 감히 말씀드릴 수 있겠습니다).

격렬한 라운드 후, WPGraphQL은 잠시 휴식이 필요하다

라운드 6: 스키마 확장

GraphQL 스키마에 필드를 추가해 봅시다.

WPGraphQL의 튜토리얼을 따릅니다. 제안된 코드는 아래와 같습니다. 배열을 선언하는 함수를 실행하기 위해 액션 훅을 선언합니다. 필드의 설명과 해결은 배열 내에서 제공됩니다:

add_action( 'graphql_register_types', function() {
 
	register_graphql_field( 'RootQuery', 'myNewField', [
		'type' => 'String',
		'args' => [
			'myArg' => [
				'type' => 'String',
        'description' => __( 'Description for how the argument will impact the field resolver', 'your-textdomain' ),
			],
		],
		'resolve' => function( $source, $args, $context, $info ) {
			if ( isset( $args['myArg'] ) ) {
				return 'The value of myArg is: ' . $args['myArg'];
			}
			return 'test';
		},
	]);
 
});

이 예제는 가능한 한 단순합니다: 리졸버는 기본적으로 아무것도 하지 않습니다. 그럼에도 코드를 보고 무엇을 하는지 한눈에 이해하는 데 어려움을 느낍니다. 빈정거리는 것이 아닙니다: 편집기에서 그 코드의 모든 색상이 저의 주의를 빼앗고 있습니다. 게다가 관심사의 분리가 없고, 코드가 그다지 재사용 가능해 보이지 않습니다.

따라서 애플리케이션을 개발하면서 코드를 읽기 쉽고, 재사용 가능하고, 버그 없이 만드는 것은 개발자(즉, 여러분)의 몫입니다; 라이브러리 자체는 이 면에서 별로 도움이 되지 않는 것 같습니다.

저는 이 스타일을 "ADD": Array-Driven Development라고 부릅니다. 제가 팬이라고는 할 수 없습니다.

(WPGraphQL에 공평하게 말하자면, 이것은 표준 코딩 관행이며 기반 엔진인 webonyx/graphql-php에서도 채택한 방식입니다.)

Gato GraphQL에서는 모든 코드가 SOLID입니다. GraphQL 스키마에 필드를 등록하려면 FieldResolverInterface 인터페이스를 구현하는 클래스를 만들고(실제로는 이미 많은 메서드가 구현된 AbstractSchemaFieldResolver를 확장하고), 컨테이너에 등록합니다.

예를 들어, 이 코드는 User 타입에 username, email, url 필드를 제공합니다:

class UserFieldResolver extends AbstractSchemaFieldResolver
{
  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;
  }
}

저는 제 솔루션이 WPGraphQL의 것보다 더 우아하다고 생각합니다. 하지만 그것은 취향의 문제입니다. Array-Driven Development를 괜찮게 여기는 개발자도 많으며, 실제로 컴팩트한 코드 덩어리에서 모든 로직을 구현할 수 있어서 선호하는 분들도 있습니다.

라운드 결과: 무승부.

무승부

인터미션

정말 멋진 밤이군요, 여러분.

지금까지의 경기를 분석할 시간

경기의 중간 지점에 도달했으니, 화장실 휴식을 취하고 지금까지 경험한 것에 대해 코멘트할 좋은 기회입니다.

(그 사이에, 스폰서의 광고를 표시해야 할 텐데요. 아쉽게도 아직 없습니다. 여러분의 회사가 Gato GraphQL 개발을 후원하고 이런 이벤트 같은 프라임 미디어에서 노출을 원하신다면, 메시지를 보내주세요.)

스폰서가 되어 브랜드의 프리미엄 광고 기회를 얻으세요

정말 대단한 경기입니다! WPGraphQL은 처음부터 불꽃 같은 기세였습니다! 시작부터 최상의 컨디션으로, Gato GraphQL에게 맹렬한 펀치를 퍼부었고, Gato GraphQL은 겨우 두 발로 버티는 상태였습니다. 연속 타격에 타격. Gato GraphQL의 처지가 되고 싶지 않았습니다.

솔직히 인정하건대, 처음 2라운드 이후에는 경기가 곧 끝날 것이라고 생각했습니다. 언제 다운이 올지 기다리고 있었습니다. 항복의 수건이 던져지는 것을 예상했습니다. 하지만 Gato GraphQL은 버텼습니다. 그것만큼은 인정해야 합니다. 정말 흔들리지 않는 의지, 참으로 놀랍습니다!

그리고 변화가 일어났습니다. 3라운드 어느 순간부터, Gato GraphQL은 어디선가 에너지를 끌어낸 것처럼 보이더니, 방어만 하는 것이 아니라 반격 펀치를 날리기 시작했고, 그중 많은 것들이 WPGraphQL의 얼굴에 적중했습니다. WPGraphQL이 휘청거리는 것을 봤습니다! 현 세계 챔피언에게서 이런 모습은 본 적이 없었습니다. 우리가 방금 목격한 것은 참으로 놀라운 변화였습니다!

그리고 상대의 자신감을 흔들고 나서, 4라운드부터 Gato GraphQL은 일련의 치명적인 타격을 가하기로 했습니다. 그것은 충격적이었습니다! 다행히 맞서고 있는 것은 우리의 세계 챔피언 WPGraphQL이었고, 군중의 환호와 공감에 힘입어 타격을 견뎌낼 수 있었습니다. 정말 대단한 영웅입니다! 다른 누구라도 그 자리에서 쓰러졌겠지만, 그는 달랐습니다. 챔피언답게 타격을 견뎌냈습니다.

하지만 챔피언으로서 얼마나 오래 버틸 수 있을까요? 아직 아무도 다운되지 않았고, 아직 아무도 수건을 던지지 않았습니다. 경기는 언제든지 결정적인 전환을 맞을 수 있습니다. 두 파이터는 자신이 원하는 것을 알고 있으며, 상대에게 달려들어 승리하기 위해 모든 힘과 의지를 다해 다시 나올 것이 분명합니다.

정말 대단한 경기입니다!

그리고 이제, 여러분, 두 전사가 링으로 돌아옵니다.

선수들이 링으로 돌아오다

나머지 경기를 향해!

핵심 사안

GraphQL 서버는 "필요한 데이터만, 그 이상도 이하도 아니게 검색한다"는 명제를 충족하기 위해 많은 사항에 주의를 기울여야 합니다.

예를 들어:

얼마나 안전한가요? 공개 엔드포인트에서 개인 데이터를 노출하지 않으려면 어떻게 해야 할까요?
얼마나 고성능인가요? 동일한 쿼리를 반복해서 보낼 때 서버 부하를 어떻게 줄이면서 가능한 한 빠르게 만들 수 있을까요?
얼마나 간단한가요? CMS가 제공하는 기능을 활용하기 위해 WordPress와 얼마나 잘 통합되어 있나요?

그리고 더 많은 질문들이 있습니다. 이것은 제가 선택한 작은 샘플로, 다음 3라운드에서 다루겠습니다.

라운드 7: Persisted queries

Persisted queries는 GraphQL과 REST의 장점을 결합합니다: GraphQL을 사용하여 생성되므로 데이터의 언더/오버 페칭이 없지만, 고유한 URL이 있는 엔드포인트로 서버에 게시됩니다.

Persisted queries는 다음과 같은 이점을 제공합니다:

✅ 안전합니다: 단일 엔드포인트를 통해 모든 데이터에 액세스할 수 있게 하는 대신, 공개할 데이터를 미리 정의할 수 있습니다.

✅ 빠릅니다: 고유한 URL로 접근되므로, 표준 HTTP 캐싱을 사용하여 클라이언트와 백엔드 사이의 모든 레이어(서버, CDN, 브라우저)에서 캐시할 수 있습니다.

WPGraphQL은 다음 두 가지 확장 기능을 통해 persisted queries를 지원합니다:

또한 Jason Bahl(WPGraphQL 제작자)은 최근 가까운 미래에 WPGraphQL에 persisted queries 지원을 추가할 것이라고 발표했습니다.

이미 2개의 확장 기능이 있는데 무엇을 생각하고 있는지 궁금합니다. 그것들과 어떻게 다를까요? 어쩌면 서드파티에 의존하지 않고 플러그인 전체의 보안 조치를 강화하기 위해 플러그인 코어의 일부로 만들고 싶을 수도 있습니다.

아니면 Gato GraphQL의 구현을 보고, 순수 코드 대신 비주얼 에디터로 조작하는 유사한 경험을 제공하고 싶을 수도 있을까요?

이것이 Gato GraphQL로 이어집니다. Persisted queries를 제공하는 것뿐만 아니라, 그것을 제공의 핵심 부분으로 만들기 위해 노력했습니다:

✅ 플러그인은 단일 엔드포인트 비활성화를 가능하게 하며, 사용자는 persisted queries를 통해서만 데이터를 공개하도록 권장됩니다.

(대조적으로, WPGraphQL은 기본적으로 인트로스펙션만 비활성화하며, 실제 엔드포인트는 비활성화하지 않습니다. 즉, 공격자는 여전히 개인 데이터에 접근할 수 있을 수 있습니다; 사전에 어떤 개인 데이터가 있는지 알 수 없게 해서 작업을 어렵게 만들 뿐입니다.)

✅ WordPress 에디터와 깊게 통합되어 있어, persisted query를 만드는 것이 블로그 게시물을 만드는 것과 같은 노력으로 가능하며, 프로그래머뿐만 아니라 누구나 할 수 있습니다.

✅ Persisted queries는 정적이지 않습니다: GraphQL 변수를 사용할 수 있으며, 그 값은 엔드포인트를 실행할 때 URL 파라미터를 통해 제공될 수 있습니다.

제 플러그인에서 persisted query를 만들고 실행하는 경험을 확인해 보세요:

라운드 승자: Gato GraphQL.

라운드 8: 캐싱

GraphQL에는 큰 문제점이 있습니다: 쉽게 캐시할 수 없습니다. 그 이유는 단일 엔드포인트에 POST 작업을 보내는 것에 의존하기 때문입니다. 단일 엔드포인트가 다른 결과를 생성하고, 쿼리가 URL 파라미터 대신 요청의 본문에 포함되어 전송되므로 단일 엔드포인트를 캐시할 수 없습니다.

많은 GraphQL 서버가 제공하는 표준 솔루션은 캐싱을 클라이언트로 옮기고, 엔드포인트의 URL 대신 객체의 ID를 캐시할 엔티티의 식별자로 사용하는 것입니다. 이 기능을 제공하는 가장 인기 있는 라이브러리는 Apollo 클라이언트입니다.

WPGraphQL의 캐싱에 사용 가능한 모든 옵션에 대한 WPGraphQL 저장소의 토론이 있습니다. 흥미롭게도, 그 대부분은 외부 도구(Apollo 클라이언트 또는 WordPress Object Cache 등)이며, 이는 애플리케이션에 추가적인 레이어를 추가하고 복잡성을 높이며 속도를 느리게 만들 수 있습니다.

(이러한 이유들이 WPGraphQL에 persisted queries를 네이티브로 구현하기로 한 결정의 배경 중 일부일 것입니다.)

예를 들어, Apollo 클라이언트는 클라이언트에서 실행됩니다. 저사양 휴대폰으로 웹사이트에 접근할 경우, 그 추가적인 JavaScript 코드가 애플리케이션의 성능에 영향을 줄 것입니다.

마찬가지로, WordPress를 다루는 개발자는 PHP에는 능숙할 수 있지만 JavaScript에는 그다지 능숙하지 않을 수 있습니다. 이제 API를 캐싱하려면 JavaScript 레이어도 신경 써야 합니다.

Gato GraphQL은 이 주제에 대해 더 현명하게 접근했습니다. Persisted queries를 제공하기 때문에, 쿼리가 자체 엔드포인트에서 실행됨을 의미하며, HTTP 캐싱을 통해 이 엔드포인트 URL을 캐시할 수 있습니다.

HTTP 캐싱 헤더의 max-age 값은 쿼리의 모든 필드에 대한 모든 max-age 값으로부터 자동으로 계산되며, 이 정보는 필드별로 WordPress 에디터를 사용하여 설정됩니다.

결과적으로 API는 여러 레이어(클라이언트, CDN, 서버)에서 캐시할 수 있으며, 다른 레이어를 추가하지 않고 플러그인 내에서 네이티브로 처리됩니다.

API 엔드포인트가 캐시되는 모습을 보여주는 다음 동영상을 확인해 보세요:

라운드 승자: Gato GraphQL.

라운드 9: Gutenberg와의 통합

한때 Gutenberg는 WordPress의 미래가 될 것이라고 했습니다. 이제는 그렇지 않습니다: Gutenberg는 이제 WordPress의 현재(WordPress 에디터라고 부를 수 있습니다)이며, Full Site Editing이 새로운 미래가 되었습니다.

말할 필요도 없이, API는 WordPress 에디터와 좋은 통합이 필요합니다. 이것은 블록의 데이터를 검색하고 게시하는 것뿐만 아니라, WordPress 에디터 자체의 기능을 강화하기 위한 것이기도 합니다.

예를 들어, GraphQL 구독이 서버에서 클라이언트로 실시간으로 데이터를 푸시할 수 있기 때문에, 협업 편집과 알림 기능을 강화하는 데 적합합니다.

WPGraphQL은 WPGraphQL Gutenberg 확장 기능을 통해 블록 데이터를 쿼리할 수 있습니다. 이 확장 기능은 각 블록을 매핑하는 새로운 타입을 생성하므로, CoreParagraphBlock, CoreQuoteBlock 등이 생깁니다.

Gato GraphQL은 곧 블록 데이터를 쿼리할 수 있게 됩니다(작업 중). 그러나 블록마다 새로운 타입을 생성하는 대신, 모든 블록을 나타내는 단일 Block 타입을 갖게 되며, 이름을 기반으로 특정 블록의 메타데이터를 추출할 수 있습니다.

예를 들어, 단락 블록 내의 콘텐츠를 번역하는 방법을 확인해 보세요(@strTranslate 디렉티브 사용, Google Translate API에 연결):

query TranslateStringsInBlocks {
  post(by: { id: 1657 }) {
    title
    paragraphBlocks: blockDataItems(
      filterBy: { include: "core/paragraph" }
    )
    translatedParagraphBlocks: blockDataItems(
      filterBy: { include: "core/paragraph" }
    )
      @underJSONObjectProperty(by: { path: "attributes.content" })
        @underEachArrayItem
          @strTranslate(from: "en", to: "fr")
  }
}

라운드 결과: 무승부.

범위 확장

"나에게는 꿈이 있습니다."

Gutenberg 블록은 WordPress에서 콘텐츠를 만들기 위한 단일 인터페이스를 제공하도록 설계되어, CMS 코드 개발과 사용자에게 필요한 학습을 크게 단순화합니다.

콘텐츠 작성을 위해 도입되었지만, 블록은 위젯, 메뉴, 그리고 곧 Full Site Editing을 통한 테마 등 CMS의 다른 모든 영역을 꾸준히 차지해 가고 있습니다. 그리고 미래에는 다국어 기능과 협업 편집(블록을 생각할 때 떠올리지 못할 수도 있는 기능)도 지원하게 될 것이며, 그 외 무엇이 더 생길지 모릅니다.

GraphQL에 대해서도 같은 관점으로 생각할 수 있습니다: 데이터와 상호작용하기 위한 단일 인터페이스로. 즉, 데이터를 가져오고 게시하는 것뿐만 아니라 편집을 포함한 데이터와 관련된 모든 상호작용이 대상입니다.

WordPress는 진정으로 웹의 OS가 될 수 있는 독보적인 기회를 갖고 있습니다: Gutenberg로 구동되는 시스템으로, 사용자가 어떤 종류의 콘텐츠(텍스트, 이미지, 비디오, 오디오 등)든 입력하고, 자체 도구나 클라우드 기반 서비스를 통해 처리하고, WordPress 사이트나 다른 곳 등 최종 목적지에 게시할 수 있습니다.

하지만 이 강력한 꿈 뒤에는, 우리가 부여하는 어떤 요건도 충족할 수 있는 진정으로 강력한 API가 있어야 합니다. GraphQL에 기반하면서도 그 한계를 넘어서도록 설계된 API입니다.

라운드 10: 커스텀 디렉티브 지원

라운드 10 시작

WPGraphQL은 단 하나의 디렉티브도 제공하지 않습니다. 지원하지 않는다고 말하는 것이 아닙니다(엔진인 webonyx/graphql-php는 지원합니다), 커스텀 디렉티브의 구현을 제공하지 않는다는 것입니다.

"그래서요?" 라고 생각할 수 있습니다. "디렉티브가 무엇에 필요한가요? 누군가 쿼리의 결과를 수정해야 한다면 자신의 클라이언트에서 하면 됩니다!"

디렉티브가 왜 필요한가?

이것은 의견의 문제이며, 옳고 그름이 없습니다. 하지만 한 가지 말씀드리겠습니다: 디렉티브는 매우 유용한 기능으로, GraphQL을 REST와 구별하는 데 도움이 됩니다. 사용하지 않고 있다면, 아마도 API를 최대한 활용하고 있지 않은 것입니다.

디렉티브는 사양에 의해 규제되지 않으므로, GraphQL 서버는 원하는 방식으로 구현할 수 있으며, 필요한 만큼 강력하게 만들 수 있습니다. 그래서 @stream과 @defer처럼 GraphQL의 많은 새로운 기능이 먼저 디렉티브로 도입됩니다.

Gato GraphQL은 디렉티브를 경외심을 가지고 다룹니다. 한 번만 실행되어 적용된 모든 필드에 대해 모든 엔티티의 데이터로 실행됩니다(이것이 @strTranslate 디렉티브가 Google Translate API에서 결과를 매우 빠르게 가져올 수 있는 이유입니다). 또한 GraphQL 엔진 자체가 디렉티브 파이프라인에 기반합니다.

아, 하지만 이 모든 힘을 사용자에게 이용 가능하게 하는 것이 두렵지 않으신가요? 그것은 타당한 우려입니다. 그러나 단일 엔드포인트에 대한 접근을 제거하고, persisted queries를 통해서만 데이터에 접근할 수 있도록 제공하면 됩니다. 그 경우, 디렉티브에 대한 접근 권한을 가진 사람은 (사이트 관리자인) 여러분뿐입니다.

따라서 여러분이 이점을 얻거나, 아무것도 일어나지 않거나 둘 중 하나입니다.

디렉티브를 좋아한다면, Gato GraphQL을 사랑하게 될 것입니다! ❤️

하지만 한편으로, 좋아하지 않는다면 아무것도 일어나지 않습니다.

라운드 승자: Gato GraphQL.

("냄새나는 디렉티브는 필요 없다"고 생각하신다면, 저에게 화내지 마세요... 저는 그저 제 일을 하고 있을 뿐입니다.)

라운드 11: REST 지원

"뭐라고요? REST요? 무슨 REST요? 여기서 GraphQL 이야기를 하고 있는 거 아닌가요? 왜 REST 이야기를 하는 건가요? 왜 제 삶을 복잡하게 만들고 싶으신 건가요?"

이 이상은 해드릴 수 없습니다

맞아요, 처음에는 이 주제가 어색하게 보입니다. 하지만 매우 단순한 이유로 이 비교에 추가했습니다: Matt Mullenweg가 WordPress 코어에 잠재적으로 포함하기 위해 GraphQL을 검토하고 있다고 말했고, 기여자들이 걱정할 것은 두 개의 코드베이스를 유지해야 한다는 것입니다.

이것이 명백한 질문으로 이어집니다: GraphQL 서버가 REST도 처리할 수 있을까요?

대답은 WPGraphQL에 대해서는 "부분적으로 예", Gato GraphQL에 대해서는 "완전히 예"입니다.

WPGraphQL에 관해서. REST 엔드포인트를 정의하는 것이 가능하며, 해결될 때, GraphQL 엔진으로의 내부 호출로, 또는 동일한 웹서버에 대해 실행되는 외부 POST 작업으로, 필요한 필드를 포함하는 GraphQL 쿼리를 실행합니다.

하지만 그것만으로는 WP REST API를 만족시키기에 충분하지 않습니다. 왜냐하면 JSON 스키마도 있어서 그것 없이는 할 수 없기 때문입니다.

Gato GraphQL에 관해서. 운이 좋았다고 인정해야 합니다. 기반 엔진(PoP이라는 서버 사이드 컴포넌트 모델)의 작업은 2013년경에 시작되었습니다. 즉, GraphQL이라는 것을 알기 몇 년 전이었고, 이 프로젝트는 자체적인 아이디어로 발전했습니다(이 저의 빈티지 글에 문서화했습니다).

그리고 약 1.5년 전에 CMS 비종속적인 GraphQL 서버(Gato GraphQL이 서 있는) 코딩을 시작했을 때, PoP를 위해 개발된 아이디어와 GraphQL이 확립한 기반을 합쳐, GraphQL 사양을 완전히 지원하면서도 다른 기능 세트를 추가할 수 있는 시스템을 만들었습니다.

이 점에서 PoP가 사용하는 스키마는 API 비종속적이며 GraphQL의 것의 수퍼셋입니다. PoP 스키마는 /api/graphql/?query=fullSchema에 있습니다.

그런 다음, GraphQL 서버 레이어는 GraphQL 사양에 따라 PoP 스키마를 포맷하여 GraphQL 스키마를 생성합니다. 마찬가지로 WP REST API가 요구하는 JSON 스키마를 생성할 수 있습니다.

이 JSON 스키마 생성은 아직 완료되지 않았지만, 가능합니다.

현재 이미 완료된 것은 쿼리의 응답을 여러 형식으로 생성하는 것입니다. 예를 들어, 이 GraphQL 쿼리:

{
  posts {
    id
    title
    date
    author {
      name
    }
  }
}

이 REST 엔드포인트를 통해서도 해결됩니다: /posts/api/rest/?query=id|title|date|author.name.

거기서 멈출 필요가 없습니다. XML 등 다른 형식으로 결과를 생성해야 하나요? 문제없습니다: /api/?query=posts.id|title|date|author.name&datastructure=xml.

(이것은 스키마에 기반한 WordPress의 새 가져오기/내보내기 도구 제안 구현에 도움이 될 수 있습니다. 이것은 또한 제가 앞서 말한 것을 조금 더 명확하게 합니다: 단일 인터페이스가 CMS 내의 모든 데이터 상호작용뿐만 아니라, CMS와 외부 API와의 상호작용도 구동할 수 있습니다.)

라운드 승자: Gato GraphQL.

라운드 12: 새로운 기능 지원

GraphQL 사양은 최종적인가요? 대답은 아니오입니다: 사양은 계속 진화하고 있습니다. 지금 이 순간, 100개의 오픈 이슈가 있으며, 그 중 많은 것들이 미래 어느 시점에 공식화될 제안을 담고 있습니다.

자, 그 100개의 이슈 중에 오늘 우리가 혜택을 받을 수 있는 새로운 기능이 분명히 있겠죠? 그렇다면 왜 기다리나요?

그것이 바로 저의 사고방식입니다.

영원히 기다릴 수는 없습니다

"하지만 GraphQL 사양에 없는 것을 GraphQL 서버에 추가해서는 안 됩니다, 사용자가 혼란스러워할 겁니다!"

좋은 지적입니다. 하지만 새로운 기능을 옵트인으로만 이용 가능하게 하면, 사용자는 반드시 그것을 인식하게 되어 문제나 오해가 생기지 않을 것입니다.

다시 말하지만, 그것이 저의 사고방식입니다. 그러나 이것은 의견의 문제이므로, 다른 모든 GraphQL 서버가 사용하는 기능만 사용하고 싶다면 그것도 괜찮습니다.

WPGraphQL은 그렇게 운영된다고 생각합니다. 적어도 사양에서 승인된 것을 넘어서는 단일 기능을 본 적이 없습니다.

Gato GraphQL에 대해서는 사양의 이슈 목록을 정기적으로 훑어보고, 제 서버에서 큰 노력 없이 충족할 수 있는 멋진 기능을 찾으면 구현합니다. (실제로 이것은 저의 취미 중 하나입니다.)

이것들은 제가 지금까지 구현한 "앞을 내다보는" 기능들입니다:

✅ 다중 쿼리 실행
✅ 스키마 네임스페이싱
✅ 중첩 뮤테이션
✅ 컴포저블 디렉티브
✅ 사전 피드백
✅ 필드 및 디렉티브 기반 버전 관리

그리고 이미 추가할 계획입니다:

✳️ Subscriptions(이것은 이미 사양의 일부입니다)
✳️ @stream과 @defer 디렉티브
✳️ 플랫 체인 문법

라운드 승자: Gato GraphQL.

판정!

신사 숙녀 여러분.

판정의 시간

정말 잊을 수 없는 밤이었습니다! 정말 대단한 경기를 경험했습니다! 두 헤비급 선수가 꿈을 위해 최선을 다했습니다.

두 선수 모두 쫓고 있는 꿈이지만, 잡을 수 있는 것은 한 명뿐입니다.

그리고 이제, 그 사람이 누구인지 알게 됩니다. 이제, 진실의 시간입니다!

"WordPress의 GraphQL" 세계 챔피언은 누가 될까요?

널리 찬사를 받고, 대중에게 사랑받으며, 유명 매체에 소개된 현 챔피언 WPGraphQL일까요?

아니면 반항적이고, 용서를 구하지 않고 발을 밟으며, 초대받지 않고 파티에 나타난 도전자 Gato GraphQL일까요?

선수들이 판정을 기다리다

심판의 판정을 기다립니다. 얼마나 긴장되는지! 오 하느님, 이 순간을 제 마음이 견뎌낼 수 있게 해 주세요!

🥁 그리고 🥁 승자는 🥁 이이이이이이이이이이이이 🥁 ...

무승부입니다!

두 파이터, 두 헤비급, 무승부입니다!

선수들이 서로 껴안다

정말 멋진 순간입니다! 두 선수가 서로 껴안으며, 우리가 모두 WordPress 커뮤니티라는 큰 가족 안에서 친구임을 보여줍니다.

그렇다면 무승부의 이유는 무엇일까요? 심판이 설명합니다:

👑 WPGraphQL이 더 인기 있으며, 그 사용이 더 널리 퍼져 있습니다.

👑 Gato GraphQL은 더 나은 아키텍처를 갖추고 있으며, 장기적으로 WordPress를 더 잘 지원할 수 있는 잠재력이 있습니다.

신사 숙녀 여러분, 심판의 판정을 들었습니다!

그리고 우리의 트로피에는 두 개의 글러브가 있습니다: 각 선수에게 하나씩.

"WordPress의 GraphQL" 트로피

하지만 여러분의 판정은 무엇인가요?

헤드리스 필요를 위해 WPGraphQL을 무조건 계속 사용할 건가요?

아니면 Gato GraphQL이 요청하는 기회를 줘서, 플러그인을 다운로드하고 시도해 볼 건가요?

신사 숙녀 여러분. 오늘 밤은 이것으로 마칩니다.

경기를 즐기셨기를 진심으로 바랍니다.

그리고 두 챔피언의 새로운 대결이 곧 이루어지기를 바랍니다.

안녕히 계세요.

2024년 05월 01일 업데이트: Gato GraphQL vs WPGraphQL 비교에서 더 자세히 알아보세요.

🥊 Gato GraphQL vs WPGraphQL: 대결!

인기도

라운드 1: 누가 사용하고 있으며, 얼마나 완성되었는가

라운드 2: 확장 기능의 이용 가능성

라운드 3: 대상 사용자

코드 스타일과 표준

라운드 4: PHP 요구 사항

라운드 5: 코딩 관행

라운드 6: 스키마 확장

인터미션

핵심 사안

라운드 7: Persisted queries

라운드 8: 캐싱

라운드 9: Gutenberg와의 통합

범위 확장

라운드 10: 커스텀 디렉티브 지원

라운드 11: REST 지원

라운드 12: 새로운 기능 지원

판정!

뉴스레터 구독하기