🕸 GraphQL은 WordPress를 어떻게, 어디서 개선할 수 있는가 — REST API를 보완하며

지난 주말에 블로그 게시물 🦸🏿‍♂️ Gato GraphQL이 이제 PHP 8.0에서 7.1로 트랜스파일됩니다를 게시했습니다.

Reddit의 /r/php에서 그 게시물을 공유한 후, 커뮤니티에서는 WordPress에서 GraphQL을 사용하는 것의 가치, WP REST API와의 차이점, 그리고 WordPress에 또 다른 API를 도입하는 것의 정당성에 대해 활발한 토론이 시작되었습니다.

대부분의 댓글은 핵심을 찌르고 있다고 생각하지만, 일부는 중요한 정보를 놓치고 있습니다. GraphQL은 단순한 인터페이스가 아니라 구현이기도 합니다. 즉, 서로 다른 제공업체의 서로 다른 GraphQL 서버는 각기 다른 특성을 우선시하도록 설계되었을 수 있습니다. 따라서 GraphQL이 제공하는 것이나 GraphQL 엔진이 작동하는 방식에 대해 항상 통일된 기대를 갖거나 완전히 이해하기는 어렵습니다.

예를 들어, WordPress와 Laravel에서의 GraphQL 경험은 다르며, WPGraphQL과 Gato GraphQL이라는 서로 다른 서버가 제공하는 경험도 다릅니다.

이 글은 Reddit 게시물의 여러 댓글을 다루는 저 자신의 견해입니다.

​

GraphQL vs WP REST API

[정말 나쁜 생각이다] 이미 자체 REST API를 사용하는 WordPress 위에 GraphQL API를 추가하다니. 그냥 REST API를 사용하면 된다. [출처]

REST API와 GraphQL 모두 동일한 목적을 수행합니다. 즉, 애플리케이션에 필요한 데이터를 제공하는 것입니다. 하지만 이를 달성하는 방식은 다릅니다. REST는 특정 데이터 집합을 제공하는 미리 정의된 엔드포인트를 갖는 반면, GraphQL은 필요한 데이터만 정확하게 제공할 수 있습니다.

이러한 동작 차이는 애플리케이션의 성능에 직접적인 영향을 미칠 수 있습니다. REST에서 게시물 목록과 각 게시물 작성자의 데이터를 가져와야 하는 경우, 추가 요청을 보내야 합니다. 모든 작성자 데이터에 대해 1개의 추가 요청, 또는 작성자당 1개의 추가 요청이 필요할 수 있습니다. 그동안 웹사이트 방문자는 페이지가 렌더링되기를 기다리고 있을 것입니다.

GraphQL은 이 상황을 개선합니다. 게시물과 작성자 데이터 전체를 단일 요청으로 직접 가져올 수 있어 웹페이지 렌더링이 더 빨라집니다.

{
  posts {
    id
    title
    excerpt
    date
    url
    author {
      id
      name
      url
    }
  }
}Copy

WordPress에 REST API가 이미 있다고 해서, 그것이 모든 작업에 항상 가장 적합한 도구라는 의미는 아닙니다. 물론 항상 사용할 수는 있지만, GraphQL에도 접근할 수 있다면 REST보다 유리한 상황에서 이 API를 선택해 사용할 수 있으며, 더 나은 결과를 얻을 수 있습니다.

​

GraphQL의 어려운 초기 설정 + 리졸버 작성

GraphQL의 초기 설정이 REST에 비해 기하급수적으로 높다는 주장은 분명히 있습니다. 연관 관계를 설정해야 한다는 점은 맞습니다. [출처]

그리고...

당신과 웹의 거의 모든 사람이 빠뜨리고 있는 것은, 이 API 형식이 작동하려면 파서(리졸버 + 타입)를 작성해야 하며, 이로 인해 REST에는 없는 일련의 문제가 발생한다는 점입니다. [출처]

이러한 댓글은 완전히 정확하지 않습니다. WPGraphQL과 Gato GraphQL이 이미 WordPress 데이터 모델을 GraphQL 스키마에 매핑해 놓았기 때문입니다(WPGraphQL은 완전히, 제 플러그인은 대부분).

따라서 이러한 플러그인 중 하나를 설치하면, 리졸버를 만들거나 엔티티 간 연관 관계를 설정할 필요 없이 즉시 애플리케이션의 데이터 가져오기를 시작할 수 있습니다.

물론 애플리케이션의 고유 엔티티(CPT 등)에서 커스텀 데이터를 가져오려면, 리졸버를 통해 매핑해야 하며 직접 해야 합니다. 하지만 이는 REST와 다르지 않습니다. CPT에서 커스텀 데이터가 필요하다면, 해당 커스텀 데이터를 가져오기 위한 REST 엔드포인트를 만들어야 합니다. 커스텀 엔드포인트도 리졸버의 일종입니다.

따라서 리졸버 필요성 측면에서, REST와 GraphQL API는 거의 동일합니다.

웹사이트와 문서를 둘러보면, GraphQL이 설정에 더 많은 노력이 필요하다는 인상을 줍니다. 이 추정에는 어느 정도 근거가 있습니다.

몇 가지 이유가 있다고 생각합니다. 우선 GraphQL에는 (최소) 두 가지 측면이 있습니다.

1. 그것이 무엇인지, 어떻게 작동하는지에 대한 개념
2. 실제 구현을 제공하는 서버

graphql.org와 같은 GraphQL 공식 사이트의 문서를 보면, GraphQL 뒤에 있는 개념에 집중하며 리졸버가 무엇인지, 왜 필요한지에 대해 자세히 설명합니다.

이는 Laravel과 Lighthouse를 사용하는 것처럼 처음부터 애플리케이션을 구축할 때 유용합니다. 그 경우에는 직접 리졸버를 코딩해야 합니다(물론 REST 엔드포인트도 직접 만들어야 하지만요).

하지만 WordPress는 이미 완성된 애플리케이션이고, WPGraphQL과 Gato GraphQL은 그 솔루션입니다. 이 두 플러그인은 이미 리졸버를 만들어 놓았으므로 신경 쓸 필요가 없습니다(WP REST API도 초기 엔드포인트 세트를 제공하여 신경 쓸 필요가 없는 것과 마찬가지입니다).

또한 GraphQL은 개발자 중심이며, 그 문서는 개발자에게 직접 말을 거는 것처럼 보입니다. 개발자가 서버 측에서 리졸버를 만들고, 개발자가 클라이언트 측에서 커스텀 쿼리로 해당 리졸버를 사용합니다. 리졸버 구축은 개발자의 일이기 때문에 자연스럽게 자주 등장합니다.

REST의 경우, 필요한 데이터를 제공하는 엔드포인트는 이미 존재해야 한다는 기대(WP REST API가 제공하는 것)가 있다고 생각합니다. 존재하지 않을 때만 커스텀 엔드포인트 설정을 고려해야 합니다. 따라서 REST에서는 리졸버 생성에 대한 언급이 적습니다.

즉, REST와 GraphQL 모두 필요한 데이터를 제공합니다. 하지만 REST는 엔드포인트가 이미 존재해야 한다는 정적인 접근 방식을 권장하며, 존재하지 않을 때만 신경 씁니다. 반면 GraphQL은 모든 쿼리를 커스텀 제작하는 동적인 접근 방식을 권장하며, 완벽한 리졸버를 코딩할 수 있습니다.

결국 REST와 GraphQL 사이에는 근본적인 차이가 없으며, 요건을 어떻게 충족해야 하는지에 대한 해석의 차이만 있을 뿐입니다.

​

GraphQL의 취약점 + 보안 고려 사항

안전한 인터프리터를 작성하는 것은 정말 어렵기 때문에 언젠가 GraphQL에서 큰 취약점이 나올 것입니다. [출처]

그리고...

WordPress는 이미 거대해서 항상 큰 공격 대상이 됩니다. 플러그인을 추가하면 위험이 크게 증가합니다. 그리고 WordPress의 모든 것을 문자 그대로 노출하려는 플러그인(메뉴와 메뉴 아이템을 공개하거나 모든 사용자를 공개하는 보안 모델을 우회하는 샘플 코드 포함)은 저에게는 절대 용납할 수 없습니다. 테마 기반이 아닌 출력은 절대적으로 필요한 것 이상으로 최대한 제한되어야 합니다(제가 요청하지 않는 한 존재하지 않아야 합니다). 이것이 코어에 포함되지 않기를 바랍니다. [출처]

GraphQL은 분명히 추가적인 보안 위험을 초래하며 이를 해결해야 합니다. 이 우려에 완전히 동의합니다.

하지만 그것이 GraphQL을 WP 코어에 포함시킬 가능성을 막는 결정적인 문제라고는 생각하지 않습니다. 더 나아가, 이를 해결하기가 정말 어렵다고도 생각하지 않습니다.

필요한 것은 GraphQL 서버가 WordPress의 기존 보안 메커니즘을 활용하고, 개발자가 그 메커니즘을 사용하여 특정 필드에 적절한 사용자만 접근할 수 있도록 하는 것입니다.

• 사용자가 로그인되어 있는가?
• 사용자가 관리자인가?
• 사용자가 어떤 역할이나 권한을 가지고 있는가?
• 사용자가 해당 게시물의 작성자인가?

이 요건을 충족하기 위해, Gato GraphQL은 Access Control Lists(접근 제어 목록)을 제공하여 각 필드와 디렉티브에 접근할 수 있는 사람을 설정으로 정의할 수 있습니다.

그런데 ACL만으로는 충분하지 않은 경우도 있으며, GraphQL 서버가 추가적인 보안 조치를 제공해야 합니다. 현재 Gato GraphQL의 다가오는 v0.8을 위해 작업 중인 내용을 설명하겠습니다.

필드 posts(게시물 데이터를 가져오는 것)는 인증이 필요 없으며, 로그인 여부에 관계없이 모든 사용자가 접근할 수 있습니다. 따라서 보안상의 이유로 공개된 게시물만 가져옵니다.

하지만 다음과 같은 상황에서는 초안/보류 중/휴지통 게시물도 가져와야 할 때가 있습니다.

• 관리자가 실행하는 정적 웹사이트 구축(사이트의 모든 데이터에 대한 접근 포함)
• 게시물 작성자가 계속 편집할 수 있도록 모든 초안 게시물을 나열하는 경우

그래서 다음과 같은 체계를 구상했습니다. 게시물을 가져오기 위해 3개의 필드가 제공됩니다.

• posts: 누구나 접근 가능하며, 공개된 게시물만 가져올 수 있음
• myPosts: 누구나 접근 가능하며, 로그인한 사용자의 게시물만 모든 상태(공개됨/초안/보류 중/휴지통)로 가져옴
• postsForAdmin: 관리자만 접근 가능하며, 모든 상태의 모든 게시물을 가져옴

그리고 postsForAdmin은 기본적으로 비활성화되어 있어 GraphQL 스키마에 표시되지 않습니다. 관리자가 명시적으로 활성화한 경우에만 표시됩니다(아마도 정적 사이트 구축에만 활성화될 것입니다).

또 다른 상황은 특정 필드가 공개 데이터와 비공개 데이터를 모두 가져올 수 있는 경우입니다. 예를 들어, 필드 option은 테이블 wp_options에서 데이터를 가져옵니다. 일부 항목은 공개(blogname 등)이지만, 그렇지 않은 것(admin_email 등)도 있습니다.

비슷한 상황으로는 필드 Post.metaValue, User.metaValue 등을 통해 메타 값을 가져오는 경우가 있습니다. 예를 들어, 사용자 메타에는 분명히 비공개인 항목 wp_capabilities가 포함되어 있지만, description은 공개되어 있습니다. 그리고 last_name은 애플리케이션에 따라 공개 또는 비공개일 수 있습니다.

이 데이터에 대한 접근을 안전하게 하기 위해, 플러그인은 설정 페이지의 허용/거부 목록을 통해 쿼리할 수 있는 항목을 지정할 수 있게 됩니다. 전체 항목 또는 정규식을 모두 허용합니다.

허용된 옵션 쿼리는 작동하고, 거부된 옵션은 null을 반환합니다.

{
  # This option is allowed
  siteName: optionValue(name: "blogname")
  # This optionValue is not allowed
  adminEmail: optionValue(name: "admin_email")
}Copy

GraphQL 서버의 적절한 보안 조치와 개발자의 상식이 있다면, 안전한 GraphQL API를 구축하는 것은 어렵지 않을 것입니다.

​

GraphQL로 인한 DB 다운

GraphQL은 깊은 관계형 쿼리를 표현할 수 있는 풍부한 구문을 가지고 있습니다. WordPress와 같은 생태계에서 데이터 모델의 확장성이 엔티티-속성-값 패턴에 기반하기 때문에, GraphQL 쿼리가 깊고 복잡하거나 재귀적인 경우 데이터베이스에 믿을 수 없는 부하가 걸려 사이트가 응답하지 않을 수 있습니다. WordPress는 이미 MySQL/MariaDB 인스턴스를 한계까지 몰아붙이는 것으로 유명합니다. 쿼리가 적절하게 작성되고 인증되며 속도 제한되지 않는다면, GraphQL을 추가하면 훨씬 더 나빠질 수 있습니다. [출처]

DB 다운은 GraphQL 서버에게 심각한 우려 사항입니다. Gato GraphQL이 이 시나리오를 피하려는 방법을 설명하겠습니다.

Gato GraphQL은 아키텍처 설계에 의해 N+1 문제가 발생하지 않도록 합니다. 엔진이 데이터베이스에서 엔티티를 로드하는 책임을 지며, 개발자가 아닙니다.

리졸버에서 연결을 해결할 때, 반환되는 값은 객체 자체가 아닌 객체의 ID(또는 ID 목록)입니다. 예를 들어, 커스텀 게시물의 작성자를 가져오는 것은 다음과 같이 수행됩니다.

class CustomPostFieldResolver extends AbstractDBDataFieldResolver
{
  private CustomPostUserTypeAPIInterface $customPostUserTypeAPI;
 
  public function getClassesToAttachTo(): array
  {
    return [
      CustomPostFieldInterfaceResolver::class,
    ];
  }
 
  public function getSchemaFieldType(string $fieldName): ?string
  {
    return match($fieldName) {
      'author' => SchemaDefinition::TYPE_ID,
      default => null,
    };
  }
 
  public function resolveValue(
    TypeResolverInterface $typeResolver,
    object $customPost,
    string $fieldName,
    array $fieldArgs = []
  ): mixed {
    switch ($fieldName) {
      case 'author':
        return $this->customPostUserTypeAPI->getAuthorID($customPost);
    }
 
    return null;
  }
 
  public function resolveFieldTypeResolverClass(
    TypeResolverInterface $typeResolver,
    string $fieldName
  ): ?string {
    switch ($fieldName) {
      case 'author':
        return UserTypeResolver::class;
    }
 
    return null;
  }
}Copy

resolveValue에서 DB 엔티티의 ID를, resolveFieldTypeResolverClass(클래스 UserTypeResolver로 표현됨)에서 객체의 타입을 얻어, GraphQL 엔진은 객체의 데이터를 로드할 수 있습니다.

데이터를 로드할 때, 엔진은 매우 효율적인 알고리즘을 사용합니다. 이는 노드 수가 아니라 쿼리 내 타입 수를 n으로 하는 시간 복잡도 O(n)입니다.

이 알고리즘이 이러한 효율성을 달성하는 이유는 그래프를 순회하지 않고, 데이터 구조를 컴포넌트 스택으로 변환하기 때문입니다. 이는 훨씬 간단하게 해결할 수 있습니다. (GraphQL의 "그래프"는 개념이지 실제 구현이 아닙니다.)

쿼리가 여러 레벨을 가지고 각각 많은 엔티티를 가져오는 경우에도 알고리즘은 꽤 잘 견딜 수 있습니다. 예를 들어, 깊이 10 레벨의 다음 쿼리를 실행해도 큰 영향이 없습니다.

{
  posts(pagination: { limit: 10 }) {
    excerpt
    title
    url
    author {
      name
      url
      posts(pagination: { limit: 10 }) {
        title
        tags(pagination: { limit: 10 }) {
          slug
          url
          posts(pagination: { limit: 10 }) {
            title
            comments(pagination: { limit: 10 }) {
              content
              date
              author {
                name
                posts(pagination: { limit: 10 }) {
                  title
                  url
                  comments(pagination: { limit: 10 }) {
                    content
                    date
                    author {
                      name
                      username
                      url
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}Copy

이 효율성의 예외는 Post.metaValue, User.metaValue, Comment.metaValue, PostTag.metaValue, PostCategory.metaValue(및 metaValues 필드)를 통해 메타 값을 가져오는 경우입니다. WordPress 함수(get_post_meta, get_user_meta 등)는 한 번에 1개의 ID에 대한 데이터를 가져오기 때문에, 각 엔티티는 메타 값을 가져오기 위한 데이터베이스 호출이 필요합니다. 결과적으로 메타 값 해결은 타입 수가 아닌 노드 수에 따라 확장됩니다(이 점에서 원본 댓글이 정확히 핵심을 찌르고 있습니다).

악의적인 행위자가 메타 필드를 사용하고 남용하는 것을 방지하기 위해, Gato GraphQL(v0.8)은 이 필드들을 기본적으로 비활성화한 상태로 제공됩니다. 관리자가 명시적으로 활성화해야 하며, 그렇게 할 때 이 필드들을 Access Control List 아래에 배치할 수 있어 DB가 공격 위험에 노출되지 않습니다.

속도 제한도 훌륭한 아이디어이며, 향후 릴리스에서 지원할 계획입니다.

그리고 쿼리의 복잡성 분석 및 제한 부과(예: 몇 레벨 깊이까지 허용하는지)에 대해서도 검토하고 있습니다. GraphQL 서버는 시간 복잡도 O(n)으로 쿼리를 해결하므로, 루핑에 관해서는 그다지 큰 해가 없습니다. 하지만 단일 쿼리만으로도 DB에서 무제한의 데이터를 가져올 수 있으며, 이는 피하고 싶은 것입니다.

예를 들어, 이 간단한 쿼리는 단일 요청으로 방대한 양의 데이터를 가져옵니다(제 데모 사이트에는 수백 건의 레코드만 있어 쿼리 실행을 시연할 수 있습니다).

{
  posts000: posts(pagination: { limit: 100 }) {
    ...PostFields
  }
  posts100: posts(pagination: { limit: 100, offset: 100 }) {
    ...PostFields
  }
  posts200: posts(pagination: { limit: 100, offset: 200 }) {
    ...PostFields
  }
  posts300: posts(pagination: { limit: 100, offset: 300 }) {
    ...PostFields
  }
  posts400: posts(pagination: { limit: 100, offset: 400 }) {
    ...PostFields
  }
  posts500: posts(pagination: { limit: 100, offset: 500 }) {
    ...PostFields
  }
  posts600: posts(pagination: { limit: 100, offset: 600 }) {
    ...PostFields
  }
  posts700: posts(pagination: { limit: 100, offset: 700 }) {
    ...PostFields
  }
  posts800: posts(pagination: { limit: 100, offset: 800 }) {
    ...PostFields
  }
  posts900: posts(pagination: { limit: 100, offset: 900 }) {
    ...PostFields
  }
}
 
fragment PostFields on Post {
  id
  title
  content
  date
}Copy

보시다시피, 문제를 일으키기 위해 쿼리를 중첩할 필요조차 없습니다. 따라서 쿼리 복잡성 분석은 까다로운 작업이며, 유용하게 만들기 위해서는 세밀한 조정이 필요합니다.

쿼리 분석 지원도 추가하고 싶지만, 우선순위가 높지 않습니다. 퍼시스티드 쿼리나 커스텀 엔드포인트와 Access Control Lists의 조합으로 이미 악의적인 행위자를 차단할 수 있으며, 우리 자신은 자신의 GraphQL 서비스를 남용하지 않을(않아야 할!) 것이기 때문입니다.