헤드리스 CMS: WordPress를 사용한 Gatsby JS

게시 됨: 2020-05-04

WordPress는 콘텐츠 관리 시스템에서 50% 이상의 시장 점유율로 전 세계 상위 100만 웹 사이트의 약 3분의 1을 차지한다는 일반적인 지식입니다. 최근 2016년에 WordPress는 REST API를 도입하여 다른 애플리케이션에 WordPress 데이터베이스의 콘텐츠에 대한 향상된 액세스를 제공하기로 결정했습니다. 결과적으로 개발자에게 WordPress를 헤드리스 CMS로 활용할 수 있는 기능을 제공합니다.

흥미로운 워드 프레스 통계

이것은 필연적으로 엔지니어가 더 이상 WordPress의 기존 프레젠테이션 계층(프론트엔드)을 사용하는 데 국한되지 않고 모든 프론트엔드 애플리케이션을 활용하여 데이터를 제공할 수 있음을 의미했습니다. 이에 비추어 이 블로그의 대부분은 헤드리스 CMS 효과와 관련하여 WordPress와 Gatsby.js의 관계를 탐구합니다.

CMS의 간략한 역사

헤드리스 CMS 혁명을 이해하기 위해 한 걸음 물러나면서 콘텐츠 관리 시스템(CMS)의 역사를 요약하는 것은 주목할 만하다고 생각합니다. 전통적으로 90년대 초반에 정적 웹페이지는 웹마스터가 직접 HTML 파일을 편집하고 FTP를 통해 서버에 업로드하는 웹사이트를 실행하는 주요 방법이었습니다. 결국 90년대 중반에 웹 기술이 발전하기 시작하고 콘텐츠가 더욱 다이내믹해지면서 최초의 모놀리식 콘텐츠 관리 시스템이 등장하게 되었습니다.

cms 시스템의 역사

기본적으로 모놀리식 CMS는 웹에서 콘텐츠를 편집하고 게시하는 데 필요한 모든 것을 포함하는 소프트웨어 응용 프로그램입니다. 이러한 시스템 중 첫 번째는 EpiServer와 같은 기업으로 제한되었지만 나중에 WordPress, Drupal 및 Joomla와 같은 오픈 소스 변형이 나타났습니다. 나머지는 WordPress가 시간이 지남에 따라 가장 많은 시장 점유율을 얻은 역사입니다.

그러나 나중에 스마트폰 혁명 동안 모바일 장치는 웹 콘텐츠가 소비되고 전달되는 방식에 영향을 미치기 시작했습니다. 이는 랩톱 및 데스크톱용 웹 콘텐츠를 제공하도록 설계된 기존의 모놀리식 CMS에 대한 도전이었습니다.

이를 완화하기 위해 반응형 디자인이 탄생하여 화면 크기에 적응하는 웹사이트 레이아웃이 탄생했습니다. 결과적으로 이는 디스플레이 계층에서 콘텐츠 관리를 분리할 수 있는 기회도 제공했습니다. 헤드리스 CMS가 여기에 해당합니다.

헤드리스 CMS

앞서 언급했듯이 Headless CMS는 프레젠테이션 레이어가 없는 CMS입니다. 결과적으로 콘텐츠는 API(RESTful 또는 GraphQL)를 통해 별도의 프론트엔드 애플리케이션으로 전달된 다음 이를 제공합니다. API는 더 높은 수준의 보안과 확장성을 갖춘 다양한 도구와 프로그래밍 언어를 사용하여 모든 채널과 장치에서 콘텐츠를 사용할 수 있도록 합니다.

기본적으로 CMS는 프론트엔드 문제와 분리되어 있으므로 개발자는 사용 가능한 최고의 기술을 사용하여 최종 사용자를 위한 풍부한 경험을 구축할 수 있습니다. "헤드리스(headless)" 또는 "분리(decoupled)" 모드는 현재 대부분의 CMS에서 지원되며, 이는 Gatsby 사이트를 위한 길을 열었습니다.

따라서 헤드리스 CMS를 활용하려면 먼저 사이트나 애플리케이션을 구축한 다음 CMS의 API를 사용하여 콘텐츠를 연결해야 합니다.

워드프레스 헤드리스 CMS 실행

위에서 공유된 이벤트의 연대기와 관련하여 WordPress가 Headless CMS에 영향을 미치는 방법을 확인했습니다. WordPress에는 플러그인(기본적으로 '응용 프로그램 프레임워크')으로 확장할 수 있는 API(응용 프로그래밍 인터페이스)가 포함되어 있습니다. 특히 이것은 나중에 설명하겠지만 REST API를 통해 달성됩니다.

그러나 WordPress API의 핵심 개념 중 하나는 후크입니다. 기본적으로 후크를 사용하면 플러그인이 WordPress 핵심 기능을 변경할 수 있습니다. 실제로 후크는 WordPress에서 특정 이벤트(예: 페이지 로드 또는 편집 후)가 발생하면 WordPress가 특정 후크를 호출하여 기능을 실행하는 방식으로 작동합니다.

구체적으로 후크는 '액션'과 '필터'로 나뉩니다. 함수는 아무 것도 반환할 필요가 없지만 특정 이벤트에서 특정 PHP 함수를 실행하기 위해 작업을 활용할 수 있습니다. 필터는 WordPress가 특정 이벤트 동안 데이터를 전달하는 기능을 실행하는 데 사용할 수 있지만 이러한 기능은 데이터를 매개변수로 받아 수정된 버전의 데이터를 반환합니다.

워드프레스와 REST API

REST(Representational State Transfer)는 HTTP 프로토콜을 기반으로 하며 CRUD(데이터 생성, 읽기, 업데이트 및 삭제)를 위한 균일한 인터페이스 의미 체계를 제공합니다.

일반적으로 WordPress에서 REST API를 실행하면 개발자가 JSON(JavaScript Object Notation) 개체를 보내고 받아 WordPress 데이터베이스의 데이터에 원격으로 액세스할 수 있습니다. 결과적으로 이것은 개발자에게 WordPress로 엔지니어링되지 않은 다른 애플리케이션에서 WordPress 데이터를 생성, 읽기, 업데이트 및 삭제할 수 있는 기회를 제공합니다. 예를 들어 JavaScript 웹 애플리케이션 또는 기본 모바일 앱.

그러나 REST API 및 Gatsby와의 Headless WordPress CMS 관계를 더 깊이 이해함에 따라 WordPress API의 몇 가지 기본 개념에 유의해야 합니다.

wordpress-api의 기본 개념
  • 경로 및 끝점: 경로는 HTTP 호출을 통해 액세스할 수 있는 경로이고 끝점은 해당 경로에 매핑된 HTTP 메서드(예: get, post, put 또는 delete)입니다.
  • 요청: 등록된 REST 경로에 대한 HTTP 요청을 시작하면 WordPress가 자동으로 요청 객체를 생성합니다. 요청에 지정된 데이터에 따라 반환될 답변이 결정됩니다.
  • 응답: 응답 개체는 요청할 때 다시 받는 데이터입니다. 요청된 데이터 또는 오류 메시지로 구성될 수 있습니다.
  • 스키마: 스키마는 끝점의 데이터 구조를 나타냅니다. 각 끝점은 반환할 수 있는 데이터 구조가 약간 또는 상당히 다를 수 있습니다. 따라서 스키마는 끝점이 반환할 수 있는 모든 가능한 속성과 받을 수 있는 모든 가능한 매개 변수를 결정합니다.
  • 컨트롤러 클래스: 컨트롤러 클래스를 사용하면 개발자가 끝점과 경로를 관리 및 등록할 수 있으며 요청을 처리하고 스키마를 활용하며 응답을 생성할 수 있습니다.

React '프레임워크'

이제 Gatsby.js와 WordPress의 관계에 대해 자세히 알아보기 위해 더 많은 역사적 기초에서 이 기술 환경을 해독해야 합니다. React는 가장 빠르게 성장하는 JavaScript 프론트엔드 라이브러리/프레임워크이기 때문에 이 이야기의 핵심입니다. Facebook(핵심 개발자)에 의해 유명해진 다른 대형 웹사이트는 Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace 및 Tesla와 같은 프론트엔드에 React를 사용합니다.

결과적으로 React는 실제로 라이브러리이기 때문에(여전히 완전한 프레임워크의 주목할만한 기능이 부족하기 때문에), 이는 다른 '프레임워크'가 그 위에 엔지니어링될 수 있음을 의미합니다. 결과적으로 이들 중 하나가 Gatsby.js입니다.

개츠비 소개

상위 웹사이트에 따르면 Gatsby.js는 개발자가 빠른 웹사이트와 앱을 빌드하는 데 도움이 되는 React 기반의 무료 오픈 소스 JavaScript 프레임워크입니다. 원칙적으로 Gatsby.js는 초기 로드를 위해 애플리케이션에서 정적 HTML 페이지를 생성한 다음 단일 페이지 React 애플리케이션(SPA)으로 진행합니다.

Gatsby.js 속성

이러한 상황에서 Gatsby는 PWA(Progressive Web App) 원칙을 활용하여 먼저 필요한 요소만 가져온 다음 나중에 백그라운드에서 나머지 애플리케이션을 로드합니다. 또한 필요한 데이터만 로드되도록 Gatsby는 GraphQL 쿼리 언어(Facebook에서도 제공)를 활용하여 소스에서 데이터를 로드합니다. 또한 탁월한 이미지 최적화를 유지합니다.

이러한 모든 기능이 통합되어 개발자는 중요한 HTML, CSS, 데이터 및 JavaScript만 로드하므로 가장 빠른 웹사이트 및 웹 앱을 만드는 데 필요한 도구를 개발자에게 제공합니다. 따라서 페이지가 로드되면 Gatsby는 링크된 페이지에 대한 리소스를 미리 가져오기 때문에 사이트 탐색이 상당히 빠르게 느껴집니다.

또한 페이지는 컴파일 시 생성되므로 온라인 배치 전에 더 이상 강력한 PHP 서버가 필요하지 않으며 정적 파일(HTML, JS 및 CSS, 버킷 저장소에서 직접)을 제공할 수 있습니다. 또한 Gatsby는 React로 구동되기 때문에 구성 요소로 모든 것을 멋지게 구성할 수 있습니다. 이 모듈식 측면을 통해 개발자는 구성 요소를 쉽게 재사용할 수 있습니다.

gatsbyjs 기능

기본 제공되는 기타 중요한 Gatsby 기능은 다음과 같습니다.

  • 정적 사이트 생성기
  • 오프라인 액세스
  • 연결된 페이지 미리 가져오기
  • 페이지 캐싱
  • 외부 코드 가져오기 없음
  • 코드로 내보내기
  • 핫 리로드 콘텐츠
  • 핫 리로드 코드
  • 구성요소화
  • 단방향 데이터 바인딩
  • 선언적 API 데이터 쿼리(GraphQL)
  • 선언적 UI
  • 프로그레시브 이미지 로딩
  • 반응형 이미지 로딩
  • 중요한 CSS 인라인
  • 글꼴 자체 호스팅
  • 서버리스
  • 자산 파이프라인
  • CSS 확장(SaSS)
  • 고급 자바스크립트 구문
  • React 컴포넌트 생태계

개츠비 플러그인

기본적으로 Gatsby 플러그인은 기본적으로 Gatsby API를 사용하는 Node.js 패키지입니다. 이러한 플러그인은 데이터 소스를 추가하고, 데이터를 다른 형식으로 변환하고, 타사 서비스를 추가할 수 있습니다. Gatsby.org는 핵심 Gatsby 팀이나 제3자가 만든 많은 이미 만들어진 플러그인을 포함하는 플러그인 라이브러리를 유지 관리합니다. 이상적으로는 Gatsby 프로젝트용 플러그인을 설치하기 위해 개발자는 UNIX 터미널에서 노드 패키지 관리자(NPM)를 사용하고 npm install 명령을 실행합니다.

GraphQL이 Gatsby와 어떻게 관련되어 있는지.

GraphQL은 정확히 원하는 데이터를 API에 설명할 수 있고, 정확히 그 데이터를 받을 수 있다는 아이디어를 중심으로 합니다. 결과적으로 REST보다 효율적입니다. 이를 위해 Gatsby는 Webpack과 GraphQL을 사용합니다. 더 중요한 것은 GraphQL을 쿼리 언어로 사용하면 모든 것이 쿼리를 실행하는 클라이언트 측에서 정의되며 클라이언트는 애플리케이션의 작동 상태를 무시한다는 것입니다.

이 고유한 구현을 통해 개발자는 모든 데이터 소스를 Gatsby에 연결할 수 있습니다. 예를 들어 블로그 게시물은 Markdown 파일, Google 시트 또는 다른 WordPress 웹사이트에서 가져올 수 있습니다. 따라서 콘텐츠 전달에 향상된 유연성을 제공합니다.

Gatsby-WordPress 메커니즘(소스 플러그인)

이 관계를 더 풀면서 소스 플러그인을 이해해야 합니다. 소스 플러그인은 Gatsby의 데이터 시스템 내에서 작동하는 특수 플러그인입니다. 이름에서 이미 알 수 있듯이 로컬 또는 원격의 다른 위치에서 데이터를 소싱합니다. 결과적으로 데이터는 Gatsby가 노드 및 노드 필드라고 부르는 것으로 바뀝니다. 기본적으로 노드 필드는 하나의 노드 내 단일 데이터 조각을 나타내며, 궁극적으로 이러한 노드는 GraphQL 쿼리를 통해 액세스할 수 있습니다.

동일한 범위에서 Gatsby는 소스 플러그인을 통해 수십 개의 헤드리스 CMS 옵션을 지원하여 엔지니어링 및 콘텐츠 팀이 선호하는 관리 인터페이스의 편안함과 친숙함과 향상된 개발자 경험 및 Gatsby, GraphQL 및 React를 사용하여 빌드하는 성능 이점을 활용할 수 있습니다. 프론트엔드.

'Gatsby-source-WordPress' 플러그인은 Gatsby 핵심 팀에서 구축 및 유지 관리하며 자체 호스팅 WordPress 사이트 또는 WordPress.com에서 데이터를 가져옵니다. 또한 Word-Press.com API에 대한 OAuth 인증을 수반하며 개발자가 반응형 이미지를 쿼리할 수도 있습니다.

기본적으로 이 플러그인은 게시물, 페이지, 태그, 카테고리, 미디어, 유형, 사용자, 상태, 분류, 사이트 메타데이터 및 사용자 정의 게시물 유형과 같은 WordPress REST API의 모든 엔터티를 지원합니다. 또한 REST API에 등록된 다른 포스트 메타 외에도 ACF(Advanced Custom Fields) 엔터티와 Polylang 및 WPML 언어 정보도 지원됩니다.

따라서 이 플러그인을 사용하면 기본적으로 wpjson의 모든 끝점을 가져오지만 개발자는 가져올 경로를 선택할 수 있습니다. 따라서 개발자는 위의 메커니즘을 사용하여 GraphQL을 사용하여 WordPress에서 데이터를 가져올 수 있습니다.

실제로 'Gatsby-source-WordPress' 도구는 모든 게시물 및 기타 엔터티에 대한 슬러그를 제공합니다. 따라서 엔지니어는 'createPage' 함수를 호출하여 페이지를 생성하기만 하면 됩니다. 이는 Gatsby-node.js 파일에서 일반적으로 먼저 데이터 소스에 대한 쿼리를 실행한 다음 발견된 각 노드에 대해 'createPage'를 호출한 다음 구성 요소로 사용할 템플릿 파일을 설정하여 실행됩니다.

CI/CD 및 애플리케이션 릴리스 자동화.

Gatsby로 헤드리스 WordPress CMS를 구현할 때 배포 수행 방법이 매우 중요합니다. 일반적으로 이러한 실행에는 ARA(응용 프로그램 릴리스 자동화)를 사용하여 자동화할 응용 프로그램 배포가 필요합니다.

애플리케이션 릴리스 자동화

일반적으로 ARA에는 다음과 같은 주요 기능이 포함됩니다.

  • 데이터, 애플리케이션 코드 및 아티팩트 배포.
  • 각 환경에 대한 특정 구성 배포
  • 작업 및 배포 단계를 자동화하기 위한 프로세스 워크플로 디자인.
  • 마지막으로 환경 모델링 및/또는 프로비저닝 바이너리

Gatsby는 정적 사이트를 생성하기 때문에 ARA 파이프라인을 설정하여 WordPress에서 콘텐츠가 업데이트될 때 Gatsby 사이트에서도 이에 따라 업데이트될 수 있도록 해야 합니다. 일반적으로 연속 배포는 코드가 변경될 때만 트리거되지만 이 경우 데이터가 변경될 때 트리거하는 것이 바람직합니다. 따라서 이를 위해 Netlify를 사용하는 것이 좋습니다. 뛰어난 내장형 연속 배포 기능을 보유하고 있으며 사용자 친화적으로 설정할 수 있습니다.

GraphQL 및 gatsby-source-WordPress를 사용하여 WordPress에서 쿼리

예를 들어, gatsby-source-WordPress는 REST를 사용하여 엔드포인트의 모든 것을 먼저 가져오는 방식으로 작동합니다. 그런 다음 해당 데이터를 기반으로 내부 GraphQl API를 생성합니다. 그런 다음 쿼리를 통해 내부 GraphQL API에서 데이터를 수집합니다. 따라서 기본적으로 빌드는 요청한 데이터로만 끝납니다.

headless-wordpress-development-with-gatsby-js의 장점

Gatsby.js를 사용한 헤드리스 워드프레스 개발의 장점

Gatsby를 사용한 Headless WordPress 개발에 대해 다루었으므로 이제 이러한 종류의 기술적 접근 방식의 장점을 분류할 수 있습니다. 이것은 본질적으로 Gatsby를 채택할지 여부에 대한 결정을 안내해야 합니다!

  • 첫 번째 이점은 미리 렌더링된 정적 사이트를 가질 수 있다는 것입니다. 이것은 웹 페이지를 렌더링하는 가장 효율적인 방법이며 Gatsby는 GraphQL을 사용하여 필요한 최소한의 데이터를 실행하기 때문에 초기 로드 후 시간 동안 약간의 추가 효율성을 제공합니다.
  • 향상된 SEO 가시성: 정적 페이지는 모든 것이 사전 렌더링되고 인덱싱 가능하므로 검색 엔진에서 쉽게 읽을 수 있습니다. 이는 JavaScript로 페이지를 렌더링하는 것이 검색 엔진 최적화(SEO)와 관련된 문제인 다른 헤드리스 메커니즘과 달리 긍정적입니다.
  • 상대적으로 빠른 개발 속도: 다른 헤드리스 접근 방식과 비교할 때 Gatsby는 소스에 관계없이 데이터를 가져오는 단일하고 이해하기 쉬운 방법을 가지고 있습니다. 이렇게 하면 실제 사이트에 집중할 수 있고 Gatsby가 대부분의 어려운 작업을 수행할 수 있으므로 개발이 다소 단순화됩니다.
  • 저렴한 호스팅: Gatsby 애플리케이션은 정적 파일만 제공하므로 호스팅 비용을 절감할 수 있기 때문에 어디서나 호스팅할 수 있습니다. 또한 WordPress는 빌드 프로세스 중에만 호출되고 사용자 세션 중에는 호출되지 않으므로 저렴한 호스팅 솔루션에서도 호스팅할 수 있습니다.
  • 보안 강화: 일반적으로 정적 사이트 생성기는 데이터베이스, 종속성, 사용자 데이터 또는 기타 민감한 정보에 직접 연결되지 않기 때문에 매우 안전합니다.
  • 플러그인 무료: 비 개발자의 관점에서 WordPress는 사용 가능한 플러그인으로 인해 작동하기가 매우 쉽습니다. 그러나 이것은 사용자 정의 기능의 구현을 제한합니다. 불행히도 플러그인이 너무 많으면 사이트가 무거워지고 렌더링하기 어려워지기 때문에 사이트 속도가 느려질 수 있습니다. Gatsby 실행은 본질적으로 이러한 모든 병목 현상을 우회합니다.

WordPress와 함께 Gatsby를 고려하도록 동기를 부여할 수 있는 더 많은 측면:

  • WordPress 관리자 패널을 관리하기 쉽습니다.
  • 사용자 로그인 시스템 및 권한을 사용할 준비가 되었습니다.
  • Gatsby 및 Gutenberg 편집기를 사용하여 끌어서 놓기 Gatsby 사이트 빌더를 구축할 수 있습니다.

Gatsby.js를 사용한 Headless WordPress 개발의 단점

  • 업데이트 제한: 콘텐츠가 처음부터 변경되면 사이트가 업데이트할 수 있는 빈도에 대한 제한이 설정됩니다. 또한 사이트에 많은 데이터가 포함된 경우 Gatsby 빌드를 실행하는 데 최대 10분이 소요될 수 있으며 이는 자주 업데이트되는 사이트의 문제일 수 있습니다.
  • 정기 업데이트 허슬: 또한 Gatsby는 정적 사이트 생성기이므로 작은 텍스트 변경에도 새로운 배포가 필요하기 때문에 그냥 "편집"할 수 없습니다. 따라서 동적 일일 콘텐츠 변경이 많이 필요한 페이지가 있는 경우 시간이 많이 걸리고 번거로울 수 있습니다.
  • 지연: 콘텐츠가 라이브로 전환될 때 변경 사항을 확인하려면 일반적으로 몇 분 정도 기다려야 합니다.
  • 미리보기 부족: 기존 WordPress 애플리케이션과 달리 Gatsby에는 미리보기가 없습니다. 슬프게도 이것은 콘텐츠 제작자가 Gatsby에서 발견한 가장 큰 문제였습니다. 웹사이트를 컴파일하고 모든 것을 온라인에 올리는 Gitlab CI/CD 파이프라인을 사용하여 모든 것을 컴파일해야 합니다.
  • 가파른 학습 곡선: 일반적으로 Gatsby와 WordPress를 동시에 사용하려면 PHP와 JavaScript 언어에 비교적 익숙해야 합니다. Gatsby는 React와 GraphQL을 병합하므로 많은 사람들에게 이것은 가파른 학습 곡선이 될 수 있습니다.

마지막 생각들.

결론적으로, 성능 및 비즈니스 이점 덕분에 더 많은 회사가 기술 스택의 일부로 Gatsby를 구현하고 있습니다. Gatsby를 WordPress와 결합하면 WP가 백엔드 전용이 되어 일부 기능과 능력을 잃게 된다는 점을 기억하는 것이 중요합니다.

또한 WordPress 개발 경험이 있는 개발자는 Gatsby가 최신 성능, 확장성, 보안 및 개발 속도 이점을 갖춘 훌륭한 도구임을 알게 될 것입니다. 이 모든 것이 WordPress에서 제공하는 친숙한 콘텐츠 생성 사용자 인터페이스를 유지하도록 허용합니다.

그러나 이 기술을 시작하기 전에 항상 프로젝트 사양과 목표를 고려해야 합니다. 예를 들어 확장성, 성능, 개발 속도, 긴 수명 주기에 중점을 둔다면 Gatsby가 그렇게 할 것입니다. 그러나 초 또는 분 단위로 콘텐츠가 업데이트되는 프로그래머가 아닌 콘텐츠 작성자를 위한 향상된 유연성과 도구를 강조하는 경우 다른 접근 방식을 고려할 수 있습니다.