💁🏽‍♂️ CMS 불가지론을 지원하기 위해 Gato GraphQL이 약 90개의 패키지로 분할된 이유와 이 접근 방식의 장단점

지난 주에 💁🏻‍♀️ Gato GraphQL이 왜 모노레포가 필요한지, 그리고 어떻게 최적화되어 있는지 라는 글을 게재했습니다. Gato GraphQL의 코드를 호스팅하는 GatoGraphQL/GatoGraphQL 모노레포가 플러그인의 코드베이스를 얼마나 효율적으로 관리할 수 있는지에 대해 설명했습니다.

이 글을 Reddit에 공유했더니 다음과 같은 댓글을 받았습니다.

OP의 글과 거기서 링크된 글들을 읽으면, 마치 모노레포가 슬라이스 빵 이후 최고의 발명인 것처럼 읽힙니다.

더 흥미로운 글이라면, 왜 CMS 불가지론을 위해 모든 것을 각각의 작은 패키지로 분리해야 한다고 생각했는지, 그리고 왜 200개 이상의 패키지 각각을 처음부터 독립된 저장소에 두어야 한다고 생각했는지를 설명하는 것이겠죠.

이것은 흥미로운 질문입니다. 그래서 이 글을 작성하여 좀 더 자세히 다루기로 했습니다.

하지만 먼저, 관련된 두 가지 주제를 다루겠습니다. 플러그인이 실제로 필요로 하는 패키지의 수와, 기반이 되는 GraphQL 서버가 CMS 불가지론적이라고 주장하는 이유입니다.

플러그인을 구성하는 패키지의 수

200개 이상의 PHP 패키지를 언급했지만, 그것은 모노레포에 관한 것입니다. 플러그인에 관해서는 실제로 그보다 훨씬 적습니다.

GatoGraphQL/GatoGraphQL 모노레포는 5개의 프로젝트를 포함하고 있습니다:

PoP: 서버 사이드 컴포넌트 모델 라이브러리 (React와 유사하지만 백엔드용)
GraphQL by PoP: PHP를 위한 CMS 불가지론적 GraphQL 서버
Gato GraphQL
사이트 빌더 (WIP)
Wassup: 사이트 빌더 기반의 웹사이트 테마 (WIP)

이러한 프로젝트들을 모노레포에서 호스팅하면 상호 의존성 때문에 작업이 간편해집니다:

GraphQL by PoP는 PoP를 기반으로 합니다
Gato GraphQL은 GraphQL by PoP를 기반으로 합니다
사이트 빌더는 컴포넌트 모델 라이브러리를 엔진으로 사용합니다 (Gatsby가 GraphQL을 사용하는 방식과 유사)
Wassup은 사이트 빌더를 기반으로 합니다

5개 프로젝트 모두의 코드와 관련하여, GatoGraphQL/GatoGraphQL은 200개 이상의 PHP 패키지를 포함하고 있습니다. Gato GraphQL에 관해서는 "단지" 91개의 패키지입니다. 그리고 기반이 되는 GraphQL 서버인 GraphQL by PoP는 "단지" 98개의 패키지를 포함하고 있습니다.

(Gato GraphQL 플러그인이 기반 GraphQL 서버보다 적은 패키지를 필요로 하는 이유는, Google Translate @strTranslate 디렉티브와 같은 일부 패키지가 아직 플러그인에 추가되지 않았기 때문입니다.)

GraphQL by PoP는 어떻게 CMS 불가지론적인가요? webonyx와의 차이는 무엇인가요?

GraphQL by PoP는 CMS 불가지론적이라고 말해왔습니다. 하지만 그것이 무슨 의미인가요?

그런데 webonyx/graphql-php도 CMS 불가지론적입니다. 그렇다면 두 가지는 어떻게 다를까요?

webonyx/graphql-php가 CMS 불가지론적인 것은, Composer를 통해 배포되는 패키지로서 "바닐라" PHP 코드만을 포함하고 있다는 의미에서입니다. 하지만 그 자체로는 완전한 GraphQL 서버가 아니며, PHP에서 GraphQL 사양을 구현한 것으로, PHP의 어떤 GraphQL 서버에 내장되도록 설계되어 있습니다.

이제 Lighthouse나 WPGraphQL과 같이 GraphQL을 구현하는 서버들은 CMS 불가지론적이지 않습니다. Lighthouse를 WordPress에서 실행하거나, WPGraphQL을 Laravel에서 실행할 수 없습니다.

이런 의미에서 GraphQL by PoP는 CMS 불가지론적입니다: Laravel, WordPress, 또는 기타 어떤 CMS나 프레임워크에서도 실행할 수 있도록 거의 준비된 "준완성형" GraphQL 서버입니다. (간결함을 위해, 이후부터 "CMS"는 "CMS 또는 프레임워크"를 의미합니다.)

특정 CMS를 위해 완성하려면, 해당 GraphQL 서버에는 해당 패키지를 통해 그 CMS에 맞는 커스텀 코드가 여전히 필요합니다.

이제 댓글의 질문에 답하겠습니다.

왜 각 패키지를 독립된 저장소에 두어야 했나요?

Packagist (Composer의 PHP 패키지 레지스트리)가 패키지를 게시/배포하기 위해 저장소 URL 제공을 요구하기 때문입니다.

(참고로, 역시 지난 주에 게재한 저의 글 Hosting all your PHP packages together in a monorepo에서도 이 문제에 대해 다루고 있습니다.)

왜 CMS 불가지론을 위해 모든 것을 각각의 작은 패키지로 분리해야 하나요?

몇 가지 이유가 있습니다.

CMS가 자체 코드를 주입할 수 있도록 하기

100% 동일한 PHP 코드를 사용하여 어디서나 작동하는 GraphQL 서버를 만드는 것은 불가능합니다.

예를 들어, 코드의 일부가 다른 곳의 변수 값을 수정할 수 있도록 하기 위해, WordPress는 필터 훅에 의존하고, Symfony는 EventDispatcher 컴포넌트를 사용하며, Laravel에는 자체적인 이벤트와 리스너 시스템이 있습니다. 이 세 가지 다른 방법의 PHP 코드도 서로 다릅니다.

여기서 코드를 세분화된 패키지로 분할하는 접근 방식이 등장합니다. 이벤트와 리스너에 대한 솔루션을 애플리케이션의 일부로 포함하는 대신, 패키지를 통해 애플리케이션에 주입되며, 이 패키지에는 CMS별 코드가 포함됩니다.

이것이 작동하려면, 모든 기능을 2개의 패키지로 분리해야 합니다:

CMS 불가지론적 패키지: 모든 비즈니스 로직을 포함하며 "바닐라" PHP 코드만 사용합니다. 이 패키지에는 CMS별 패키지가 충족해야 할 계약이 포함됩니다
CMS별 패키지: 해당 CMS에 대한 계약을 충족합니다

예를 들어, GraphQL by PoP에는 다음과 같은 계약을 포함하는 hooks 패키지가 있습니다:

interface HooksAPIInterface
{
  public function addFilter(string $tag, callable $function_to_add, int $priority = 10, int $accepted_args = 1): void;
  public function removeFilter(string $tag, callable $function_to_remove, int $priority = 10): bool;
  public function applyFilters(string $tag, mixed $value, mixed ...$args): mixed;
  public function addAction(string $tag, callable $function_to_add, int $priority = 10, int $accepted_args = 1): void;
  public function removeAction(string $tag, callable $function_to_remove, int $priority = 10): bool;
  public function doAction(string $tag, mixed ...$args): void;
}

그리고 패키지 hooks-wp는 WordPress에 대한 계약을 충족합니다:

class HooksAPI implements HooksAPIInterface
{
  public function addFilter(string $tag, callable $function_to_add, int $priority = 10, int $accepted_args = 1): void
  {
    \add_filter($tag, $function_to_add, $priority, $accepted_args);
  }
  public function removeFilter(string $tag, callable $function_to_remove, int $priority = 10): bool
  {
    return \remove_filter($tag, $function_to_remove, $priority);
  }
  public function applyFilters(string $tag, mixed $value, mixed ...$args): mixed
  {
    return \apply_filters($tag, $value, ...$args);
  }
  public function addAction(string $tag, callable $function_to_add, int $priority = 10, int $accepted_args = 1): void
  {
    \add_action($tag, $function_to_add, $priority, $accepted_args);
  }
  public function removeAction(string $tag, callable $function_to_remove, int $priority = 10): bool
  {
    return \remove_action($tag, $function_to_remove, $priority);
  }
  public function doAction(string $tag, mixed ...$args): void
  {
    \do_action($tag, ...$args);
  }
}

이제 훅의 개념은 WordPress에서 유래했지만, 다른 CMS에서도 작동할 수 있습니다 (예: 이벤트와 리스너를 사용하여 훅을 구현하는 경우). 따라서 hooks-wp를 hooks-laravel, hooks-symfony, hooks-drupal, hooks-octobercms, 또는 다른 것으로 교체하여 각 CMS별 코드를 사용해 계약을 충족할 수 있습니다.

CMS가 지원할 수 없는 기능을 제거할 수 있도록 하기

모든 CMS가 모든 기능을 지원할 수 있는 것은 아닙니다. 예를 들어, WordPress는 meta_value 항목으로 게시물을 정렬하는 것을 가능하게 하지만, OctoberCMS는 그렇지 않습니다.

그래서 GraphQL by PoP에는 metaquery 패키지가 있습니다 (WordPress를 위해 metaquery-wp를 통해 충족됩니다). 그러면 WordPress를 위해 구현된 GraphQL 서버는 이 패키지를 포함하겠지만, OctoberCMS를 위한 것은 포함하지 않을 것입니다.

이 접근 방식의 장점

패키지를 세분화하여 분할하면 몇 가지 이점이 있습니다.

비즈니스 로직을 CMS별 코드에서 분리하기

CMS의 특성 (코딩 방식, 기능, 제한 사항 등)에 기반하여 애플리케이션을 코딩하는 대신, 코드를 추상화하고 비즈니스 로직만 사용할 수 있습니다.

예를 들어, 게시물 목록을 가져오기 위해, 애플리케이션은 CMS 불가지론적 패키지 posts의 인터페이스에서 getPosts 메서드를 실행할 수 있습니다. 그러면 기반 CMS에 의한 구현과 무관하게 게시물은 항상 같은 방식으로 가져와집니다.

기술적 부채를 우회하고 최신 표준 사용하기

위의 예를 이어서, PSR-4 규약을 따르는 getPosts 메서드를 실행하여 게시물을 가져옵니다. WordPress에서 정의한 get_posts를 호출하는 대신에 말이죠.

마찬가지로, 부정확한 get_post 대신 getCustomPost를 실행하여 커스텀 게시물을 가져올 수 있습니다 (이것은 WordPress의 기술적 부채의 일부입니다).

스코프 적용이 쉽다

WordPress 플러그인에 PHP-Scoper를 사용하여 스코프를 적용하는 것은 쉽지 않으며, 가능한 경우에도 버그가 발생하기 쉽습니다.

CMS별 코드와 애플리케이션의 비즈니스 로직을 철저히 분리하면, 일부 패키지 (비즈니스 로직이 있는 것)에만 PHP-Scoper를 적용하고 다른 패키지 (WordPress 코드를 포함하는 것)에는 적용을 피할 수 있습니다. 이 전략에 대해 여기에서 자세히 설명했습니다.

또한, PHP-Scoper와 유사하게, 일부 CMS별 코드 (WordPress 등)에 적용하면 실패하는 다른 도구들도 있을 수 있습니다. 그런 경우에는 패키지를 세분화하여 분할하는 것이 해결책이 될 수 있습니다.

필요한 코드만 포함하는 다양한 애플리케이션을 생성할 수 있다

패키지를 재사용하여 필요한 패키지만 포함하는 여러 애플리케이션을 생성할 수 있습니다.

예를 들어, 개인 블로그는 posts, tags, categories만 필요할 수 있으므로, users나 user-login 기능을 다룰 필요가 없습니다.

실제로, 저는 곧 이 기능을 활용할 계획입니다: 현재 "Private GraphQL API"를 개발 중입니다. 이것은 자체 완결형 GraphQL 엔진으로, WordPress 플러그인 개발자들이 자신의 플러그인에 번들로 포함하여 Gutenberg 블록에 GraphQL API를 제공할 수 있게 하는 것입니다.

Gato GraphQL 플러그인에서 필요하지 않은 패키지 (UI, 클라이언트, 커스텀 엔드포인트, HTTP 캐싱, 영속 쿼리 등을 다루는 것들)를 제거하기만 하면 "Private GraphQL API"를 손쉽게 만들 수 있습니다.

마지막으로, 스코프 적용이 쉽기 때문에 (위에서 살펴본 것처럼), 필요한 모든 패키지에 접두사를 붙일 수 있으므로, Private GraphQL API는 충돌 없이 작동할 것입니다 (2개의 서로 다른 플러그인이 서로 다른 버전의 Private GraphQL API를 번들로 포함할 때 발생할 수 있는 상황).

이 접근 방식의 단점

두말할 것도 없이, 이 접근 방식은 완벽과는 거리가 있습니다.

더 많은 노력이 필요하고 코드가 장황해진다

일반적으로, 애플리케이션이 WordPress에서 실행된다면, 게시물 목록을 가져오기 위해 단순히 get_posts를 실행하기만 하면 됩니다. 간단하고 쉽습니다.

CMS 불가지론적으로 만들면 상황이 상당히 복잡해집니다. 게시물 목록을 가져오려면 다음을 수행해야 합니다:

posts와 posts-wp 패키지를 생성합니다
posts 패키지에 getPosts 함수가 있는 계약을 생성합니다
posts-wp 패키지에서 get_posts를 통해 계약을 충족합니다
기능을 항상 계약을 통해 호출하고 직접 호출하지 않도록 합니다

getpop/access-control
getpop/cache-control
getpop/component-model
getpop/definitions
getpop/engine
getpop/engine-wp
getpop/field-query
getpop/guzzle-helpers
getpop/hooks
getpop/hooks-wp
getpop/loosecontracts
getpop/mandatory-directives-by-configuration
getpop/modulerouting
getpop/query-parsing
getpop/root
getpop/routing
getpop/routing-wp
getpop/translation
getpop/translation-wp
graphql-api/markdown-convertor

API 기능:

getpop/api
getpop/api-clients
getpop/api-endpoints
getpop/api-endpoints-for-wp
getpop/api-graphql
getpop/api-mirrorquery

GraphQL 서버 기능:

graphql-by-pop/graphql-clients-for-wp
graphql-by-pop/graphql-endpoint-for-wp
graphql-by-pop/graphql-parser
graphql-by-pop/graphql-query
graphql-by-pop/graphql-request
graphql-by-pop/graphql-server

데이터 모델:

pop-schema/basic-directives
pop-schema/categories
pop-schema/categories-wp
pop-schema/comment-mutations
pop-schema/comment-mutations-wp
pop-schema/commentmeta
pop-schema/commentmeta-wp
pop-schema/comments
pop-schema/comments-wp
pop-schema/custompost-mutations
pop-schema/custompost-mutations-wp
pop-schema/custompostmedia
pop-schema/custompostmedia-mutations
pop-schema/custompostmedia-mutations-wp
pop-schema/custompostmedia-wp
pop-schema/custompostmeta
pop-schema/custompostmeta-wp
pop-schema/customposts
pop-schema/customposts-wp
pop-schema/generic-customposts
pop-schema/media
pop-schema/media-wp
pop-schema/menus
pop-schema/menus-wp
pop-schema/meta
pop-schema/metaquery
pop-schema/metaquery-wp
pop-schema/pages
pop-schema/pages-wp
pop-schema/post-categories
pop-schema/post-categories-wp
pop-schema/post-mutations
pop-schema/post-tags
pop-schema/post-tags-wp
pop-schema/posts
pop-schema/posts-wp
pop-schema/queriedobject
pop-schema/queriedobject-wp
pop-schema/schema-commons
pop-schema/tags
pop-schema/tags-wp
pop-schema/taxonomies
pop-schema/taxonomies-wp
pop-schema/taxonomymeta
pop-schema/taxonomymeta-wp
pop-schema/taxonomyquery
pop-schema/taxonomyquery-wp
pop-schema/user-roles
pop-schema/user-roles-access-control
pop-schema/user-roles-wp
pop-schema/user-state
pop-schema/user-state-access-control
pop-schema/user-state-mutations
pop-schema/user-state-mutations-wp
pop-schema/user-state-wp
pop-schema/usermeta
pop-schema/usermeta-wp
pop-schema/users
pop-schema/users-wp