머리를 잃지 마십시오: 머리 없는 평가

이 기사는 시각적 편집기, 중첩 구성 요소 및 웹 사이트 및 앱용 사용자 정의 가능한 콘텐츠 블록이 있는 친숙한 헤드리스 CMS인 Storyblok의 친애하는 친구의 지원을 받았습니다. 감사합니다!

많은 옵션에는 많은 결정이 따르며, 서로 다른 시스템이 제공하는 다양하고 많은 이점에 빠져들기 쉽습니다. 그렇다면 이러한 옵션을 평가하는 방법은 무엇입니까? 2주 전 Aaron Hans는 Smashing Magazine에서 헤드리스 사용 사례와 이것이 어떤 이점이 있는지 설명했습니다. 오늘은 CMS 환경에 대한 입문서와 결정을 내리는 데 도움이 되는 몇 가지 질문을 드리겠습니다.

목이 없는? 뭐라고 요?

헤드리스 콘텐츠 관리는 프런트 엔드에서 콘텐츠 관리 시스템(CMS)을 분리하는 방식입니다. 기존(또는 "모놀리식") 시스템과 달리 CMS는 웹 프런트 엔드에 전원을 공급하는 직접적인 책임이 없습니다. 대신 콘텐츠는 API를 통해 원격 시스템에서 프런트 엔드로 제공되고 프런트 엔드는 이 데이터를 사용하여 페이지를 렌더링합니다. 이것은 런타임 (사용자가 웹사이트에 방문할 때) 또는 빌드 시 (컨텐츠가 미리 렌더링되고 생성됨)에 발생할 수 있지만 여기서 중요한 개념은 컨텐츠와 프레젠테이션 레이어를 분리하는 것입니다.

Jamstack을 사용하여 사이트를 만들 계획이라면 기본적으로 이 방향으로 향하게 되지만 PHP, . 넷, 또는 루비.

그러나 이것이 왜 물건입니까?

Headless는 원래 Jamstack의 콘텐츠를 관리하는 방법으로 나왔지만(Jamstack이 멋진 이름을 갖기 전) 이러한 접근 방식은 여러 가지 이유로 팬을 확보했습니다. 헤드리스 콘텐츠 관리를 통해 다양한 플랫폼에 콘텐츠를 배포할 수 있으므로 예를 들어 기본 모바일 앱에서 웹사이트의 콘텐츠를 사용할 수 있습니다.

헤드리스를 사용하면 다른 시스템의 단점 을 보완할 수도 있습니다. 예를 들어, Shopify. 이 기능은 훌륭하지만 온라인 상점의 콘텐츠를 관리하는 데 있어 가장 유연한 시스템은 아닙니다. 헤드리스 CMS를 사용하여 Shopify 사이트에 대한 추가 콘텐츠를 원격으로 관리하고 기본적으로 제공하는 것보다 더 많은 기능과 유연성을 제공할 수 있습니다.

저는 최근에 정확히 이 작업을 수행하는 프로젝트에서 작업했습니다. 즉, 헤드리스 CMS에서 추가로 풍부한 콘텐츠로 Shopify가 제공하는 콘텐츠를 확장하는 것입니다(이 특정 프로젝트에 Contentful을 사용하게 되었지만 헤드리스 CMS가 이 작업을 수행할 수 있음). 헤드리스 콘텐츠 관리 솔루션을 사용하여 요구 사항에 맞출 수 있는 사용자 지정 데이터 구조를 만들 수 있었습니다. 예를 들어, 클라이언트는 제품을 만드는 데 사용한 재료를 강조하고 싶었지만 Shopify는 이를 관리하는 좋은 방법을 제공하지 않습니다. Shopify에서 새로운 콘텐츠 유형을 생성하고 우리가 만든 다른 유형의 콘텐츠로 가득 찬 사용자 정의 제품 페이지에 추가할 수 있도록 허용했습니다.

Shopify 콘텐츠는 Contentful로 가져와 동기화되었으며, 이는 Shopify API가 재고 수준 확인 및 장바구니 생성에만 실제로 관여하는 사이트의 주요 데이터 동인이 되었습니다. 이러한 종류의 풍부한 데이터를 SaaS 기반 전자 상거래 사이트에 추가할 수 있다는 것은 매우 강력했습니다.

우리는 우연히 Nuxt를 사용하여 사이트를 구축하여 이 결과를 얻었지만 Shopify 템플릿 내에서 직접 CMS의 데이터를 통합할 수도 있었습니다. 여기서 더 나은 접근 방식으로 Jamstack 이 선택되었지만 헤드리스는 거의 모든 곳에서 사용할 수 있을 만큼 충분히 유연합니다. JavaScript 또는 PHP 또는 .Net과 같은 보다 전통적인 백엔드 언어를 통해 일종의 스크립팅에 액세스할 수 있는 한 헤드리스를 워크플로에 통합할 수 있습니다.

프레젠테이션 레이어에서 콘텐츠를 분리하는 것은 정말 강력할 수 있습니다. 콘텐츠를 다양한 플랫폼 및 프레젠테이션 레이어에 연결할 수 있도록 하면 접점 전체에서 콘텐츠의 일관성을 유지하는 데 도움이 되며 콘텐츠가 여러 팀에서 관리하는 여러 시스템에서 파편화되지 않도록 할 수 있습니다.

웹사이트, 모바일 앱 및 프로그래밍 광고에서 이야기하고 싶은 제품이 있다고 상상해 보십시오. 헤드리스를 사용하면 하나의 중앙 컨텐츠 리포지토리 를 보유하고 동일한 컨텐츠(또는 그 일부)를 이러한 모든 플랫폼 등에 배포할 수 있습니다. 보다 전통적인 콘텐츠 관리를 사용하면 다양한 플랫폼의 콘텐츠를 별도로 관리해야 합니다.

이것은 좋은 소리입니다! 그렇다면 헤드리스가 나에게 적합합니까?

접근 방식을 선택할 때 고려해야 할 사항이 많이 있습니다. 헤드리스로 이동하면 이점이 있지만 비용도 있습니다. 다음은 헤드리스를 접근 방식으로 고려할 때 자문해야 할 몇 가지 질문입니다.

당신은 분할을 만드는 지식 요구 사항에 편안합니까?

많은 사람들이 헤드리스로 전환하면 백엔드 개발자의 필요성을 "제거"할 수 있다고 생각하지만, 사실 데이터를 효과적으로 구조화 하고 잘 작동하고 확장 가능한 콘텐츠 모델을 구축하려는 사고 방식은 여전히 ​​그 사고 방식과 매우 다릅니다. 대부분의 시간 동안 훌륭한 프론트엔드 개발자가 필요했습니다. 여전히 지식 격차가 있으며, 이는 여전히 채워져야 합니다.

상당한 규모의 프로젝트를 처리하는 경우 여전히 일부 개발자는 "백 엔드" 영역에 집중하고 일부는 "프론트 엔드"에 집중하기를 원할 것입니다. 머리가 없는 땅에서는 부서가 더 미세하고 유연하지만 머리가 없는 곳으로 가는 것만으로 개발 인력을 절반으로 줄일 수 있다는 잘못된 가정하에 노력하지 마십시오.

총 소유 비용을 알고 계십니까?

헤드리스가 모놀리스보다 저렴한 경우가 많지만 이러한 시스템 대부분의 SaaS 특성은 빠르게 변화하는 대규모 데이터 세트 또는 대규모 팀의 경우 비용이 추가되지 않을 수 있음을 의미할 수 있습니다. 비용이 어떻게 확장되고 그 확장이 무엇을 기반으로 하는지 항상 확인하십시오. 일부 공급업체는 데이터 볼륨 , 일부 는 API 요청 수 , 일부는 콘텐츠를 편집 하는 공동 작업자 수에 따라 확장됩니다. 이러한 조합은 규모에 따라 비용이 증가하는 방식에 극적인 영향을 미칠 수 있습니다.

또한 총 소유 비용에 대한 아이디어를 공식화하기 위해 여러 플랫폼을 살펴봐야 할 수도 있습니다. "즉시" 검색이 되지 않는 경우 해당 기능을 추가하는 데 드는 비용을 고려해야 합니다. 일반적으로 이러한 비용이 어떻게 확장될지 예측할 수 있으며 소규모로 시작할 수도 있지만 장기적으로 이러한 비용이 얼마나 들 수 있는지 알아둘 가치가 있습니다.

또한 헤드리스를 선택하는 경우 빌드 시간 을 면밀히 주시하십시오. 특히 개발 및 콘텐츠 채우기 단계에서 이러한 시간이 빠르게 증가할 수 있습니다. 사이트를 정적으로 생성하도록 선택한 경우 CMS에서 각 게시 작업 후에 빌드가 필요합니다. 대규모 사이트의 경우 이러한 빌드에 시간이 걸릴 수 있으므로 확인해야 한다는 점을 염두에 두는 것이 좋습니다. 많은 인기 있는 정적 호스팅 서비스(예: Netlify 및 Vercel)는 빌드 자산 캐싱을 지원하며, 증분 빌드를 가능하게 하는 최신 프레임워크와 결합하여 이렇게 증가하는 비용을 완화하는 데 도움이 될 수 있지만 여전히 이를 주시하고 다음을 수행해야 합니다. 잡히지 않도록 조사합니다.

고객에게 충분히 설명했습니까?

Jamstack 및 헤드리스로 작업하는 개발자 경험을 좋아할 수도 있지만 이러한 평가를 할 때 클라이언트는 함께 만든 솔루션을 사용하고 함께 살아야 하는 사람이라는 점을 명심해야 합니다. 그들의 삶을 가능한 한 쉽게 만들려고 노력하십시오.

이전 역할에서 저는 업계 최고의 성능 을 최우선 순위로 원한다고 말했지만 궁극적으로 더 전통적인 솔루션을 제공하는 다른 에이전시와 함께 갔던 자동차 제조업체의 프레젠테이션에 참여했습니다. 이것은 여러 가지 이유로 발생할 수 있습니다. (아마도 우리는 우리 접근 방식의 이점을 충분히 판매하지 못했을 것입니다. 그러나 헤드리스 방식은 콘텐츠 편집자에게도 꽤 무서운 것처럼 보일 수 있습니다. 특히 재능이 있는 일부 전통적인 "엔터프라이즈" 시스템에 맞서 싸울 때 모든 것이 "정상적으로 작동하는" 것처럼 보이게 합니다.)

헤드리스로 전환하면 한 곳에서 이러한 모든 작업을 수행할 수 있는 하나의 대규모 시스템을 사용하는 대신 각각의 특정 작업에 매우 적합하도록 설계된 개별 도구를 함께 사용하게 됩니다. 클라이언트가 가능한 한 쉽게 처리할 수 있도록 하지 않는 한 처리하기가 매우 위협적일 수 있습니다.

추가 개발 시간을 고려하고 있습니까?

헤드리스의 모든 잠재력과 유연성은 공짜가 아닙니다. 모든 것이 맞춤화되는 것의 단점 중 하나는 이것이 모든 것이 처음부터 개발 되어야 한다는 것을 의미한다는 것입니다. 이 공간에 있는 많은 옵션에는 실제 "기본" 문서 스키마가 없습니다. 실제로 그러한 기본값이 없도록 매우 의도적으로 설정되어 있습니다. 이것은 사용자의 요구에 정확히 일치하는 밀접하게 조정된 문서 모델을 얻을 수 있다는 것을 의미하기 때문에 한편으로는 훌륭합니다.

그러나 다른 한편으로는 누군가가 이러한 문서 모델을 정의해야 하고, 그런 다음 누군가가 당신이 사용하는 시스템에 대해 생성해야 한다는 것을 의미합니다. 그러면 프론트엔드와 백엔드가 분리되기 때문에 누군가는 일반적 으로 초안 콘텐츠를 미리 볼 수 있는 엔진을 만들어야 합니다. 많은 최신 프레임워크에는 초안 콘텐츠를 미리 볼 수 있는 시스템이 포함되어 있지만 일반적으로 작동하려면 추가 구성이 필요하며 일부는 일정 수준의 사용자 정의 코드가 필요합니다. 물론 프론트엔드는 콘텐츠에 연결되어 있지 않으므로 데이터를 프론트엔드 구성 요소에 매핑하는 작업도 수행해야 합니다. 일반적으로 밀접하게 연결된 CMS를 사용하는 경우에도 이 중 최소한 일부는 수행해야 하지만 이러한 모든 작업에 시간을 할당해야 한다는 사실은 비용이 많이 들 수 있습니다.

귀하/귀하의 고객은 귀하의 인프라에 없는 데이터에 대해 편안함을 느끼십니까?

헤드리스 CMS 시스템 및 기타 SaaS 공급업체와 협력하는 많은 사람들이 이를 긍정적으로 생각하지만, 민감한 제품 또는 비공개 프로덕션 데이터가 관련된 경우와 같이 데이터가 자체 인프라 외부에 있는 것이 바람직하지 않을 수 있는 상황이 있습니다. 이러한 회사의 보안은 일반적으로 꽤 좋지만 항상 위험이 따릅니다.

콘텐츠를 익명의 AWS 서버 어딘가에 보관 하는 것의 상대적 이점을 저울질해 보십시오 . 우리는 강력한 AWS라도 중단이 발생할 수 있으며 비즈니스 크리티컬 시스템의 경우 매우 비용이 많이 들 수 있음을 보았습니다. 여기에서 AWS 기반 SaaS와 자체 인프라 사용 간의 차이점은 자체 인프라에 중단 또는 보안 위반이 있는 경우 자체 제품 또는 코드에 영향을 미칠 가능성이 높지만 SaaS/AWS 환경에서는 중단이 귀하의 비즈니스와 관련이 없는 요인으로 인해 발생할 가능성이 더 큽니다. 이러한 경우는 드물지만 실제로 발생하므로 이러한 결정을 내릴 때 이를 고려하는 것이 중요합니다.

큰 확인. 내 옵션은 무엇입니까?

2021년에 사용 가능한 헤드리스 및 헤드리스 지원 콘텐츠 관리 솔루션의 수는 놀랍고 지속적으로 증가하고 있습니다. 여기에서 모든 옵션을 다루기보다는 잘 알려진 몇 가지 옵션에 대해 아주 간략하게 소개하고자 합니다. 보다 포괄적인 목록을 찾고 있다면 헤드리스 CMS 또는 CMS 비교를 확인하는 것이 좋습니다.

만족스러운

Contentful은 2016년에 설립되어 여러 차례 성공적인 시드 투자 라운드를 즐겼으며 "디지털 경험을 제공하는 API 우선 콘텐츠 플랫폼"이라고 설명하는 헤드리스 CMS 옵션 중 가장 확립된 것 중 하나입니다.

Contentful은 번역 및 트랜스 생성된 콘텐츠를 더 잘 지원하기 위해 최근 몇 년 동안 큰 발전을 이루었으며 여러 콘텐츠 "환경"을 잘 지원하므로 프로덕션 데이터에서 변경하고 나중에 마이그레이션할 수 있습니다.

Contentful에는 다른 SaaS 앱과의 통합 제품군이 있으므로 전자 상거래의 경우 Shopify 또는 CommerceLayer, 자산 호스팅 및 처리의 경우 Cloudinary와 쉽게 통합할 수 있습니다.

최고:

헤드리스 공간에서 가장 잘 정립된 솔루션을 찾는 사람들.

스토리블록

Storyblok은 실제로 스스로를 CMS로 설명하는 헤드리스 퍼스트 옵션 중 유일하며, 놀라운 WYSIWYG 인터페이스를 사용하여 현장에서 겉보기에 콘텐츠를 만들고 편집할 수 있는 정말 멋진 시각적 콘텐츠 편집기를 제공합니다. 이것은 웹 사이트에서 CMS를 분리하는 전통적인 약점 중 하나이므로 Storyblok에서 이러한 종류의 편집 환경을 만드는 것을 보는 것은 큰 발전이며 팀은 이와 관련하여 시장을 주도하게 된 것을 자랑스럽게 생각합니다.

Storyblok은 또한 API를 사용하여 콘텐츠 스키마를 생성할 수 있는 기능을 가지고 있어 이러한 것들이 코드와 함께 유지될 수 있어 유지 관리가 용이합니다. 역할 기반 권한 및 번역/변환 기능을 통해 분산된 팀이 다국어 사이트에서 즐겁게 작업할 수 있습니다. 전반적으로 Storyblok은 매우 세련되고 세심하게 설계된 제품처럼 느껴지며 특히 콘텐츠 팀이 열광할 가능성이 높은 제품입니다.

최고:

헤드리스 CMS에서 동급 최강의 WYSIWYG 콘텐츠 편집 솔루션을 찾는 사람들.

제정신

Sanity는 이 분야에서 가장 최근에 나온 아이들 중 하나지만 빠르게 주목받고 있습니다. 그들은 스스로를 "팀이 큰 꿈을 꾸고 빠르게 전달할 수 있도록 도와주는 최고의 콘텐츠 플랫폼"이라고 설명합니다.

Sanity는 모든 구성 및 콘텐츠 모델이 개발자에게 편리한 보관 장소인 코드로 수행된다는 점에서 여기의 다른 옵션과 약간 다르게 작동합니다. 문서 모델 및 사용자 정의 필드 유형으로 거의 무한한 창의성을 허용함으로써 Sanity는 개발자가 웹 콘텐츠뿐만 아니라 모든 방식에 대해 깊고 풍부한 콘텐츠 구조를 만들 수 있도록 합니다.

Sanity의 편집 제품군은 깨끗하고 단순하며 사용자 지정이 가능한 오픈 소스이며 React를 기반으로 합니다. 편집 스튜디오를 원하는 호스트에 배포하거나 Sanity 하위 도메인을 사용하여 해당 인프라에서 호스트하도록 선택할 수 있습니다.

최고:

사용자 지정 데이터 구조에서 입력 구성 요소에 이르기까지 구현의 거의 모든 측면을 절대적으로 제어해야 하는 사용자.

프리즘

Prismic은 실제로 2013년으로 거슬러 올라가는 머리 없는 공간의 방에 있는 오래된 캐릭터이지만 공간에서 혁신을 멈추지는 않았습니다. 바로 작년에 그들은 콘텐츠 블록(또는 "슬라이스")과 프런트 엔드 구성 요소 사이에 1:1 관계를 만들어 구성 요소를 만드는 프런트 엔드 개발자와 콘텐츠 작성자 사이의 격차를 해소하는 것을 목표로 하는 SliceMachine을 도입했습니다. 페이지와 콘텐츠 섹션은 편집자를 위한 것입니다.

Prismic의 편집 제품군은 훌륭하고 필드 선택에 존재했던 일부 구멍을 패치한 것 같아서 균형 잡힌 경험을 제공합니다.

최고:

콘텐츠 편집자의 마찰을 최소화하려는 사람들.

조금 더 전통적인 것을 원하면 어떻게 합니까?

워드프레스

Wordpress는 2021년에도 여전히 거대합니다. 다른 플랫폼에 대한 모든 과대 광고에도 불구하고 WordPress는 여전히 인터넷의 약 40%를 차지하며 아무데도 가지 않을 것입니다. 개발자는 헤드리스 기능을 개선하고 API 지원에 더 집중하여 이를 확인하도록 돕고 있습니다. 새로운 편집 도구는 또한 WordPress 내에서 작성하는 경험을 더 즐겁게 만들고 WordPress를 사용하여 작업할 때 내재된 일부 절충안은 최근 몇 년 동안 크게 개선되었습니다.

Nestify와 같은 WordPress-as-a-service 회사와 협력하면 개발자로서 보안에 대한 많은 걱정과 골칫거리를 해결할 수 있지만 인터넷에서 가장 큰 플랫폼인 WordPress는 여전히 매우 매력적인 악의적 인 의도를 가진 사람들을 대상으로합니다.

최고:

편안하고 친숙한 콘텐츠 플랫폼을 고수하면서 기술을 최신 상태로 유지하려는 사람들.

사이트 코어

엔터프라이즈 콘텐츠 관리의 거인 중 하나인 Sitecore는 아마도 이 목록에서 가장 보기 힘든 이름 중 하나일 것입니다. 그러나 그들은 헤드리스 지원에서 큰 진전을 이루었고 Jamstack 프로젝트가 Sitecore 데이터와 인터페이스할 수 있도록 Sitecore JSS를 출시했습니다.

헤드리스 방식으로 Sitecore 또는 기타 엔터프라이즈 CMS 시스템을 사용하는 데 있어 큰 어려움은 항상 개인화를 설정하고 실행하는 것이었지만 이 문제는 실제로 이러한 종류의 기능을 활성화하기 위해 Sitecore와 함께 작업하기 시작한 Uniform의 사람들에 의해 해결되었습니다. .

Sitecore는 거대한 규모이며 많은 프로젝트에 적합하지 않을 것입니다. 비용만으로 엔터프라이즈 수준 고객을 제외한 모든 고객의 범위를 벗어납니다. 그러나 AEM과 함께 여기에 나열할 가치가 있습니다. 헤드리스 콘텐츠 관리가 소규모 웹사이트에만 해당된다고 생각하는 많은 사람들이 있습니다.

최고:

새로운 기술에 "올인"할 필요가 없는 클라이언트와 함께 엔터프라이즈 프로젝트를 찾고 있는 사람들.

어도비 익스피리언스 매니저

Adobe Experience Manager(또는 AEM)는 기업의 끝 부분에서 또 다른 주요 업체 중 하나입니다. 대부분의 경쟁 제품과 마찬가지로 거대하고 비용이 많이 들지만 Adobe는 웹 사이트 프레젠테이션에서 컨텐츠를 분리하려는 사람들에게 더 친숙한 제품을 제공하기 위해 엄청난 노력을 기울인 또 다른 공급업체입니다.

이제 AEM은 플랫폼에서 데이터를 요청하는 몇 가지 다른 방법을 지원하고 Adobe는 이제 AEM을 "하이브리드 CMS"로 판매합니다. 이는 다양한 플랫폼에서 작업해야 하고 이러한 플랫폼 간의 콘텐츠를 세밀하게 제어해야 하는 마케팅 팀에 큰 이점이 될 수 있지만 Adobe의 "모든 것을 지배하는 하나의 플랫폼"을 원하는 사람들은 시작하려면 막대한 자금이 필요합니다.

최고:

주머니가 깊숙이 들어가는 기업의 극치를 바라보는 이들! AEM은 많은 일을 하지만(여기서 언급할 수 있는 것보다 더 많이), 비용이 많이 듭니다.

이제 내 옵션에 대한 아이디어가 있지만 어떻게 그 중에서 선택하기를 희망할 수 있습니까?

이제 머리 없는 공간에는 옵션이 너무 많아 옵션 마비에 쉽게 빠질 수 있습니다. 그러나 초기 의견을 형성하거나 최소한 필드를 좁히는 데 사용할 수 있는 몇 가지 질문이 있습니다.

속도를 높이는 데 얼마나 걸립니까?

시스템마다 학습 곡선이 다르고 개발자를 지원하는 방법도 다릅니다. 여기에 나열된 모든 시스템에는 주변에 구축된 개발자 커뮤니티가 있지만 모든 커뮤니티가 평등하게 생성되는 것은 아닙니다. 공급업체에서 자세한 문서를 제공합니까? 시작 프로젝트? 이 모든 것이 스핀업 시간에 큰 영향을 미칠 수 있습니다.

어떤 종류의 지원 모델이 필요합니까?

지원 모델은 일반적으로 클라이언트에게 가장 중요하며 보다 직접적인 지원 라인에 액세스하려면 "엔터프라이즈" 패키지에 비용을 지불해야 하므로 사용량을 보고 예상하는 것보다 더 많은 투자를 할 수 있습니다.

공급업체는 얼마나 잘 설립되었습니까?

공급업체가 얼마나 잘 확립되어 있습니까? 재정은 어떻게 마련되나요? 다시 말하지만, 이는 일반적으로 개발자가 아닌 클라이언트에 대한 고려 사항이지만, 귀하가 추천하는 공급업체가 안정적이고 X년 동안 주변에 있었고 , 그들이 곧 아무데도 가지 않을 것이라고 확신합니다. 클라이언트가 처리하기를 원하는 마지막 일은 고객이 계약을 진행하는 동안 기존 공급업체가 제품을 중단하고 있기 때문에 강제로 플랫폼을 다시 구성하는 것입니다!

편집 경험은 어떤가요?

편집 경험은 모든 프로젝트의 클라이언트 측에서 많은 사람들에게 매우 중요할 수 있습니다. 이들은 매일 당신이 선택한 CMS와 함께 일할 사람들입니다. CMS가 사용하기에 악몽이라면, 그들은 그렇게 말할 것입니다. 저를 믿으세요. 저는 고객이 기존 시스템에 대해 가지고 있는 많은 좌절감을 나열하는 데 상당한 시간을 할애한 많은 프레젠테이션과 후속 회의에 참석했습니다!

"당신이 보고 있는 시스템이 상황에 맞는 편집이나 실시간 초안 미리보기를 제공할 수 있습니까?"

"이것들을 설정하는 데 얼마나 많은 노력이 있습니까?"

"편집기 자체가 얼마나 빨리 또는 느리게 실행됩니까?"

"사용자가 옵션과 익숙하지 않은 버튼으로 가득 차 있습니까? 아니면 잘 정리되어 있습니까?"

이러한 모든 질문은 시스템의 전반적인 사용 용이성에 영향을 미칩니다. Storyblok과 같은 일부 솔루션은 콘텐츠 편집 을 풍부하고 매끄러운 경험 으로 만들기 위해 많은 노력을 기울였지만 일반적으로 헤드리스 환경 전체에서 강점으로 간주되지 않으므로 소규모 데모를 넣을 가치가 있습니다. 콘텐츠 편집자 앞에서 귀하가 주목하고 있는 솔루션에 대해 어떻게 느끼는지 확인하십시오.

플랫폼에서 데이터를 가져오는 것이 얼마나 쉬운가요?

내가 참여한 피치 회의의 수를 세지 못했고 클라이언트의 콘텐츠가 독점 콘텐츠 관리 시스템에 완전히 묶여 있기 때문에 콘텐츠에 대해 처음부터 새로 시작하거나 맞춤 스크레이퍼를 작성해야 할 수도 있다는 말을 들었습니다. 데이터를 쉽게 내보낼 수 없습니다.

선택한 CMS가 아무리 멋져 보이더라도 특정 시점에서 시스템에서 모든 콘텐츠를 쉽게 제거할 수 있는 방법이 있다는 것을 절대적으로 확인하십시오. 슬프게도 영원한 시스템은 없으며 클라이언트는 결국 사이트와 인프라를 변경하기를 원할 것입니다. 그 시점에서 그들의 삶을 더 쉽게 만들기 위해 당신이 할 수 있는 모든 것은 큰 긍정적인 일이 될 것입니다.

헤드리스 CMS 솔루션은 핵심에서 API를 사용할 수 있기 때문에 일반적으로 더 쉽습니다.

합산

콘텐츠 관리에 대한 접근 방식과 플랫폼을 선택하는 것은 모든 디지털 프로젝트에서 중요한 선택입니다. 헤드리스 콘텐츠 관리는 강력하고 유연하지만 약간의 비용이 따르며 모든 상황에 이상적이지는 않습니다.

공급업체에서 처음 에 보는 가격이 솔루션의 최종 총 비용인 경우는 거의 없다는 점을 명심하고 기존의 "백업"을 제거하여 개발 비용을 줄일 수 있다고 생각하는 함정에 빠지지 않도록 하십시오. -end” 개발자.

모든 사람이 보다 전통적인 설정과 달리 헤드리스 CMS로 작업하는 현실에 익숙해 지도록 하고, 가장 많이 설정한 시스템으로 작업할 사람들이기 때문에 여정에 콘텐츠 편집자를 동반해야 합니다. 자주.

바라건대, 이 가이드가 적어도 과장된 내용에 대한 정보를 제공하는 데 도움이 되었고 귀하와 귀하의 고객이 편안하게 결정할 수 있는 결정을 내리는 데 도움이 될 수 있습니다. 이제 헤드리스를 중심으로 원하는 거의 모든 것을 구축할 수 있습니다. 하지만 솔루션이 익숙하거나 과대 광고되어 솔루션에 도달하고 있는지, 아니면 실제로 상황에 가장 적합한 솔루션인지 항상 자문해 보십시오.