이것을 누르십시오: WPGraphQL 및 Faust.js

WMR의 WordPress 커뮤니티 팟캐스트인 Press This에 오신 것을 환영합니다. 각 에피소드에는 커뮤니티 주변의 게스트와 WordPress 개발자가 직면한 가장 큰 문제에 대한 토론이 포함됩니다. 다음은 원본 녹음의 필사본입니다.

RedCircle 제공

Doc Pop : WMR에서 WordPress 커뮤니티 팟캐스트인 Press This를 듣고 있습니다. 매주 우리는 WordPress 커뮤니티의 회원을 주목합니다. 저는 여러분의 호스트인 Doc Pop입니다. 저는 WP Engine에서의 역할과 팟캐스트를 만들고 만화와 튜토리얼 비디오를 그리는 TorqueMag.Io에 대한 기여를 통해 WordPress 커뮤니티를 지원합니다. 확인해보세요.

Red Circle, iTunes, Spotify에서 Press This를 구독하거나 wmr.fm에서 직접 에피소드를 다운로드할 수 있습니다.

이번 Press This 에피소드에서는 Headless WordPress, GraphQL 및 Faust.js에 대해 이야기합니다. 이러한 도구를 함께 사용하는 방법과 Headless WordPress와 관련된 비용은 얼마입니까? 우리는 이것에 대해 깊이 파고들려고 노력할 것입니다. 오늘 두 명의 훌륭한 손님이 저에게 합류했습니다. 콜로라도 주 덴버에 있는 WP Engine의 수석 소프트웨어 엔지니어인 Jason Bahl이 있습니다. . 그리고 Faust.js에서 일하는 엔지니어링 관리자인 Chris Weigman이 있습니다. 나는 보통 게스트에게 WordPress 기원 이야기에 대해 묻는 이 쇼를 시작하는 것을 좋아하지만 여기서 약간 전환해야 한다고 생각했습니다.

Jason, WPgraphQL이 무엇이며 wordPress Origin 스토리가 무엇인지 말씀해 주시겠습니까?

Jason Bahl: 네, WPGraphQL은 WordPress 사이트에 GraphQL API를 제공하는 무료 오픈 소스 WordPress 플러그인이고 GraphQL은 그래프 쿼리 언어입니다. 따라서 개발자는 그래프 쿼리 언어를 사용하여 WordPress 안팎으로 콘텐츠를 가져올 수 있습니다.

플러그인은 몇 년 전에 신문사에서 일하고 있었고 우리는 많은 콘텐츠 신디케이션을 하고 있었습니다. 우리는 미국 전역에 걸쳐 54개 사이트로 구성된 네트워크를 보유하고 있었고 콘텐츠를 한쪽에서 다른 쪽으로 옮겨야 했습니다. 뉴스 기사가 게시되면 여러 신문에서 다른 신문의 콘텐츠를 구독할 수 있습니다.

그래서 다양한 이벤트가 발생하면 이 네트워크에서 데이터를 이동해야 했고 데이터 이동을 많이 하기 위해 WordPress REST API를 사용하고 있었습니다. 그리고 기술적으로 그리고 기술적으로 실제 성능과 같은 몇 가지 문제가 있었지만 개발자 경험도 있었습니다. 2015년 페이스북에서 공개한 실제 그래프 쿼리 언어인 GraphQL에 대해 알게 되었습니다.

그래서 저는 이 기술을 발견하고, 몇 가지 프로토타이핑을 하고, 동료들에게 피칭한 다음 연락처 신디케이션을 REST에서 GraphQL로 마이그레이션했습니다. 그런 다음 저는 JavaScript 프레임워크가 인기를 얻고 있으며 서버 간 통신이 주요 사용 사례가 아닌 것처럼 GraphQL을 사용하는 주요 사용 사례가 될 것임을 알고 커뮤니티 프로젝트로 프로젝트 작업을 계속했습니다. 그것은 우리의 필요를 해결했지만 더 큰 비전을 보았기 때문에 커뮤니티를 위한 오픈 소스 프로젝트로 계속 작업했습니다.

DP: 글쎄요. 크리스, 파우스트가 무엇이고 어떻게 생겨났는지 비슷한 이야기를 들려주실 수 있나요?

Chris Weigman: Sure Faust는 최근 이번 주에 공식적으로 대중에게 공개되었으며 GraphQL을 사용하여 Headless WordPress 사이트를 구축하기 위한 공개 프레임워크로 다시 출시되었습니다. 2020년에 Well 개발이 시작되었고 일종의 WP Engine의 비공식 프로젝트였으며 이것이 세 번째 주요 피벗입니다.

그들은 그것을 DevRel의 확장으로 시작했고 좀 더 공식적으로 만들기 시작했고 GQty라는 것과 매우 JavaScript, 개발자 우선 정신이라는 것으로 피벗했습니다. 그리고 작년 12월 1일 팀을 인수했을 때 우리는 그것이 우리의 목표 시장이 아니라는 것을 깨달았습니다.

우리는 WordPress 개발자를 위해 개발했어야 했습니다. 그래서 우리는 그것을 다시 재구성하기 시작했고, 마침내 최근에 다시 출시할 수 있게 되었습니다.

DP: Jason은 최근 Faust.js에서 새로운 wpgraphql.com을 시작했다고 트윗했습니다. 이전 사이트는 헤드리스 WordPress였습니다. 이 변경 사항에 대해 말씀해 주시겠습니까? 당신이 말하는 개선 사항은 무엇입니까?

JB: 네. 따라서 wpgraphql.com은 수년 동안 헤드리스 사이트였습니다. 그래서 여러 데이터 소스를 사용하고 있습니다. 블로그 게시물이 모두 WordPress에 있는 것처럼 WordPress에 많은 콘텐츠가 있습니다.

일부 문서는 WordPress에도 있습니다. 그런 다음 GitHub 저장소의 마크다운 파일에 일부 문서가 있습니다. 가장 오랫동안 Gatsby를 사용했는데, 아마도 3년 정도는 Gatsby를 사용했습니다. Gatsby는 핵심에 여러 소스에서 데이터를 가져올 수 있는 데이터 계층이 있는 JavaScript 프레임워크입니다.

그래서 저는 그것을 사용하고 있었고 GitHub에서 데이터를 가져오고 WPGraphQL을 사용하여 WordPress에서도 데이터를 가져오고 그 데이터를 사용하여 템플릿을 만들 수 있었습니다. 그래서 몇 년 동안 그것을 사용했습니다. 벗어나고 싶었던 데이터 계층에는 많은 어려움이 있습니다.

그래서 저는 Faust가 구축한 Next를 사용하고 싶었습니다. 또 다른 JavaScript 프레임워크이지만 누락된 부분이 많았던 것 같습니다. 다음으로 이러한 많은 JavaScript 프레임워크는 프런트 엔드 프레임워크가 모든 라우팅을 정의해야 한다는 생각을 가지고 있습니다. 맞습니까? 그러나 CMS를 사용하는 경우 CMS는 라우팅을 정의합니다.

따라서 프런트엔드가 무언가에 대한 의견을 가지고 있고 백엔드가 다른 의견을 가지고 있는 것과 같이 이러한 것들을 잘 작동하게 하는 데에는 많은 기술적인 문제가 있습니다. 그래서 제가 해결하려고 했던 문제 중 하나는 프런트 엔드에서 특정 URL이 특정 유형임을 인식한 다음 해당 항목을 나타내는 템플릿을 렌더링하는 것입니다.

블로그 게시물은 문서나 사용자 아카이브 등과는 다른 템플릿을 가지고 있습니다. 그래서 프런트 엔드가 CMS에 URL을 보내고 데이터를 다시 가져오지만 반환할 템플릿을 이해하는 기능을 갖기를 원했습니다. WordPress에서는 템플릿 계층이라고 합니다. 그래서 Faust 팀이 그 문제를 해결할 수 있게 되었을 때 저는 '아, 그래, Faust로 넘어가겠다'고 생각했습니다.

예, PHP 테마와 같은 핵심 WordPress에 존재하는 몇 가지 개념을 헤드리스에서 사용할 수 있으므로 React의 이점과 프런트 엔드에서 사용하려는 모든 JavaScript를 사용하여 내 템플릿을 만들 수 있습니다. 사이트이지만 여전히 WordPress 세계의 친숙한 개념입니다.

DP: 크리스, 파우스트가 약간의 변화를 겪었다고 말씀하셨는데요. 그러한 변화는 무엇이었습니까? 알다시피, 제이슨이 그것들을 언급하고 있었습니다. 이러한 개선을 가능하게 한 변경 사항에는 어떤 것이 있습니까?

CW: 항상 WPGraphQL에 중점을 둡니다. 실제로 문제가 된 것은 다른 모든 것이었습니다. 예를 들어, Faust의 마지막 주요 버전은 GQty라는 GraphQL과 상호 작용하기 위해 그 아래에 있는 라이브러리를 사용했습니다. 당시 Faust 팀의 아이디어는 사람들이 이러한 복잡한 쿼리를 작성하는 방법을 알 필요가 없다는 것입니다.

이 프레임워크는 이를 추상화해야 합니다. WordPress 데이터의 모든 복잡성 때문에 실제로는 정말 좋아 보였습니다. 단일 게시물 유형도 매우 다양한 변형을 가질 수 있습니다. 아마도 당신은 그것을 범주와 혼합하고 있을 것입니다. 아마도 모든 다른 것들일 것입니다. GQty는 전원을 공급할 수 없었습니다.

게다가 GQty 버전으로 빌드했을 때 Jason이 말한 라우팅 문제에 대한 관심이 정말 없었습니다. 누가 라우팅을 처리합니까? WordPress는 콘텐츠가 무엇인지에 따라 라우팅을 처리하려고 합니다. 콘텐츠 관리 시스템이므로 모든 라우팅과 WordPress는 대부분 콘텐츠 기반입니다.

Next.js는 프런트엔드 프레임워크이므로 모든 라우팅의 기반이 됩니다. 라우팅 기반 방식에 대한 완전히 다른 패러다임입니다. /Blog on Next는 블로그 콘텐츠와 아무 관련이 없을 수 있습니다. 일련의 템플릿으로 이동합니다. 블로그를 구축할 수 있는 애플리케이션의 일부가 될 것입니다.

워드프레스의 /블로그는 의미가 있을 수 있지만 이들은 모두 블로그 게시물입니다. WordPress를 매우 견고한 프런트엔드 또는 헤드리스 지원 CMS로 만들고 싶다면 구축할 때 그 패러다임을 처리해야 했습니다. GQty 버전에서 말했듯이 우리가 이것을 만들었을 때 또 다른 변화는 우리의 목표는 WordPress를 사용해야 하는 JavaScript 개발자였습니다. 이것이 WP 엔진이라는 것을 깨닫기 전까지는 고귀한 것처럼 보입니다.

우리는 몇 년 동안 WordPress를 기반으로 구축한 에이전시를 상대하고 있으며, 나중에 들어갈 수 있는 여러 가지 이유로 이제 헤드리스로 이동하고 있습니다. 그들은 WordPress 개발을 수행하는 방법을 알고 있습니다. 그들은 WordPress 템플릿 라우팅이 작동하는 방식과 템플릿이 작동하는 방식 등을 이해합니다.

WordPress 개발자가 GraphQL을 더 쉽게 사용할 수 있도록 이러한 기능을 앞으로 가져와야 합니다. 그리고 그것이 여기서 파우스트의 목표였습니다. 템플릿 계층 구조는 단순히 WordPress가 수행한 것을 다시 빌드합니다. 이제 Next의 라우팅을 사용하려는 경우 아무것도 잃지 않도록 앱에서 재정의할 수 있는 방법이 있습니다.

그러나 WordPress를 콘텐츠 관리를 통해 콘텐츠를 라우팅할 수 있는 진정한 콘텐츠 관리 시스템으로 사용하는 사람들에게는 Faust가 훨씬 더 잘 처리할 것입니까? 말이 돼?

DP : 네. 전적으로. 여기가 잠깐 쉬어가기 좋은 곳인 것 같아요. Chris Weigman과 Jason Bahl이 함께하는 WordPress 커뮤니티 팟캐스트인 Press This를 듣고 계십니다. WordPress 및 헤드리스에 대해 다시 이야기하겠습니다. 계속 지켜봐 주세요.

DP: Press This로 돌아왔습니다. 아시다시피 Chris, 그 휴식 직전에 당신은 무언가를 언급했고 점점 더 많은 회사가 헤드리스에 들어가고 있다고 언급했으며 WP Engine이 그 사실을 보여주는 많은 연구 종류를 수행했음을 알고 있습니다. 헤드리스는 확실히 어떤 것으로 명성이 있고 기업이라고 생각합니다. 헤드리스를 생각할 때 제가 올바르게 생각하고 있는지 궁금합니다. 그게 헤드리스인가요? 기업용 도구입니까, 아니면 더 많은 사이트에서 사용할 도구입니까?

CW: 예, 아니오. 주로 헤드리스, 특히 현재 WordPress에서 관련된 복잡성은 필요한 것을 구축하는 전체 팀이 있음을 의미합니다.

이것은 WordPress를 즉시 사용하는 사람이 아니라 개인 블로그를 원하는 사람입니다. 그렇게 할 수 있지만 그렇게 할 수 있기 위해서는 지금까지 훨씬 더 무거운 리프트입니다. Contentful과 동일하며 다른 모든 CMS와 동일합니다. 단순한 것을 원했다면 수년 동안 웹에 있었던 콘텐츠 유형인 헤드리스가 지금까지 처리하고 싶었던 것보다 더 많은 작업이 필요할 것입니다.

엄격히 기업입니까? 봐, 안돼. 개츠비는 수년 동안 이 문제에 대해 연구해 왔습니다. 나중에 또 다른 팟캐스트인 Doc with Mastodon이 있습니다. 제가 수년 동안 참여해 온 커뮤니티입니다. 대부분의 사람들은 헤드리스 CMS의 변형, 특히 Gatsby를 사용하고 있지만 Hugo가 있습니다. 매우 풀뿌리 수준에서 다양한 종류의 기술이 있습니다.

따라서 풀뿌리 사용자로 마무리하고 무거운 사이트의 기업 사용자로 마무리하는 반면 WordPress는 전통적으로 그 사이에 다른 모든 사용자와 함께 떨어지는 것처럼 보입니다. Gatsby 사용자처럼 마크다운 파일과 코드를 다루고 싶지 않은 사람입니다.

그러나 10명으로 구성된 전체 팀이 개인 브랜딩이나 개인 블로그를 구축하는 사람도 아닙니다. 이렇게 하면 WordPress가 그 중간에서 벗어나 매우 쉽게 양쪽 끝으로 확장됩니다. 이제 GraphQL 간에 쉽게 빌드할 수 있고, 모든 데이터가 있고, 해당 데이터를 처리하는 방법이 계속해서 증가하고 있습니다.

그리고 Faust는 한 달이 아닌 하루 만에 구축할 수 있는 것을 훨씬 더 쉽게 활용할 수 있게 해줍니다.

DP: 제이슨, 크리스가 당신의 생각을 듣고 싶다고 언급했습니다. 소규모 팀, 저와 같은 소규모 블로거에게는 적합하지 않을 수 있다고 들었습니다. 헤드리스 WordPress는 필요하지 않지만 , 제가 ​​궁금한 것은 헤드리스 WordPress가 iOS 개발자와 WordPress 개발자가 있어야 하기 때문에 비용이 더 많이 들까요? 더 비싸거나 더 비용 효율적입니까?

JB: 아마 당신이 무엇을 제작하느냐에 따라 다를 것 같아요. 당신이 iOS를 언급한 것처럼 당신이 네이티브 모바일 앱을 하고 있다면 내 말은 분명히 그와 관련된 비용이 있다는 것을 의미하며 WordPress의 데이터를 사용하는 경우 실제로 좋은 방법이 없다는 것을 의미합니다. 헤드리스로 하는 것보다 네이티브 앱은 PHP를 렌더링하지 않으므로 헤드리스로 해야 합니다.

하지만 지금 기존 WordPress에서 웹용으로 빌드하는 경우 테마를 찾을 수 있습니다. 무료 테마를 알고 있거나 마켓플레이스에서 테마를 찾아 다운로드하고 설치하면 됩니다. 경주로. 대부분의 사람들은 어떤 식으로든 사용자 정의할 것입니다.

따라서 일반적으로 개발자 비용은 본인이 하든 다른 사람이 하든 관계없이 발생합니다. 전통적인 PHP 테마와 다른 헤드리스 WordPress의 특징 중 하나는 예를 들어 새 wpgraphql.com을 시작했을 때 내 Gatsby 사이트를 지원하는 동일한 WordPress 인스턴스를 사용할 수 있다는 것입니다.

데이터를 받고 있고 데이터가 나오고 Gatsby 사이트로 들어가고 있습니다. 동시에 CMS에 콘텐츠를 게시하는 동시에 다음 프런트엔드를 개발할 수 있었습니다. 기존 WordPress 개발에서는 일반적으로 스테이징 환경과 같은 사이트로 사이트를 마이그레이션해야 합니다.

해당 환경에서 새 테마를 활성화하고 거기에서 테마를 구축하고 콘텐츠 제작자에게 "이봐, 오늘은 콘텐츠를 게시할 수 없습니다. 새 WordPress 인스턴스인 라이브 인스턴스를 다시 설정하겠습니다.” 그런 다음 거기에 로그인하여 콘텐츠를 올바르게 작성해야 합니다.

헤드리스 WordPress, 실제 WordPress 인스턴스에서 아무 것도 방해하지 않고 완전히 다른 프런트엔드 스택에서 내 사이트를 다시 빌드할 수 있었습니다. 데이터와 프레젠테이션이 분리된 것입니다. 맞습니까? 그래서 내일 차세대 핫 기술을 탐색하고 싶다면 갈 수 있습니다. 예를 들어 Next 대신 Svelte에 시선을 둘 수 있고 WordPress에서 아무것도 변경할 필요가 없습니다.

따라서 어떤 경우에는 실제로 더 저렴할 수 있습니다. 다른 서버를 가동하고 팀이 콘텐츠 작성을 중단한 다음 다른 WordPress 인스턴스로 이동한 다음 거기에서 게시를 시작하고 델타 마이그레이션을 수행하는 전체 프로세스, 그것도 비용이 있습니다.

또 다른 흥미로운 점은 JavaScript 생태계가 실제로 발전하고 있다는 것입니다. 내 생각에 헤드리스 이동에 대한 일반적인 동기 중 하나는 구성 요소 기반 아키텍처입니다. 그리고 React 및 VUE 생태계에는 모든 종류의 구성 요소 라이브러리가 있어 프로젝트 전체에서 구성 요소를 재사용할 수 있습니다.

따라서 에이전시는 프로젝트에서 사용하는 공통 구성 요소를 구축하고 중앙 위치에서 이를 업데이트한 다음 여러 프로젝트에 설치할 수 있습니다. WordPress를 사용하면 PHP 템플릿 부분과 WordPress가 일반적으로 그들이 속한 프로젝트와 매우 밀접하게 결합되기 때문에 쉽지 않습니다.

헤드리스를 사용하면 해당 구성 요소가 포함된 MPM 패키지를 가질 수 있고 여러 프로젝트에서 해당 패키지를 업데이트하고 적은 노력으로 동시에 이점을 얻을 수 있습니다. 그래서 지금은 아마도 비용이 더 많이 들고 더 많은 작업이 필요하다고 말하고 싶지만 최근까지 존재하지 않았던 Faust와 같은 도구가 헤드리스를 구축하는 데 필요한 전반적인 노력을 낮추고 있다고 생각합니다.

그리 멀지 않은 미래에는 헤드리스를 만들지 않는 것보다 헤드리스를 만드는 것이 더 저렴할 것입니다.

DP: Chris, 헤드리스 WordPress의 비용 측면에서 대행사가 고려해야 할 사항에 추가하고 싶은 것이 있습니까?

CW: 제이슨이 정말로 머리에 못을 박았다고 생각합니다.

그리고 그것이 WPGraphQL에 대해 제가 좋아하는 한 가지는 우리 팀이 우리가 부르는 방향으로 WordPress를 확장하는 작업을 하고 있다는 것입니다. 작업 제목은 React Gutenberg Bridge이지만 WordPress에서도 문제입니다. 이러한 구성 요소를 어떻게 재사용합니까? JavaScript 측에 적용되는 것과 같은 방식으로 WordPress 측에 적용되지 않기 때문에 단지 구성 요소라는 단어를 사용하고 싶지 않습니다.

그러나 헤드리스 또는 WordPress를 사용하여 프로젝트 전체에서 코드를 재사용하는 방법은 헤드리스가 가능합니다. 그러나 평균적인 블로거는 식도락가 블로그를 꺼내려고 노력하는 것일 뿐, 스스로는 다루지 않을 것이라고 말하는 것이 안전하다고 생각합니다. 그것은 대행사 문제입니다. 비용이 더 들까요?

아닐 수도 있고 아닐 수도 있지만 비용이 어디에 있는지에 대해 이야기할 때 복잡해집니다. 데이터를 사용하려는 방식이 다르기 때문입니다.

DP: 네, 물론이죠. 제이슨, Twin Cities와 Nashville의 Weeklys에서 일하는 신문 배경에서 56개 신문에 하루 동안 발행하지 말라고 하면 어땠을지 상상할 수 있습니다.

오늘은 사이트 업데이트 중이라 소식이 없습니다.

JB: 네. 그리고 제 말은, 우리는 그 기간을 겪었죠, 그렇죠? 내가 거기에 고용되었을 때처럼 그들은 WordPress에 없었기 때문에 다른 시스템에서 WordPress로 가져오는 것이 내 일의 일부였습니다. 그래서 확실히 WordPress의 날에 라이브가 시작되는 날이 있었습니다. 하던 일을 멈추세요. 오른쪽.

그래서 확실히 그런 기간이 있었거나 우리는 또한 그 문제를 처리해야 했습니다. 좋아, 그들은 어젯밤 자정까지 이전 시스템에 게시했지만 우리는 그 이틀 전에 갈 준비가 된 WordPress를 가지고 있었습니다. 이제 우리는 델타 마이그레이션처럼 해야 하고 모든 데이터가 여전히 동기화되어 있는지 확인해야 합니다. 그러면 이러한 프로세스에 대한 기술 및 인적 비용이 확실히 발생합니다.

DP: 네. 그리고 아직 워드프레스를 사용하고 있을 때 이러한 비용 절감을 얻을 수 있는 생태계를 얻을 수 있는 것도 많이 있다고 생각합니다. SEO 도구를 구축할 필요가 없습니다.

Yoast SEO 플러그인 등을 사용할 수 있습니다. 헤드리스 사이트이더라도 대부분의 플러그인은 정면을 향하지 않는 한 계속 작동할 것입니다.

JB: 네. 그것은 실제로 흥미로운 것입니다. 따라서 새로운 Faust는 플러그인 아키텍처 자체로 구축됩니다. 즉시 사용할 수 있는 것처럼 클라이언트와 함께 제공될 것입니다. Apollo 클라이언트를 사용하여 WPGraphQL에서 데이터를 가져올 수 있고 WordPress 데이터를 가져올 수 있지만 플러그인을 만들 수 있습니다. WordPress 사이트에 Yoast SEO를 설치하세요.

Yoast 플러그인을 추가할 수 있습니다. 아직 존재하지 않지만 곧 가능합니다. 해당 데이터로 무엇을 해야 하는지 알고 있는 프런트엔드에 Faust용 Yoast 플러그인을 추가할 수 있습니다. 그래서 사람들을 위한 능력이 있을 것입니다. 일부는 우리가 생산하고 지원할 수 있지만 일부는 커뮤니티가 Faust 측면을 위한 플러그인을 생산하고 지원할 수 있으므로 단 한 줄의 코드로 이 플러그인을 추가할 수 있습니다. 헤드리스 프런트 엔드를 위한 Yoast와 같은 기능을 활용하십시오.

Faust가 접근하는 것과 같은 방식으로 다른 헤드리스 프런트 엔드에는 개념이 없다고 생각합니다. 그래서 저는 플러그인이 WordPress 개발자에게 친숙한 또 다른 것이라고 생각합니다. WordPress에서 친숙한 개념을 가져오지만 최신 JavaScript 프런트엔드 스택과 연결합니다.

DP: 여기 Press This에서 마지막 휴식을 취하기에 좋은 장소입니다. 돌아오면 Chris Weigman 및 Jason Bahl과의 대화를 마무리하겠습니다. 계속 지켜봐 주세요.

DP: 지금 WordPress 커뮤니티 팟캐스트인 Press This를 듣고 계십니다. 저는 여러분의 호스트인 Doc Pop입니다. 오늘 우리는 WPGraphQL, Faust 및 헤드리스 WordPress 사이트를 강화하는 방법에 대해 이야기하고 있습니다. 휴식 직전에 우리는 Faust와 플러그인에 대해 이야기했고 저는 여러분 모두에게 임의의 질문을 던지고 여기에 좋은 답변이 있는지 확인하려고 합니다.

하지만 Chris, 저는 Faust와 함께 어떤 잠재력이 있는지 궁금합니다. 헤드리스 플랫폼이라는 것을 알고 있지만 WordPress Faust 테마와 같이 적어도 다음과 같이 설정할 수 있는 가능성이 있는지 궁금합니다. 여기 당신이 필요로 하는 플러그인이 있고 여기에 바로 사용할 수 있는 모든 것이 있습니다.

CW: 물론이죠. 사실, 우리는 이미 그것을 가지고 있습니다. Local과 매우 많이 작동하기 때문에 Blueprints라고 합니다. 대부분의 사람들은 WP 엔진과 같은 플랫폼에서 시작하기 전에 이 물건에 대해 일종의 조정을 할 것입니다. 그래서 우리는 Local의 Blueprints 이름을 빌렸습니다.

새로운 Faust의 경우 Portfolio라는 것이 있는데 기본적으로 전체 포트폴리오 테마이며 대행사가 사용할 수 있는 매우 빈 발판에 대해 작업하고 있습니다. 일단 요령을 터득하면 모든 것을 직접 맞춤화하고 싶을 것입니다. 따라서 스캐폴드는 프로젝트 모범 사례가 될 것입니다. 이를 활용하면 스캐폴드를 사용하여 모든 작업을 수행할 수 있습니다.

장기적으로 우리는 헤드리스 테마 스토어인 Blueprints에 대해 매우 많이 이야기했습니다. 우리는 인력이 없기 때문에 약간의 거리가 있지만 절대적으로 우리가 고려하고 있으며 우리가 보고 싶은 일입니다.

DP: 네, 생각만 해도 좋습니다. 그것은 완전히 다른 종류의 생태계에 들어가는 것입니다.

제이슨, 이전에 인터뷰한 적이 있고 이 질문이 항상 나올 것이라고 확신하지만 WPGraphQL에 대해 들을 때마다 REST API가 하는 것과 많이 비슷하다고 생각합니다. 실제로 이는 REST API가 수행하는 것보다 훨씬 강력하고 REST API가 코어의 일부인 것 같습니다. WPGraphQL이 WordPress Core의 일부가 되어야 한다고 생각하십니까?

JB 언젠가는. 나는 우리가 아직 거기에 있다고 생각하지 않습니다. 아마도 구텐베르크를 제외하고 WordPress Core에서 모든 것이 병합되면 혁신이 중단됩니다. 예를 들어 REST API에는 2016년부터 여전히 존재하는 사람들에게 지적하는 버그가 있습니다. 즉, 핵심에 들어갈 때 웹의 40% 정도에 기능 세트를 추가하고 따라서 변경 작업은 훨씬 느린 속도로 수행되어야 합니다. 플러그인인 경우 사람들이 원하는 버전을 선택하도록 할 수 있고 프로젝트에 가장 적합한 버전을 선택할 수 있기 때문에 훨씬 더 빠르게 반복할 수 있습니다.

코어에서 코어를 업데이트하고 여기에 브레이킹 체인지가 포함된 경우 웹의 40%가 손상되었을 수 있습니다. 따라서 GraphQL은 사양이며 WordPress와도 관련이 없습니다.

오른쪽. 따라서 GraphQL 사양은 계속 진화하고 있습니다. 그리고 그것이 계속 진화함에 따라 우리는 GraphQL 사양의 최신 및 최고의 사양을 따라잡기를 원합니다. 오늘날 WPGraphQL을 Core로 병합하고 GraphQL이 계속 진화한다면 WordPress는 GraphQL의 2022년 에디션에 머물고 나머지 세계는 2030년 버전에 머물러 있을 것입니다. 나에게는 WPCLI가 X 작업을 수행하는 공식적인 방법과 같은 것으로 인식되는 것이 어느 시점에서 이치에 맞을 것이라고 생각합니다.

WordPress용 CLI 클라이언트를 직접 구축할 수 있지만 WPCLI가 공식적인 것임을 커뮤니티에서 인정합니다. WordPress Core의 일부는 아니지만 WordPress Foundation 및 대부분의 WordPress 커뮤니티에서 공식적인 것으로 인정합니다. 따라서 어느 시점에서 WPGraphQL이 그렇게 인식되는 것이 좋을 수 있습니다. 예를 들어 헤드리스 WordPress를 수행하려는 경우 이 방법으로 수행합니다.

여전히 플러그인으로 남을 것입니다. 그게 제 생각입니다. GraphQL이 완벽하다고 느껴지고 실제로 반복되지 않는 경우가 있을 수 있으며 아마도 그 시점에 우리는 그것을 고려할 것입니다. 그러나 현재 GraphQL 사양에는 API에 주요 변경 사항이 적용되는 사항이 있습니다.

그래서 그것을 플러그인으로 하는 것은 나에게 여전히 의미가 있습니다.

DP: 맞습니다. 그리고 네, WPCLI에 대해 언급하셨는데 저는 계속 잊어버리고 있습니다. 마치 핵심의 일부인 것처럼 느껴집니다. 어떤 느낌이든 공식과 같습니다. 예, 예, 오 예, 그것은 현재 WPGraphQL과 마찬가지로 독립적인 것과 같습니다.

좋은 비유입니다. 그래서 저는 여기서 마무리하겠습니다. 두 분과의 대화는 정말 즐거웠습니다. 청취자가 귀하를 팔로우하는 데 관심이 있는 경우 @JasonBahl 및 @ChrisWeigman을 팔로우할 수 있습니다. 가능한 경우 쇼 설명에 Twitter 핸들을 넣겠습니다. WMR에서 WordPress 커뮤니티 팟캐스트인 Press This를 들어왔습니다.

다음 주 에피소드에서는 Automatic의 제품 연락 담당자인 Anne McCarthy가 사이트 편집 및 6.1의 변경 사항과 6.2에 나올 내용에 대해 이야기할 예정입니다. Press This를 들어주셔서 다시 한 번 감사드립니다.

Twitter @thetorquemag에서 Torque 잡지와 함께 제 모험을 팔로우하거나 우리가 매일 이와 같은 튜토리얼, 비디오 및 인터뷰를 제공하는 torquemag.io로 이동할 수 있습니다. 따라서 torquemag.io를 확인하거나 Twitter에서 팔로우하세요. Red Circle, iTunes, Spotify에서 Press This를 구독하거나 매주 wmr.fm에서 직접 다운로드할 수 있습니다. 저는 귀하의 호스트 Doctor Popular입니다. 저는 WP Engine에서의 제 역할을 통해 WordPress 커뮤니티를 지원합니다. 그리고 저는 매주 Press This에서 커뮤니티 회원들을 집중 조명하는 것을 좋아합니다.