DE{CODE}: WordPress 개발자를 위한 헤드리스 101

헤드리스 개발은 기존 WordPress 개발보다 더 강력하고 재미있을 수 있습니다. 그러나 이 신흥 스택에 새로운 선택이 너무 많은 경우 시작하는 가장 좋은 방법은 무엇입니까? 이 워크숍에서는 헤드리스용 WordPress 프로젝트를 설치하고 최적화하는 과정부터 분리된 프런트엔드에서 첫 번째 페이지를 템플릿으로 만드는 과정까지 빌더를 안내합니다.

세션 슬라이드

전체 텍스트 성적 증명서

GRACE ERIXON : WordPress 개발자를 위한 Headless 101에 오신 것을 환영합니다. 제 이름은 Grace Erixon이고 여기 WP Engine의 부개발자 옹호자입니다. 저와 합류하는 사람은 Haus의 Steve입니다. 오늘은 헤드리스 WordPress가 무엇인지, 그리고 어떻게 사용을 시작할 수 있는지에 대해 간략하게 소개하겠습니다.

따라서 헤드리스 WordPress 웹사이트 아키텍처가 무엇인지 이해하려면 기존 WordPress 아키텍처가 어떻게 생겼는지에 대해 모두 같은 페이지에 있는지 확인하는 것이 중요합니다. 전통적으로 WordPress와 같은 CMS는 웹사이트의 프런트 엔드와 백엔드를 모두 처리합니다.

기존 아키텍처에서 게시자는 WordPress 내부의 블로그 게시물 및 페이지와 같은 콘텐츠를 만들고 관리합니다. 개발자는 PHP 및 WordPress의 테마 API를 사용하여 사이트의 모양과 기능을 제어하는 ​​코드를 작성합니다. 그런 다음 WordPress는 방문자에게 전송되는 HTML 페이지를 생성합니다.

이 결합된 CMS 아키텍처에서 WordPress는 게시자에게 콘텐츠 관리 기능을 제공합니다. 또한 웹사이트 방문자에게 HTML 페이지를 제공하는 역할도 합니다. 헤드리스 CMS는 프런트 엔드와 백 엔드가 별도로 관리되는 분리된 아키텍처를 사용합니다. 헤드리스 아키텍처에서 게시자는 여전히 기존 WordPress 아키텍처와 마찬가지로 WordPress에서 콘텐츠를 만들고 관리합니다.

개발자는 JavaScript에서 사이트의 모양과 기능을 제어하는 ​​코드를 작성하고 WPGraphQL 또는 REST API를 사용하여 WordPress에서 데이터를 가져옵니다. Faust.js, Next.js, Nuxt.js 또는 SvelteKit과 같은 프레임워크는 종종 이 프런트엔드 애플리케이션을 구동하는 데 사용됩니다. 그런 다음 프런트 엔드 JavaScript 애플리케이션은 웹 사이트 방문자에게 전송되는 HTML 페이지를 생성하고 제공합니다.

기존 아키텍처와 달리 WordPress는 더 이상 HTML 페이지 생성을 담당하지 않습니다. 따라서 WordPress 백엔드와 프런트엔드 JavaScript 애플리케이션 간의 콘텐츠 교환을 위한 상호 작용은 API 계층을 통해 발생합니다. API 계층에 대한 두 가지 옵션은 WordPress REST API 또는 WPGraphQL입니다.

REST API는 WordPress와 함께 번들로 제공됩니다. 그러나 REST가 각 리소스에 고유한 끝점이 있어야 하므로 필요한 데이터 액세스 패턴이 느려질 수 있습니다. 예를 들어 완전히 모델링된 게시물을 재구성하려면 여러 번의 왕복이 필요합니다. 게시물의 콘텐츠, 작성자 및 범주를 가져오려면 세 가지 별도의 API 호출이 필요합니다.

반대로 WPGraphQL을 사용하면 게시물의 콘텐츠, 작성자 및 카테고리를 한 번의 요청으로 모두 요청할 수 있습니다. 이 때문에 WPGraphQL은 우리가 선호하는 API 계층입니다. WPGraphQL은 확장 가능한 GraphQL 스키마와 WordPress 사이트용 API를 제공하는 무료 플러그인입니다. WPGraphQL은 요청된 정확한 데이터를 가져오고 쿼리 최적화를 통해 실행되는 함수가 적고 데이터 다운로드가 적고 데이터 로드가 더 효율적이며 단일 요청에 여러 리소스가 포함되기 때문에 REST API보다 빠릅니다.

헤드리스 아키텍처는 개발자에게 JavaScript 프레임워크가 가장 널리 사용되는 모든 프런트 엔드 기술 스택에서 자유롭게 선택할 수 있도록 합니다. 가장 인기 있는 프런트 엔드 JavaScript 프레임워크에는 React, Vue.js 및 Svelte가 있습니다. 새로운 프레임워크가 항상 출시되고 있으므로 이 목록은 거의 종합적이지 않습니다.

이러한 JavaScript 프레임워크 중 다수는 라우팅, 서버 측 렌더링 등과 같은 솔루션을 추가하는 메타 프레임워크와 함께 사용됩니다. React는 Next.js와 함께 사용되며 Vue.js는 Nuxt.js와 함께 사용되며 Svelte는 SvelteKit과 함께 사용됩니다. Gatsby는 또 다른 유명한 메타 프레임워크입니다.

WP Engine은 React 및 Next.js 위에 구축된 JavaScript 프레임워크인 Faust.js를 개발했습니다. Faust는 헤드리스 WordPress 웹 애플리케이션을 지원하기 위해 특별히 제작되었습니다. 즉시 인증 및 사후 미리보기를 지원하고 WordPress 데이터에 액세스하기 위한 편리한 내장 React 후크 등을 제공합니다.

그래서 우리는 헤드리스 WordPress 아키텍처의 의미와 사용할 기술의 종류에 대해 이야기했습니다. 하지만 헤드리스를 선택하는 이유에 대해 빠르게 살펴보겠습니다. WordPress 자체는 무거운 CMS이며 빠른 언어가 아닌 PHP를 사용합니다. Headless WordPress는 JavaScript를 통해 위탁 언어를 사용하고 API 호출을 통해 필요한 파일만 로드합니다. 훨씬 더 가벼워 사이트가 더 빨리 로드됩니다.

헤드리스 WordPress는 또한 데이터가 프런트 엔드 배달과 별도로 존재하므로 콘텐츠에 대한 위험을 최소화합니다. 웹 공격에 덜 노출됩니다. 그리고 주요 이점은 헤드리스 WordPress 아키텍처를 통해 게시자는 WordPress가 제공하는 훌륭한 게시 환경의 이점을 계속 누릴 수 있으며 개발자와 웹 사이트 방문자는 최신 JavaScript 애플리케이션이 테이블에 제공하는 기술적 기능을 활용할 수 있습니다.

이제 실제 헤드리스 사이트의 코드를 파헤쳐 보겠습니다. 새로운 Atlas Blueprints 헤드리스 WordPress 사이트의 연습을 미리 녹음했습니다. Atlas의 새로운 Blueprints 기능은 완전한 헤드리스 WordPress 사이트를 시작하고 실행할 수 있는 정말 쉬운 방법을 제공합니다. 시작 코드, 플러그인, 콘텐츠 모델 및 페이지 구조와 함께 제공되어 앱을 더 빠르게 시작할 수 있습니다.

이제 새로운 Blueprint 사이트를 생성하여 코드를 살펴보겠습니다. WP Engine 대시보드 내부에서 Atlas로 이동합니다. 앱 만들기를 클릭합니다. Blueprint로 시작을 선택합니다. 그런 다음 사용할 청사진을 선택합니다. 포트폴리오 청사진을 선택하겠습니다.

그런 다음 WP Engine 계정을 GitHub 계정에 연결하고 해당 청사진을 새 리포지토리에 복제합니다. 빌드하는 데 몇 초가 걸립니다. 마지막으로 방금 생성한 리포지토리의 이름과 가장 가까운 지역을 선택한 다음 Create App을 클릭합니다.

이제 Atlas URL을 클릭하면 헤드리스 WordPress 사이트가 어떻게 생겼는지 확인할 수 있습니다. 특히 게시물 페이지에 관심이 있습니다. 보시다시피 사이트는 가장 최근의 모든 게시물을 이 블로그 페이지로 가져오고 있습니다. 또한 각 게시물에는 자체 개별 보기 페이지가 있습니다. 하지만 이 모든 데이터는 어디에서 오는 것일까요?

WP Engine 대시보드로 돌아가면 WP Admin 버튼이 표시됩니다. 헤드리스 WordPress 사이트의 백엔드가 있습니다. 게시물을 클릭하면 웹 앱이 가져오는 것과 동일한 목록이 표시됩니다. 이제 블루프린트가 복제된 GitHub 리포지토리를 열 수 있습니다. 그리고 해당 리포지토리를 로컬 환경으로 복제해 보겠습니다.

그런 다음 내가 가장 좋아하는 코드 편집기인 Visual Studio Code에서 이 리포지토리를 열겠습니다. 프로젝트 디렉토리를 자세히 살펴보면 블로그 페이지용 파일은 SRC, 페이지, 게시물, Index.js에서 찾을 수 있습니다. 이 프로젝트는 React, Next.js, Faust.js 및 WPGraphQL을 사용하여 빌드되었습니다. React나 JavaScript에 익숙하지 않다면 처음에는 혼란스러워 보일 수 있습니다.

첫 번째 섹션에서 파일은 내부 및 외부 소스에서 필요한 항목을 가져옵니다. 포스트 노드 사전 전달 필드를 정의하는 두 번째 섹션은 필요한 모든 데이터가 나열되는 곳입니다. 사전 통과를 통해 이를 실행하면 필요할 때 데이터가 있고 계단식 요청이 발생하지 않습니다.

그런 다음 페이지 기능이 있습니다. 처음에는 몇 가지 다른 변수, 즉 일반 설정과 페이지가 매겨진 게시물 목록에 필요한 데이터를 수집하는 것뿐입니다. return 문 내부의 태그는 웹 페이지에서 시각적으로 렌더링되는 코드입니다. 먼저 헤더에 대한 구성 요소가 있습니다. 그런 다음 이 기본 구성 요소 내부에는 항목 헤더 구성 요소가 있으며 페이지 상단에 최신 게시물이라는 큰 제목이 표시됩니다.

마지막으로 페이지가 매겨진 게시물 목록을 매개 변수로 받아들이는 게시물 구성 요소에 도달합니다. 이 정보로 포스트 구성 요소가 수행하는 작업을 살펴보겠습니다. 여기서는 수신한 게시물 목록에 포함된 각 게시물을 반복합니다. 각 게시물에 대해 최신 게시물 페이지에 카드와 같은 보기를 표시합니다. 첫 번째는 개별 블로그 게시물의 페이지에 대한 링크로 래핑된 추천 이미지 구성 요소, 게시물 제목의 제목 및 게시물의 날짜와 작성자로 구성된 게시물 정보 구성 요소로 구성됩니다.

모든 게시물을 표시하는 Index.js 파일로 돌아가서 요청 시 더 많은 게시물과 바닥글을 검색하기 위해 페이지 하단에 추가 로드 구성 요소를 표시하여 이 작업을 완료합니다. 마지막 함수인 getStaticProps는 함수에서 반환된 props를 사용하여 빌드 시 이 페이지를 사전 렌더링하도록 지시하는 Next.js 정적 사이트 생성 함수입니다. 그리고 그게 다야.

Headless 설정을 처리해 준 Blueprints에게 감사드립니다. WPGraphQL을 사용하여 WordPress 백엔드에서 데이터를 가져오고 React 구성 요소를 사용하여 게시물을 표시하기 위해 게시물 페이지에 들어가는 내용을 분석하는 것은 간단했습니다. 시청해 주셔서 감사합니다. Twitter @graceerixon에서 저를 찾을 수 있습니다.

Headless WordPress에 대한 자세한 내용은 developer.wpengine.com을 확인하세요. Faust.js를 사용하여 첫 번째 Headless WordPress 사이트를 처음부터 빌드하는 방법에 대한 자습서가 있으며 현재 Headless 101 콘텐츠 시리즈를 작업하고 있습니다. 무료 Sandbox 계정에 가입하면 Atlas가 제공하는 모든 도구를 사용할 수 있습니다. 이제 Haus가 leoburnett.com 프로젝트를 위해 Headless WordPress를 선택한 이유에 대해 자세히 이야기하기 위해 Steve에게 전달하겠습니다.

STEVE SCAVO: 고마워요, 그레이스. 안녕하세요, 저는 Haus의 CTO인 Steve Scavo입니다. 우리는 캘리포니아 로스앤젤레스에 소재한 크리에이티브 기술 스튜디오이자 에이전시입니다. 이 강연의 제목은 WordPress 개발자를 위한 Headless 101입니다. 솔직히 말씀드리자면 저는 직업상 WordPress 개발자는 아니지만 이것이 헤드리스 아키텍처의 아름다움의 일부라고 생각합니다.

따라서 WordPress를 활용해야 하는 비 WordPress 개발자를 위해 이 Headless 101을 쉽게 호출할 수 있었습니다. 그것은 적절한 제목이었을 것입니다. 그것이 머리가 없는 것이 아름다운 것입니다. 보시다시피 모든 면에서 윈-윈입니다.

그렇다면 왜 머리가 없습니까? 우리가 말할 수 있는 높은 수준의 이유가 너무 많지만 실제 프로덕션 사례와 그것이 빛날 때의 실제 사례에 대해 이야기하는 것이 정말 도움이 된다고 생각합니다. 헤드리스 아키텍처에서 헤드리스를 사용하여 Leo Burnett을 위해 수행한 프로젝트를 소개하고 싶습니다. 맥락상 Leo Burnett은 시카고에 기반을 둔 유서 깊은 광고 대행사이지만 전 세계적으로 많은 지사를 두고 있습니다. 그래서 그들은 많은 콘텐츠와 많은 작업을 가지고 있습니다.

이전 사이트는 단일 WordPress 테마로 운영되고 있었습니다. 정말 단편적이고 느리고 성능이 좋지 않았습니다. 업데이트하기 어려웠고, Leo Burnett이 전달하고자 했던 일종의 캐쉬와 브랜딩을 제대로 보여주지 못했습니다. 이것이 우리가 디자인 관점에서 작업한 것입니다. 그리고 스택을 현대화하기 위해 헤드리스를 선택했습니다.

우리는 단지 그것이 생생하고 신선하게 느껴지고 멋진 사용자 경험과 UI를 실제로 결합하는 데 필요한 그런 종류의 기능을 갖기를 원했습니다. 우리는 그들의 출판력을 높이고 싶었습니다. 콘텐츠를 게시할 수 있는 주기를 늘리고 싶었습니다. 우리는 브랜드 아이덴티티를 재정립하고 UI와 상호 작용, Leo Burnett이 실제로 스며나온 웹 사이트에 대한 느낌과 이러한 모든 작은 손길과 그들이 전달하고자 하는 일종의 편집 및 인쇄 및 상호 작용 포인트를 원했습니다.

그리고 우리는 미래를 위한 코드 베이스와 웹사이트를 준비하고 싶었습니다. 우리는 사이트가 향후 12개월 동안 관련성이 있기를 원하지 않았습니다. 우리는 그것이 다음 10년 동안 관련이 있기를 원합니다. 저는 이 헤드리스 아키텍처, 헤드리스 스택이 실제로 그렇게 한다고 생각합니다.

따라서 헤드리스의 초기 문제 중 하나는 호스팅, 배포 및 인프라에 대해 항상 많은 결정이 있으며 항상 큰 어려움을 겪었다는 것입니다. 따라서 이러한 스택 결정은 항상 개발자에게 맡겨졌습니다. 그리고 주변을 둘러보고 생각합니다. 어떤 제3자, 아마도 CI/CD 애플리케이션을 사용해야 할까요? 이것을 AWS에서 호스팅할 예정입니까? 어떻게 하죠? 어떤 서비스? 그런 다음 이러한 종류의 잠재적으로 이러한 종류의 임시 솔루션을 해당 흐름에 구현합니다.

글쎄요, Atlas와 WordPress Engine Atlas 플랫폼은 이 문제를 정말 해결합니다. 이것이 작동하는 곳입니다. 우리는 이러한 모든 이유로 Atlas를 선택했고 Atlas는 이 관리형 서비스 인프라를 보유하고 있습니다. CI/CD 파이프라인을 표준화합니다. 당신은 그것에 대해 정말로 생각할 필요가 없습니다.

본질적으로 한 번의 클릭 흐름으로 내려가는 환경 간에 데이터 마이그레이션이 있습니다. 역사적으로 QA에서 스테이징, 프로덕션으로 이동할 때 항상 큰 문제였습니다. 본질적으로 WordPress 엔진과 Atlas 플랫폼은 한 번의 클릭으로 그것을 가져왔습니다.

그리고 마이크로서비스와 DevOps에 대한 피로도가 있습니다. 개발자로서 그것에 대해 얼마나 많이 생각하고 지원하고 인식하고 계속 실행해야 하는지에 대한 인지적 부담이 큽니다. 이것들은 Atlas 플랫폼이 실제로 당신의 손에서 벗어나 유익한 방식으로 해결하는 모든 것입니다.

헤드리스가 실제로 촉진하고 강조하는 몇 가지 역학에 대해 이야기해 봅시다. 여기 첫 번째 기둥은 세 개입니다. 첫 번째 기둥은 개발자 경험입니다. 작업에 적합한 도구를 선택할 수 있습니다. 우리라고 하면 개발자를 의미합니다.

그것은 우리가 코드를 작성하고 싶은 스택을 선택할 수 있게 해줍니다. 그리고 그것은 우리에게 Haus에 있고 Next.js와 React입니다. Next.js는 라우팅, 성능 및 애플리케이션 아키텍처에 대한 몇 가지 정말 멋진 규칙을 중심으로 한 훌륭한 프레임워크입니다. 그리고 우리는 또한 디자인 시스템을 구현하고 싶었습니다. 단지 시각 디자인 시스템이 아니라 코드화된 디자인 시스템이었습니다. 이것은 애플리케이션을 일관되고 테스트되고 아름답게 유지하는 것입니다.

상호 작용은 일관됩니다. 이를 통해 우리는 앞으로 해당 생태계에 새로운 페이지와 기능을 구축하고 이를 유지하고 일관성을 유지할 수 있습니다. 또한 선언적 표현 코드를 작성할 수 있으며 React는 이를 라이브러리로 보증합니다. 그러나 우리는 또한 팀으로서의 글쓰기 스타일을 믿습니다. 이를 통해 프런트 엔드에서 해당 스택을 선택할 수 있지만 전통적인 테마 기반 WordPress 사이트일 수 있지만 실제로는 동일한 사치가 없습니다.

우리는 또한 많은 창의적인 헤드룸이 필요합니다. leoburnett.com을 방문하면 아름다운 페이지 전환이 있음을 알 수 있습니다. 우리는 사물을 렌더링하는 방법에 대해 기존 WordPress 스택에 얽매이지 않습니다. WordPress는 더 이상 프런트엔드 렌더링을 담당하지 않습니다.

우리의 헤드룸은 사실상 무한합니다. 애니메이션 라이브러리를 선택할 수 있습니다. 구성 요소가 서로 상호 작용하는 방식을 선택할 수 있습니다. DX 측면에서 큰 이점입니다.

관리자 경험이 향상되었으며, 이전의 친숙함에서 벗어나지 않았기 때문에 이를 최적화했다고 생각합니다. 백엔드 컷오버가 없습니다. 우리는 WordPress에서 WordPress로 이동했습니다. 다른 독점 시스템으로 이동하기 위해 데이터를 내보내고 일종의 스크립트를 작성할 필요가 없었습니다. 그래서 친숙함이 엄청납니다. 우리는 leoburnett.com의 현재 관리자를 위해 이러한 종류의 흐름을 유지하고 싶었습니다.

채택 및 문서화 – 웹에서 5분을 보낸다면 아마도 WordPress 백엔드를 만졌을 것이며 이는 아무리 강조해도 지나치지 않습니다. Leo Burnett은 또한 매우 구체적인 콘텐츠 포인트와 사용자 정의 필드를 많이 가지고 있습니다. WordPress는 이를 제공하고 그 힘을 제공하지만 고급 사용자 정의 필드 플러그인을 구현할 수 있었습니다. 이는 관리 UI를 조정하여 정말 친숙하고 사용하기 쉽게 만드는 것과 관련된 정말 좋은 규칙입니다. 그래서 그것은 관리자 경험에서 승리했습니다.

이제 세 번째 기둥은 물론 사용자 경험입니다. 정말 중요한 것입니다. 사용자 여러분, 저는 Haus의 웹 애플리케이션이 기본 애플리케이션처럼 느껴져야 한다고 생각하는 것과 매우 유사하다고 생각합니다. 중단이 없어야 합니다. 사용자들도 그 점을 정말 높이 평가한다고 생각합니다.

원활합니다. 반응이 좋습니다. 그들은 단지 기분이 좋습니다. 그리고 우리는 Leo Burnett과 우리의 모든 애플리케이션이 그렇게 느끼기를 원했다고 생각합니다. 프런트 엔드에서 원하는 스택을 선택할 수 있으므로 그렇게 할 수 있습니다.

기본 앱은 본질적으로 백엔드 콘텐츠 인프라와 분리되어 있으며 웹 앱도 마찬가지입니다. 이것이 바로 Atlas가 홍보하는 것입니다. 이것이 일반적으로 헤드리스 아키텍처가 촉진하는 것입니다. 또한 성능을 촉진합니다. 우리는 보편적으로 UI를 렌더링할 수 있습니다. 이는 초기 로드가 서버 측에 있음을 의미합니다. 그 후 클라이언트가 인수합니다.

여기에는 많은 이점이 있습니다. 하나는 검색 엔진을 행복하게 만든다는 것입니다. 그들은 서버 측 콘텐츠입니다. 빠르다. 또한 거의 즉각적으로 다음 페이지를 사전 렌더링하고 뷰포트에 있는 항목을 기반으로 요청을 한 번에 수행할 수 있습니다.

Leo Burnett의 경우 사용하기로 선택한 콘텐츠 API 측면에서 GraphQL 끝점을 설정합니다. 즉, 더 적은 페이로드가 다시 돌아옵니다. 필요한 콘텐츠를 정확하게 정의하고 있습니다. 서버 측에서 클라이언트 측 렌더링으로 렌더링한 후 수분 공급이 줄어듭니다.

유선으로 들어오는 코드가 적고, 응답이 적고, 응답 시간이 더 빠릅니다. 그것은 확실히 승리입니다. Atlas 워크플로나 헤드리스 워크플로로 이동하려는 경우 GraphQL API와 REST API 같은 것을 사용하는 것을 면밀히 검토할 것을 제안합니다.

그리고 사용자의 관점에서 그들은 신선하고 시의적절한 콘텐츠를 보고 있습니다. 콘텐츠 미리 보기에 최적화된 게시 흐름입니다. 스테이징 및 미리보기 측면에서 빠른 콘텐츠 가져오기에 최적화된 다음 이를 프로덕션으로 승격합니다. Leo Burnett의 관리자는 콘텐츠를 업데이트하는 것이 얼마나 쉬운지 매우 만족하며 사용자를 만족시킵니다.

결과는? 이것은 모든 것을 롤업하는 것입니다. 영감을 받은 개발자, 생산적인 관리자 및 행복한 사용자입니다. 이것이 모든 웹 개발 팀이 진정으로 추구하는 세 가지 요소이자 희망입니다.

개발자는 영감을 받으면 최적화된 도구 세트를 사용합니다. 그냥 기분이 좋아. 그들은 행복합니다. 그들은 더 나은 코드를 작성합니다.

관리자는 자신이 아름다운 생태계에 콘텐츠를 생산하고 있음을 알고 있습니다. 빠르다. 빠르게 배송됩니다. 그리고 사용자는 업데이트된 콘텐츠를 보고 현대적이고 아름답고 잘 작동하며 최적화된 프런트 엔드를 경험하고 있습니다.

나는 그것을 마무리하려고 생각합니다 – 당신이 기억하기를 바라는 몇 가지 마지막 생각입니다. 브리핑 자체에는 항상 언어가 누락되어 있다고 생각합니다. 너무 자주 우리는 아름다운 웹사이트를 만들어 달라는 이야기만 한다고 생각합니다. 멋진 웹사이트를 구축하세요. 나는 그것이 보이고 느껴지기를 원합니다. 그리고 우리는 이러한 모든 검토를 고객과 함께 실행했습니다.

그리고 모두가 흥분하고 V1이 출시됩니다. 그런 다음 그 웹사이트를 장악해야 하는 사람들은 마치 당신이 나에게 엉망진창을 건넸습니다. 어떻게 처리해야 합니까? 이것은 당신이 생각한 임시 흐름입니까?

아름다운 웹사이트를 구축하고 부담을 넘기고 싶지 않습니다. 우리는 Haus에서 그렇게 하지 않는 것에 많은 자부심을 가지고 있습니다. Atlas와 플랫폼으로서의 Atlas의 놀라운 점은 그것을 해결한다는 것입니다.

이는 인프라 관점과 코드 배포 관점에서 실제로 의미가 있는 에코시스템과 웹 게시 시스템을 제공하고 있다는 확신을 줍니다. 그것은 IT 팀과 엔지니어링 팀 또는 마케팅 팀에 당신이 무엇을 하고 있는지 알고 있고 당신이 그들을 위해 구축한 이 새로운 웹 사이트를 그들이 잘 관리하고 있다는 문서화된 증거를 제공합니다.

기억하세요, 우리는 단지 웹사이트를 구축하는 것이 아닙니다. 우리는 콘텐츠 게시 시스템을 구축하고 있으며 첫날부터 이해하고 인정하는 것이 중요합니다. 그리고 다시, 이것은 Atlas가 작용하는 곳입니다.

따라서 이 작은 정보가 헤드리스 스택을 전략적으로 구상하는 데 도움이 되기를 바랍니다. 그것이 당신이 가고자 하는 방향이라면 Atlas를 살펴보는 것이 좋습니다. 세션이 즐거우셨기를 바라며, 대단히 감사합니다.