WordPress에서 GraphQL 작동하기

헤드리스 워드프레스(Headless WordPress)는 최근 몇 주 동안 많은 새로운 개발이 이루어지면서 유행하는 것 같습니다. 활동이 폭발적으로 증가한 이유 중 하나는 WordPress용 GraphQL 서버인 WPGraphQL 버전 1.0 릴리스입니다.

WPGraphQL은 WordPress 웹사이트에서 데이터를 가져오고 게시하는 방법인 GraphQL API를 제공합니다. 그것은 우리가 선택한 프레임워크(React, Vue.js, Gatsby, Next.js 또는 기타).

최근까지 WPGraphQL은 WordPress용 유일한 GraphQL 서버였습니다. 하지만 이제 다른 플러그인을 사용할 수 있습니다. 바로 제가 작성한 WordPress용 GraphQL API입니다.

이 두 플러그인은 WordPress 웹사이트에 GraphQL API를 제공하는 동일한 목적을 수행합니다. 이미 WPGraphQL이 있는데 왜 다른 플러그인이 필요한지 궁금할 것입니다. 이 두 플러그인이 동일한 작업을 수행합니까? 아니면 다른 상황을 위한 것입니까?

먼저 이것을 말하겠습니다. WPGraphQL은 훌륭하게 작동합니다. 문제가 있어서 플러그인을 빌드하지 않았습니다.

GraphQL에 매우 적합한 데이터를 효율적으로 검색 하는 엔진을 작업했기 때문에 WordPress용 GraphQL API를 만들었습니다. 그래서 “왜 안 되지?”라고 스스로에게 말했고, 저는 그것을 구축했습니다. (또한 몇 가지 다른 이유도 있습니다.)

두 플러그인은 아키텍처가 다르고 특성이 다르기 때문에 특정 작업을 플러그인 하나로 쉽게 달성할 수 있습니다.

이 기사에서는 WPGraphQL이 갈 길이고 워드프레스용 GraphQL API가 더 나은 선택인 경우를 내 자신의 관점에서 최대한 객관적으로 설명합니다.

다음과 같은 경우 WPGraphQL 사용: Gatsby 사용

Gatsby를 사용하여 웹사이트를 구축하는 경우 선택 사항은 WPGraphQL뿐입니다.

그 이유는 WPGraphQL에만 WordPress용 Gatsby 소스 플러그인이 있기 때문입니다. 또한 WPGraphQL의 제작자인 Jason Bahl은 최근까지 Gatsby에 고용되어 있었기 때문에 이 플러그인이 Gatsby의 요구 사항에 적합할 것이라고 전적으로 신뢰할 수 있습니다.

Gatsby는 WordPress 웹 사이트에서 모든 데이터를 수신하고 그 이후로 응용 프로그램의 논리는 WordPress가 아닌 Gatsby 측에서 완전히 수행됩니다. 따라서 WPGraphQL에 대한 추가 사항(예: @stream 또는 @defer 지시문 추가 가능성)은 큰 차이를 만들지 않습니다.

WPGraphQL은 Gatsby가 필요로 하는 만큼 이미 훌륭합니다.

새로운 헤드리스 프레임워크 중 하나를 사용하는 경우 WPGraphQL 사용

앞서 언급했듯이 최근 WordPress 헤드리스 공간에서 Next.js를 기반으로 하는 몇 가지 새로운 프레임워크 및 스타터 프로젝트와 관련하여 활발한 활동이 있었습니다.

• Colby Fayock은 Next.js WordPress Starter를 만들었습니다.
• WebDevStudios는 자체 Next.js WordPress Starter를 출시했습니다.
• WP 엔진은 헤드리스 워드프레스 웹사이트를 호스팅하고 배포하는 서비스를 제공하는 헤드리스 워드프레스 프레임워크를 만들었습니다.

이러한 새로운 헤드리스 프레임워크를 사용해야 하는 경우 모두 이 플러그인 위에 구축되었기 때문에 WPGraphQL을 사용해야 합니다.

그것은 약간 불행합니다. WordPress용 GraphQL API가 이들에게도 전원을 공급할 수 있기를 정말로 원합니다. 그러나 그렇게 하려면 이러한 프레임워크가 인터페이스를 통해 GraphQL과 함께 작동 해야 GraphQL 서버를 교체할 수 있습니다.

나는 이러한 프레임워크 중 하나가 그러한 인터페이스를 제자리에 배치할 것이라는 희망을 갖고 있습니다. Headless WordPress Framework 토론 게시판에서 이에 대해 질문했는데 고려될 수 있다고 들었습니다. WebDevStudios의 Next.js 워드프레스 스타터 토론게시판에도 질문을 올렸는데 아쉽게도 제 질문은 답변도 없이 바로 삭제되었습니다. (강력하지 않습니까?)

따라서 WPGraphQL은 현재, 그리고 예측 가능한 미래입니다.

다음 경우 중 하나(또는 둘 다) 사용: Frontity 사용

Frontity는 WordPress용 React 프레임워크입니다. 이를 통해 WordPress를 통해 백엔드에서 관리되는 React 기반 애플리케이션을 구축할 수 있습니다. WordPress 편집기를 사용하여 블로그 게시물을 만드는 것조차 기본적으로 지원됩니다.

Frontity는 데이터 획득 방법을 누출하지 않고 애플리케이션의 상태를 관리합니다. 기본적으로 REST 기반이지만 해당 소스 플러그인을 구현하여 GraphQL을 통해 전원을 공급할 수도 있습니다.

이것이 Frontity가 스마트한 방식입니다. 소스 플러그인은 데이터 공급자와 통신하기 위한 인터페이스입니다. 현재 사용 가능한 유일한 소스 플러그인은 WordPress REST API용 플러그인입니다. 그러나 누구나 WordPress용 WPGraphQL 또는 GraphQL API용 소스 플러그인을 구현할 수 있습니다. (이것이 내가 Next.js 기반 프레임워크를 복제했으면 하는 접근 방식입니다.)

결론 : WPGraphQL이나 GraphQL API는 Frontity와 작업할 때 다른 이점을 제공하지 않으며, 둘 다 연결하는 데 약간의 초기 노력이 필요합니다.

다음과 같은 경우 WPGraphQL 사용: 정적 사이트 생성

처음 두 섹션에서 결론은 동일했습니다. WPGraphQL을 사용하십시오. 그러나 이 결론에 대한 내 반응은 달랐습니다. Gatsby를 사용할 때는 후회가 없었지만 Next.js에서는 이에 대해 뭔가를 해야 한다고 느꼈습니다.

왜 그런 겁니까?

차이점은 Gatsby는 순전히 정적 사이트 생성기이지만 Next.js는 정적 웹사이트와 라이브 웹사이트 모두에 전력을 공급할 수 있다는 것입니다.

나는 WPGraphQL이 이미 Gatsby에 충분하다고 언급했습니다. 이 진술은 실제로 확장될 수 있습니다. WPGraphQL은 이미 모든 정적 사이트 생성기에 충분합니다 . 정적 사이트 생성기가 WordPress 웹 사이트에서 데이터를 가져오면 WordPress로 거의 해결됩니다.

WordPress용 GraphQL API가 추가 기능을 제공하더라도 정적 사이트 생성기에 차이가 없을 가능성이 큽니다.

따라서 WPGraphQL은 이미 충분히 훌륭하고 GraphQL 스키마를 완전히 매핑했기 때문에(여전히 WordPress용 GraphQL API에 대한 작업이 진행 중임) WPGraphQL은 현재와 가까운 미래에 가장 적합한 옵션입니다.

다음 경우 GraphQL API 사용: 라이브(즉, 비정적) 웹 사이트에서 GraphQL 사용

이제 모바일 앱에 전원을 공급하거나 웹사이트에 실시간 데이터를 플로팅(예: 분석 표시)하거나 정적 및 라이브 접근 방식을 결합하는 경우와 같이 GraphQL이 라이브 웹사이트에서 데이터를 가져오도록 하려면 위의 상황이 변경됩니다. 같은 웹사이트에서.

예를 들어 Next.js 프레임워크 중 하나를 사용하여 간단한 정적 블로그를 구축했으며 사용자가 블로그 게시물에 댓글을 추가할 수 있도록 하려고 한다고 가정해 보겠습니다. 이 작업을 어떻게 처리해야 합니까?

정적 및 라이브 (또는 동적)의 두 가지 옵션이 있습니다. 정적을 선택하면 댓글이 웹사이트의 나머지 부분과 함께 렌더링됩니다. 그런 다음 댓글이 추가될 때마다 웹훅을 트리거하여 웹사이트를 재생성하고 재배포해야 합니다.

이 접근 방식에는 몇 가지 불편한 점이 있습니다. 재생성 및 재배포 프로세스 에는 몇 분이 소요될 수 있으며 그 동안에는 새 설명을 사용할 수 없습니다. 또한 웹 사이트가 하루에 많은 댓글을 수신하는 경우 정적 접근 방식은 더 많은 서버 처리 시간을 필요로 하므로 비용이 많이 들 수 있습니다(일부 호스팅 회사는 서버 시간을 기준으로 청구함).

이 상황에서는 웹사이트를 주석 없이 정적으로 렌더링한 다음 라이브 사이트에서 주석을 검색하여 클라이언트에서 동적으로 렌더링하는 것이 좋습니다.

이를 위해 Gatsby보다 Next.js를 권장합니다. 다양한 기능을 가진 사용자를 위해 다양한 출력을 지원하는 것을 포함하여 정적 및 라이브 접근 방식을 더 잘 처리할 수 있습니다.

GraphQL 토론으로 돌아가기: 라이브 데이터를 다룰 때 WordPress용 GraphQL API를 권장하는 이유는 무엇입니까? GraphQL 서버가 주로 속도와 보안 면에서 애플리케이션에 직접적인 영향을 미칠 수 있기 때문에 그렇게 합니다.

순전히 정적 웹사이트의 경우 WordPress 웹사이트는 비공개로 유지될 수 있으므로(개발자의 랩톱에 있을 수도 있음) 안전합니다. 그리고 사용자는 서버의 응답을 기다리지 않으므로 속도가 반드시 중요한 것은 아닙니다.

그러나 라이브 사이트의 경우 GraphQL API가 공개되므로 데이터 안전성이 문제가 됩니다. 악의적인 행위자가 액세스할 수 없도록 해야 합니다. 또한 사용자는 응답을 기다리므로 속도가 중요한 고려 사항이 됩니다.

이런 점에서 워드프레스용 GraphQL API는 WPGraphQL에 비해 몇 가지 장점이 있습니다 .

WPGraphQL은 기본적으로 자체 검사를 비활성화하는 것과 같은 보안 조치를 구현합니다. 그러나 WordPress용 GraphQL API는 기본적으로 단일 엔드포인트를 비활성화하여(여러 다른 측정과 함께) 더 나아갑니다. 이것은 WordPress용 GraphQL API가 기본적으로 지속 쿼리를 제공하기 때문에 가능합니다.

속도와 관련하여 지속 쿼리는 API를 더 빠르게 만듭니다. 그 이유는 클라이언트, 콘텐츠 전달 네트워크 및 서버를 포함한 여러 계층에서 HTTP 캐싱을 통해 응답을 캐시할 수 있기 때문입니다.

이러한 이유로 WordPress용 GraphQL API는 라이브 웹사이트를 처리하는 데 더 적합합니다.

다음과 같은 경우 GraphQL API 사용: 다른 사용자 또는 응용 프로그램에 대해 다른 데이터 노출

WordPress는 다양한 애플리케이션의 콘텐츠를 관리할 수 있고 다양한 유형의 사용자가 액세스할 수 있는 다목적 콘텐츠 관리 시스템입니다.

컨텍스트에 따라 다음과 같은 다양한 데이터를 노출하기 위해 GraphQL API가 필요할 수 있습니다.

• 특정 데이터를 유료 사용자에게 노출하지만 무료 사용자에게는 노출하지 않습니다.
• 특정 데이터를 모바일 앱에 노출하지만 웹사이트에는 노출하지 않습니다.

다른 데이터를 노출하려면 다른 버전의 GraphQL 스키마 를 제공해야 합니다.

WPGraphQL을 사용하면 스키마를 수정할 수 있습니다(예: 등록된 필드를 제거할 수 있음). 그러나 프로세스는 간단하지 않습니다. 스키마 수정은 코딩되어야 하며 누가 무엇을 어디서 액세스하는지 이해하기가 쉽지 않습니다(예를 들어, 모든 스키마는 단일 끝점인 /graphql 에서 계속 사용할 수 있음).

대조적으로 WordPress용 GraphQL API는 기본적으로 다음과 같은 사용 사례를 지원합니다.

• /graphql/mobile-app 및 /graphql/website ,
• /graphql/pro-users 및 /graphql/regular-users .

각 사용자 지정 엔드포인트는 액세스 제어 목록을 통해 구성되어 필드별로 세분화된 사용자 액세스를 제공할 뿐만 아니라 스키마의 메타 데이터를 모든 사람이 사용할 수 있는지 아니면 승인된 사용자만 사용할 수 있는지 여부를 결정하는 공개 및 비공개 API 모드를 제공합니다.

이러한 기능은 WordPress 편집기(예: Gutenberg)와 직접 통합됩니다. 따라서 다른 스키마를 만드는 것은 블로그 게시물을 만드는 것과 유사하게 시각적으로 수행됩니다. 이는 개발자뿐만 아니라 모든 사람이 맞춤형 GraphQL 스키마를 생성할 수 있음을 의미합니다.

WordPress용 GraphQL API는 이 사용 사례에 대한 자연스러운 솔루션을 제공합니다.

다음과 같은 경우 GraphQL API 사용: 외부 서비스와 상호 작용

GraphQL은 단순히 데이터를 가져오고 게시하는 API가 아닙니다. 중요하지만(종종 무시되지만) 데이터를 처리하고 변경할 수도 있습니다. 예를 들어 문법 오류를 수정하기 위해 텍스트를 타사 API로 전송하거나 콘텐츠 전달에 이미지를 업로드하는 것과 같이 일부 외부 서비스에 데이터를 제공하여 데이터를 변경할 수도 있습니다. 회로망.

이제 GraphQL이 외부 서비스와 통신하는 가장 좋은 방법은 무엇입니까? 제 생각에 이것은 데이터를 생성하거나 검색할 때 적용되는 지시문을 통해 가장 잘 수행됩니다(WordPress 필터 작동 방식과 다르지 않음).

WPGraphQL이 외부 서비스와 얼마나 잘 상호 작용하는지 모르겠습니다. 문서에 언급되지 않고 코드 기반이 지시문 예제를 제공하지 않거나 생성 방법을 문서화하지 않기 때문입니다.

대조적으로 WordPress용 GraphQL API 는 지시문을 강력하게 지원합니다 . 쿼리의 모든 지시문은 총 한 번만 실행됩니다(필드 및/또는 개체당 한 번과 반대). 이 기능은 외부 API와의 매우 효율적인 통신을 가능하게 하며 서비스 클라우드 내에서 GraphQL API를 통합합니다.

예를 들어, 이 쿼리는 많은 게시물의 제목과 발췌문을 영어에서 스페인어로 번역하기 위해 @translate 지시문을 통해 Google 번역 API를 호출하는 것을 보여줍니다. 모든 게시물의 모든 필드는 단일 호출로 함께 번역됩니다.

WordPress용 GraphQL API는 이 사용 사례에 대한 자연스러운 선택입니다.

참고 : 사실 WordPress용 GraphQL API의 기반이 되는 엔진인 GraphQL by PoP는 고급 데이터 조작 기능을 제공하도록 특별히 설계되었습니다. 그것이 독특한 특징 중 하나입니다. 달성할 수 있는 극단적인 예는 "사용자별 현지화된 뉴스레터 보내기"에 대한 가이드를 확인하세요.

지원 커뮤니티를 원하는 경우 WPGraphQL을 사용하십시오.

Jason Bahl은 WPGraphQL을 중심으로 커뮤니티를 모으는 일을 훌륭하게 해냈습니다. 결과적으로 GraphQL API 문제를 해결해야 하는 경우 도움을 줄 수 있는 사람을 찾을 수 있습니다.

제 경우에는 여전히 WordPress용 GraphQL API를 중심으로 사용자 커뮤니티를 만들기 위해 노력하고 있으며 WPGraphQL에 가깝지 않습니다.

다음과 같은 경우 GraphQL API를 사용하십시오. 혁신을 좋아하는 경우

저는 WordPress용 GraphQL API를 "미래 지향적인" GraphQL 서버라고 부릅니다. 그 이유는 내가 종종 GraphQL 사양에 대한 요청 목록을 탐색하고 그 중 일부를 훨씬 미리 구현하기 때문입니다(특히 약간의 친밀감을 느끼거나 약간의 노력으로 지원할 수 있는 경우).

현재 WordPress용 GraphQL API는 옵트인으로 제공되는 여러 혁신적인 기능(예: 다중 쿼리 실행 및 스키마 네임스페이스)을 지원하며 몇 가지 추가 계획이 있습니다.

완전한 스키마가 필요한 경우 WPGraphQL 사용

WPGraphQL은 다음을 포함하여 WordPress 데이터 모델을 완전히 매핑했습니다.

• 게시물 및 페이지,
• 사용자 정의 게시물 유형,
• 카테고리 및 태그,
• 사용자 정의 분류법,
• 미디어,
• 메뉴,
• 설정,
• 사용자,
• 코멘트,
• 플러그인,
• 테마,
• 위젯.

WordPress용 GraphQL API는 새로운 릴리스마다 데이터 모델을 점진적으로 매핑하고 있습니다. 오늘 현재 목록에는 다음이 포함됩니다.

• 게시물 및 페이지,
• 사용자 정의 게시물 유형,
• 카테고리 및 태그,
• 사용자 정의 분류법,
• 미디어,
• 메뉴,
• 설정,
• 사용자,
• 코멘트.

따라서 플러그인, 테마 또는 위젯에서 데이터를 가져와야 하는 경우 현재 WPGraphQL만 작업을 수행합니다.

다음과 같은 경우 WPGraphQL 사용: 확장이 필요한 경우

WPGraphQL은 Advanced Custom Fields, WooCommerce, Yoast, Gravity Forms를 포함한 많은 플러그인에 대한 확장을 제공합니다.

WordPress용 GraphQL API는 이벤트 관리자용 확장을 제공하며 플러그인 버전 1.0 릴리스 후에도 계속 추가될 것입니다.

다음 중 하나 사용: WordPress 편집기용 블록 만들기

WordPress용 WPGraphQL 및 GraphQL API는 현재 GraphQL을 Gutenberg와 통합하는 작업을 진행 중입니다.

Jason Bahl은 이러한 통합을 수행할 수 있는 세 가지 접근 방식을 설명했습니다. 그러나 모두 문제가 있기 때문에 그는 GraphQL 스키마에 대한 다양한 구텐베르크 블록을 식별할 수 있도록 워드프레스에 서버 측 레지스트리 도입을 옹호하고 있습니다.

WordPress용 GraphQL API에는 "한 번 생성, 모든 곳에 게시" 전략을 기반으로 Gutenberg와 통합하는 접근 방식도 있습니다. 저장된 콘텐츠에서 블록 데이터를 추출 하고 단일 Block 유형을 사용하여 모든 블록을 나타냅니다. 이 접근 방식은 제안된 서버 측 레지스트리의 필요성을 피할 수 있습니다.

WPGraphQL의 솔루션은 서버 측 레지스트리의 사용을 수락하는 커뮤니티에 의존할 것이기 때문에 잠정적인 것으로 간주될 수 있으며, 그것이 언제 일어날지 또는 언제 일어날지 모릅니다.

WordPress용 GraphQL API의 경우 솔루션은 전적으로 자체적으로 의존하며 실제로 이미 진행 중인 작업입니다.

곧 작동하는 솔루션을 만들 가능성이 더 높기 때문에 WordPress용 GraphQL API 를 추천하는 경향이 있습니다. 그러나 솔루션이 완전히 구현될 때까지(계획에 따라 몇 주 내로) 의도한 대로 작동하는지 확인한 다음 내 권장 사항을 업데이트하겠습니다.

다음과 같은 경우 GraphQL API 사용: 플러그인을 통해 블록 배포

WordPress에서 GraphQL을 사용하는 플러그인(있는 경우)이 많지 않다는 것을 깨달았습니다.

오해하지 마세요: WPGraphQL이 10,000개 설치를 넘어섰습니다. 그러나 나는 그것들이 대부분 Gatsby에 전원을 공급하거나(Gatsby를 실행하기 위해) Next.js에 전원을 공급하기 위해(헤드리스 프레임워크 중 하나를 실행하기 위한 설치라고 믿습니다.

마찬가지로 WPGraphQL에는 앞에서 설명한 것처럼 많은 확장 기능이 있습니다. 그러나 이러한 확장은 바로 확장입니다. 그들은 독립 실행형 플러그인이 아닙니다.

예를 들어 WooCommerce 확장을 위한 WPGraphQL은 WPGraphQL과 WooCommerce 플러그인 모두에 의존합니다. 둘 중 하나가 설치되어 있지 않으면 확장이 작동하지 않으며 괜찮습니다. 그러나 WooCommerce는 작동하기 위해 WPGraphQL에 의존하는 선택권이 없습니다. 따라서 WooCommerce 플러그인에는 GraphQL이 없습니다.

내 이해는 WordPress 자체의 기능을 실행하거나 특히 Gutenberg 블록에 전원을 공급하기 위해 GraphQL을 사용하는 플러그인이 없다는 것입니다.

이유는 간단합니다. WordPress용 WPGraphQL이나 GraphQL API는 모두 WordPress의 핵심이 아닙니다. 따라서 플러그인이 WordPress의 REST API에 의존하는 방식으로 GraphQL에 의존하는 것은 불가능합니다. 결과적으로 Gutenberg 블록을 구현하는 플러그인은 REST만 사용하여 GraphQL이 아닌 블록에 대한 데이터를 가져올 수 있습니다.

겉보기에 솔루션은 GraphQL 솔루션(대부분 WPGraphQL)이 WordPress 코어에 추가될 때까지 기다리는 것입니다. 하지만 얼마나 걸릴지 누가 알겠습니까? 6개월? 년? 이년? 더 길게?

Matt Mullenweg가 암시했기 때문에 WPGraphQL이 WordPress의 핵심으로 고려되고 있다는 것을 알고 있습니다. 하지만 그 전에 많은 일이 일어나야 합니다. 최소 PHP 버전을 7.1로 올리는 것(WPGraphQL과 WordPress용 GraphQL API 모두에 필요함), GraphQL이 어떤 기능을 강화할 것인지에 대한 명확한 분리, 이해 및 로드맵이 있어야 합니다.

(현재 개발 중인 전체 사이트 편집은 REST 기반입니다. 구텐베르크의 4단계에서 다룰 다음 주요 기능인 다국어 차단은 어떻습니까? 그게 아니라면 어떤 기능이 될까요?)

문제를 설명한 후에는 기다릴 필요가 없는 잠재적인 솔루션을 고려해 보겠습니다 .

며칠 전 또 다른 깨달음을 얻었습니다. WordPress의 코드 기반용 GraphQL API에서 GraphQL 엔진만 포함하고 다른 것은 포함하지 않은 더 작은 버전을 생성할 수 있습니다(UI 없음, 사용자 지정 끝점 없음, HTTP 캐싱 없음, 액세스 제어 없음, 더 아무것도). 그리고 이 버전은 Composer 종속성으로 배포될 수 있으므로 플러그인이 자체 블록에 전원을 공급하기 위해 설치할 수 있습니다.

이 접근 방식의 핵심은 이 구성 요소가 플러그인에 특정 용도로 사용되어야 하며 다른 사람과 공유되어서는 안 된다는 것입니다. 그렇지 않으면 이 구성 요소를 참조하는 두 개의 플러그인이 서로 재정의하는 방식으로 스키마를 수정할 수 있습니다.

운 좋게도 최근 WordPress용 GraphQL API 범위 지정을 해결했습니다. 따라서 웹 사이트의 다른 코드와 충돌하지 않는 버전을 생성하여 전체 범위를 지정할 수 있다는 것을 알고 있습니다.

즉 , 이벤트 조합에 대해 작동합니다.

• 구성 요소를 포함하는 플러그인이 이를 사용하는 유일한 플러그인인 경우
• WordPress용 GraphQL API도 동일한 웹사이트에 설치되어 있는 경우
• 이 구성 요소를 포함하는 다른 플러그인이 웹사이트에 설치된 경우
• 구성 요소를 포함하는 두 개의 플러그인이 구성 요소의 동일한 버전 또는 다른 버전을 참조하는 경우.

각 상황에서 플러그인은 자체 포함된 개인 GraphQL 엔진을 갖고 있으며 이 엔진은 Gutenberg 블록에 전원을 공급하는 데 완전히 의존할 수 있습니다(충돌을 두려워할 필요가 없습니다).

Private GraphQL API 라고 하는 이 구성 요소는 몇 주 안에 준비될 것입니다. (이미 작업을 시작했습니다.)

따라서 GraphQL을 사용하여 플러그인의 Gutenberg 블록에 전원을 공급하려면 몇 주 동안 기다렸다가 WordPress의 동생인 Private GraphQL API용 GraphQL API를 확인하는 것이 좋습니다.

결론

게임에 스킨이 있긴 하지만 대부분 객관적인 글을 쓸 수 있었던 것 같아요.

WPGraphQL을 사용해야 하는 이유와 시기에 대해 솔직하게 말했습니다. 마찬가지로 WordPress용 GraphQL API가 여러 사용 사례에서 WPGraphQL보다 더 나은 것처럼 보이는 이유를 솔직하게 설명했습니다.

일반적으로 다음과 같이 요약할 수 있습니다.

• WPGraphQL을 사용하여 정적으로 전환하거나 WordPress용 GraphQL API를 사용하여 라이브로 전환하세요.
• WPGraphQL로 안전하게 플레이하거나 WordPress용 GraphQL API에 (잠재적으로 가치 있는 보상을 위해) 투자하십시오.

마지막으로 저는 Next.js 프레임워크가 Frontity에서 사용하는 것과 동일한 접근 방식을 따르도록 재설계되기를 바랍니다. 여기서 특정 솔루션을 직접 구현하는 대신 인터페이스에 액세스하여 필요한 데이터를 가져올 수 있습니다. 현재는 WPGraphQL임). 그런 일이 발생하면 개발자는 프로젝트마다 필요에 따라 사용할 기본 서버 (WPGraphQL, WordPress용 GraphQL API 또는 향후 도입될 기타 솔루션)를 선택할 수 있습니다.

유용한 링크

• WPGraphQL: 문서, 다운로드 페이지, 코드 저장소
• WordPress용 GraphQL API: 문서, 다운로드 페이지, 코드 저장소
• "개츠비 워드프레스 통합 워크샵"
  WPGraphQL 데모가 포함된 YouTube 동영상
• “WordPress용 GraphQL API 소개”
  WordPress용 GraphQL API 데모가 포함된 YouTube 동영상