Smashing Magazine이 콘텐츠를 관리하는 방법: WordPress에서 JAMstack으로 마이그레이션

이 기사는 최신 웹 프로젝트 자동화를 위한 올인원 플랫폼인 Netlify의 친애하는 친구의 지원을 받았습니다. 감사합니다!

개발자가 WordPress에 대해 이야기할 때마다 시장 점유율 비율이 변경됩니다. “ 전체 사이트의 20%가 워드프레스에 있습니다! " " 전체 사이트의 40%가 워드프레스에 있습니다! " 백분율이 무엇이든 메시지는 동일합니다. 채택 측면에서 WordPress는 거대합니다.

그렇다면 왜 그런 종류의 채택으로 WordPress를 사용하는 사이트가 JAMstack으로의 이전을 고려할까요? 두 부분으로 구성된 이 기사 시리즈에서는 지금 읽고 있는 바로 그 사이트의 사례 연구를 사용하여 실제 WordPress 마이그레이션이 어떻게 보이는지 다룰 것입니다.

우리는 이득과 손실, 우리가 더 일찍 알았으면 했던 것들, 그리고 우리가 놀랐던 것에 대해 이야기할 것입니다. 그런 다음 WordPress에서 완전히 벗어나는 것이 아니라 가능한 한 마이그레이션 경로에 대한 기술 시연으로 후속 조치를 취하여 두 세계의 장점을 모두 누릴 수 있도록 분리된 WordPress를 제공하는 방법: 모든 것을 제공하는 WordPress의 JAMstack 구현 더 나은 성능과 보안과 함께 대시보드와 기능의 힘.

파헤쳐보자!

왜요?

2015년, Netlify의 공동 설립자 Mathias Biilmann과 Smashing의 설립자 Vitaly Friedman은 상점에 대해 이야기했습니다. JAMstack 아키텍처가 라운드를 시작하면서 Smashing은 스택에 대한 아이디어에 더 많은 관심을 갖게 되었습니다. Vitaly와 Markus(전 Smashing 전무이사)는 Smashing이 기존 WordPress/LAMPstack 사이트에서 JAMstack 아키텍처로 마이그레이션하면 어떻게 될지 Matt에게 질문했습니다.

실험으로 Matt는 Smashing에서 모든 HTML을 스크랩하고 Netlify에서 호스팅하여 CDN에서 정적으로 콘텐츠를 전달했습니다. 결과는 놀라웠습니다. 정적 버전은 평균 6배 이상 빠릅니다!

이러한 유형의 아키텍처는 페이지를 방문할 때 페이지가 주문형으로 컴파일되지 않기 때문에 부분적으로 매우 잘 작동합니다. Content Delivery Network 에서 직접 사전 제작된 콘텐츠를 제공 하기 때문에 사이트는 이미 "거기"에 있고 사용자를 위해 준비되어 있습니다.

CDN을 통해 서비스를 제공하고 있으므로 잠재적인 방문자에게 더 가까운 전 세계에 콘텐츠를 배포할 수도 있습니다. 모든 독자를 위해 빠른 속도를 원하는 온라인 출판물의 경우 중요한 출처의 중심점이 없습니다.

그래서 무대가 마련됐다. Smashing Magazine은 JAMstack, 특히 플랫폼인 Netlify로 마이그레이션했습니다. 운영 10년 동안 Smashing은 작은 온라인 출판물에서 책, 컨퍼런스 티켓, 워크샵 등을 판매하는 거대한 WordPress 블로그로 성장했습니다.

이 사이트의 몇 가지 조각이 있습니다.

• 워드프레스 블로그
• Rails 채용 게시판
• 쇼피파이 스토어
• 회의장을 위한 또 다른 CMS

Netlify가 처음 마이그레이션을 시작했을 때 사이트는 20,000개의 댓글과 수천 개의 기사로 인해 몇 가지 성능 문제를 겪고 있었습니다. Smashing은 또한 새로운 구독 계획의 일부로 인증과 보다 현대적인 모습을 위한 재설계에 관심이 있었습니다.

신뢰할 수 있음

Smashing은 정기적으로 다른 플랫폼이 꿈꾸는 것, 즉 거대한 커뮤니티를 통해 널리 공유되는 기사를 달성합니다. 그러나 게시물의 트래픽이 티핑 포인트에 도달했을 때 Smashing은 정기적으로 중단 문제가 발생했습니다. 이를 완화하기 위해 스택에 WordPress 플러그인을 많이 사용했지만 여전히 좋은 가동 시간 메트릭을 유지하는 데 어려움을 겪었습니다.

Netlify로 이전하면서 Smashing 팀은 데이터베이스 연결 오류를 방지하고 기사에서 엄청난 양의 트래픽을 확인하더라도 다운타임에 대해 걱정할 필요가 없었 습니다. 왜요? 서버 없이 제공할 때 미리 빌드된 콘텐츠를 생성하고 제공할 필요가 없기 때문에 이미 존재하고 볼 준비가 되어 있습니다. 전체 정적 페이지를 제외하고는 그 자리에서 아무 것도 요청되지 않습니다.

CDN을 통한 서비스도 Smashing이 보안 면에서 조금 더 쉽게 잠을 잘 수 있게 해주었습니다. wp-login.php 는 오랫동안 보안 허점과 공격 경로의 근원이었습니다. 사전 구축된 콘텐츠는 동일한 방식으로 액세스할 수 없으며 보안 허점은 어디에나 존재하지 않습니다.

캐시 무효화

Smashing은 다양한 결과와 많은 문제로 모든 WordPress 캐싱 플러그인을 순환했습니다. Smashing의 Vitaly Friedman은 다음과 같이 언급합니다.

“우리가 가진 주요 문제는 격주로 계속 발생하는 '데이터베이스 연결 설정 오류'와 관련이 있었고 문자 그대로 모든 단일 WordPress 캐싱 플러그인을 시도했습니다. 성능은 (전체적으로) 꽤 괜찮았지만 우리는 그것을 더 개선하고자 했습니다. 또한 멤버십을 출시하고 컨퍼런스, 채용 공고, 기사, 책, 전자책 등 다양한 서비스를 하나의 플랫폼으로 연결하고 싶었지만 WordPress를 사용하면 달성하기가 매우 어려웠습니다.”

Netlify로 이전하면서 Smashing 팀은 즉각적인 캐시 무효화를 확인하는 동시에 추가 오버헤드 없이 캐시되고 성능이 뛰어난 콘텐츠를 제공할 수 있었습니다.

사이트를 배포할 때 HTML 파일은 Netlify의 CDN에서 호스팅됩니다. 변경된 모든 HTML 파일을 즉시 무효화 할 수 있는 동시에 높은 캐시 적중률과 빠른 첫 번째 바이트 시간에 최적화되어 있습니다. Netlify는 또한 CSS 파일, 이미지, 글꼴 또는 JS 파일과 같은 자산에 대한 모든 링크를 지문으로 인식하고 영원히 캐시하는 캐싱 헤더로 Smashing을 제공합니다. 지문은 고유함을 보장하며 새 버전을 업데이트하면 새 버전이 대신 제공됩니다.

워크플로

기존 설정을 살펴보면 마이그레이션의 큰 이유 중 하나는 단순히 기존 속성을 통합하는 것이었습니다. 이러한 모든 다른 기술 스택과 설정 사이의 컨텍스트 전환은 엔지니어에게 어려운 유지 관리 문제가 되었습니다.

이전에 인프라가 너무 많은 다른 시스템으로 분할되었을 때 이 마이그레이션 프로세스는 모든 것을 통합 하여 기본 사이트, 회의 사이트, 구독 및 전자 상거래 섹션을 서로 다른 스택으로 별도로 유지 관리하는 대신 함께 작동하도록 유지했습니다. 이는 개발 비용을 낮추고 모든 속성에서 일관되게 작업하는 개발자 경험을 유지하는 데 도움이 되었습니다.

WordPress 마이그레이션 조각은 가장 크고 가장 섬세한 것으로 판명되었습니다. Netlify는 WP 내보내기에서 데이터를 내보내려고 했지만 콘텐츠에 보존해야 하는 포함이 있거나 때때로 플러그인에 의해 변경되었다는 것을 발견했습니다. 사이트에 있는 것과 동등성을 유지하기 위해 기사, 자산, 댓글 및 홈페이지별로 분류된 일련의 스크레이퍼가 작성되었습니다.

일단 작성되고 변환되면 GitHub의 새 리포지토리에 로드되고 Netlify CMS가 대신 사용되었습니다. Netlify CMS를 독특하게 만드는 것은 가볍고 콘텐츠 편집기를 Git 워크플로에 통합한다는 것입니다. 즉, 말 그대로 데이터베이스 대신 git repo에서 마크다운 파일을 가져와서 제공합니다. 또한 Netlify CMS는 플랫폼에 구애받지 않으며 GitHub에 저장된 (거의) 모든 정적 사이트 생성기 및 사이트와 함께 작동합니다.

그 당시 Sara Soueidan은 Smashing에서 프리랜스 프론트엔드 개발자로 재설계했습니다. 그녀는 프론트 엔드 아키텍처를 구축하기 위해 구성 요소 라이브러리를 만들고 CMS로 작업할 때도 git에서 직접 작업하기 때문에 작업이 훨씬 더 간단하다고 말했습니다.

“내가 저장소로 푸시한 모든 것이 패턴 라이브러리에 직접 적용되고 있습니다. 즉, 두 가지 다른 구성 요소 세트를 유지 관리할 필요가 없습니다. 이러한 유형의 연속성은 훌륭했습니다! HTML, CSS, JavaScript를 작성하고 repo에 푸시하면 모든 것이 마술처럼 작동합니다. 워크플로가 환상적이었습니다.”

이 모든 것은 Netlify CMS가 때때로 트래픽이 많고 규모가 큰 사용 사례에 비해 너무 가벼울 수 있습니다. Smashing에는 정기적으로 게스트 저자와 전체 편집 직원이 있습니다. WordPress가 제공하는 풍부한 기능 중 일부는 이러한 종류의 고도로 협업적인 환경에 정말 유용합니다.

그렇기 때문에 다음 자습서에서는 콘텐츠 제작자를 위한 WordPress 대시보드의 이점을 계속 누릴 수 있지만 API를 통해 WordPress를 사용하고 개발이 git 중심 워크플로에 의존하도록 하는 헤드리스 모델 을 안내합니다. 개발자도 유지 관리할 수 있습니다. 계속 지켜봐 주세요!

프레임워크 선택

Matt Biilmann이 만든 초기 프로토타입에서 그는 성능에 매우 중점을 두었기 때문에 Hugo와 함께 최소한의 Preact로 모든 것을 작성했습니다. 그는 소품을 사용하고 모든 것을 매우 가볍게 유지했습니다. Smashing의 개발자인 Ilya Pukhalski가 유지 관리하도록 프로젝트를 전달하면서 그는 Preact에 React의 생태계를 활용하기 위해 누락된 일부 기능이 부족하다는 것을 발견했습니다. 결국 Redux 및 기타 라이브러리의 이점이 비용을 능가했습니다.

지금 생각해보면 Matt는 그 당시 시장 점유율이 높지 않은 Vue를 사용했을 것이라고 말합니다. 나는 분명한 질문을 했습니다. 왜 Svelte가 아닌가요? 성능을 중시하는 사람들은 해당 라이브러리에 손을 대는 경향이 있습니다. 그는 Svelte에 Vue가 아직 가지고 있지 않은 생태계가 있다고 언급했습니다.

Matt는 Hugo를 계속 사용했을지 여부를 생각할 때 Hugo를 사랑한다고 말합니다. 그러나 특히 이 프로젝트에서 그가 어려웠던 점은 배너 광고 및 기타 작업을 만드는 플러그인 시스템이 충분하지 않았다는 것입니다. 자연은 Hugo로 충분히 프로그래밍할 수 없었고 그는 그것을 달성하기 위해 스크립트를 주입해야 했습니다. 이러한 스크립트는 빌드 프로세스를 느리게 하는 경향이 있습니다. 그렇긴 하지만, 우리는 여전히 netlify.com 의 자체 사이트에 Hugo를 사용하고 있으며 매우 좋아합니다. 이 경고는 특히 Smashing 사이트의 요구 사항에 매우 특별합니다.

다시 할 수 있다면 플러그인 및 기타 확장 가능한 스크립트 생성 측면에서 풍부한 기능을 갖춘 Eleventy를 선택할 수 있습니다. 또는 그가 Vue를 사용하고 있었다면 Nuxt는 서버 측 렌더링, 라우팅 및 정적 생성을 제공하여 해당 프레임워크에 대한 좋은 선택을 허용하면서 멋진 플러그인 기능을 제공했을 것입니다.

대규모 사이트 구축

Smashing과 같은 대규모 사이트에서 작업하는 동안 한 가지 문제가 발생했으며 이미 그것이 무엇인지 알 수 있을 것입니다. 방금 다루었습니다. CDN에서 제공되는 사전 구축된 페이지의 대규모 사이트에서 사용자를 위해 즉석에서 아무것도 구축하지 않기 때문에 성능이 여전히 우수한 것은 사실입니다.

그러나 이러한 이점은 사이트가 사전 구축된 경우에만 발생할 수 있으며 해당 프로세스에는 시간이 많이 소요될 수 있습니다. 보다 전통적인 사이트는 귀하가 요청할 때 페이지를 구축하지만, 우리는 말 그대로 사용자가 필요할 경우를 대비하여 모든 단일 페이지를 미리 생성합니다. 그것은 성능을 초고속으로 만듭니다! 그러나 그 시간은 이제 개발 및 게시 시간으로 분담되어 모든 페이지를 만드는 데 시간이 걸릴 수 있습니다.

이것은 소규모 사이트에서는 그다지 문제가 되지 않지만 Smashing Magazine의 규모에서 우리는 그 시간에 대해 조금 더 생각할 필요가 있습니다. 특히 사람들이 매일 적극적으로 콘텐츠를 생성하면서 높은 생산성을 유지할 수 있도록 하기 위해서입니다.

Netlify가 한 일은 이미 호스팅하고 있던 1000개에 달하는 기사의 대부분을 담고 있는 큰 /production-articles 폴더를 만드는 것이었습니다. 그런 다음, 활발하게 생성되고 편집된 기사를 넣을 수 있는 content/articles 라는 별도의 작업 디렉토리를 만들었습니다.

이 빌드 프로세스는 사이트에서 작업하는 모든 사람들이 전체 빌드를 기다리는 데 방해를 받지 않고 로컬 개발을 위해 더 적은 양의 기사로 작업하고 있음을 의미했습니다. 이 프로세스는 생산 기사를 준비하는 꿀꺽 꿀꺽 작업으로 관리되었으며 Hugo는 활발하게 작업 중인 작업만 처리하도록 했습니다.

이 접근 방식의 단점 중 하나는 전체 빌드를 실행해야 하므로 프로세스가 느려진다는 것입니다. 소규모 출판물에서는 이것이 덜 중요할 수 있지만 Smashing의 규모에서는 출판 프로세스가 느려집니다.

오픈 소스 API

처음에 우리는 Smashing이 무엇보다도 기존 전자 상거래 솔루션을 마이그레이션하고 WordPress 외부에서 댓글을 처리하고 인증 기능을 추가하는 데 관심이 있다고 언급했습니다. 이러한 모든 기능은 Netlify가 유지 관리하는 오픈 소스 솔루션으로 구축되어 상태 비저장 API로 나뉩니다.

• 고텔
  많은 양의 주석을 처리하기 위한 API 및 빌드 도구입니다.
• 고커머스
  주문 및 결제를 처리하는 전자 상거래 사이트를 위한 작은 Go 기반 API입니다.
• 고트루
  프로젝트에 대한 사용자 등록 및 인증을 처리하기 위한 독립형 API 서비스 역할을 할 수 있는 Golang으로 작성된 작은 오픈 소스 API입니다. OAuth2 및 JWT를 기반으로 하며 사용자 가입, 인증 및 사용자 지정 사용자 데이터를 처리합니다.

이러한 각 부분에는 마이그레이션과 고유한 요소가 필요했으며 이 기사의 범위를 벗어나지만 Matt가 공동 저술 한 " JAMstack에서 현대적인 웹 개발 "이라는 무료 책에서 모두 다룹니다. 우리는 또한 다음 게시물에서 검색과 인증에 대해 이와 같은 몇 가지 심층 분석(사용 가능한 예와 함께)을 할 것입니다.

결론

마이그레이션은 순조롭게 진행되었습니다. 찰싹? 어… 잘 됐습니다. Smashing은 그 자체의 성공에 대해 불이익을 받지 않았습니다. 인기 있는 기사가 나왔을 때 콘텐츠를 일관되게 제공할 수 있었고 더 이상 큰 부하를 가하지 않았습니다. 이와 함께 JAMstack 인프라로의 이동으로 성능과 보안이 향상되었습니다.

Smashing Magazine의 전 CEO인 Markus Seyfferth는 다음과 같이 말했습니다.

"처음 로드하는 시간이 이전보다 훨씬 빨라졌습니다... HTML 파일이 800ms 동안 제공되기를 기다려야 했고 지금은 80ms 입니다."

이 프로세스는 성공적이었고 모든 훌륭한 엔지니어링 프로젝트와 마찬가지로 그 과정에서 교훈을 얻었습니다. 이 시리즈의 다음 기사에서는 학습한 내용을 바탕으로 권장할 내용에 대한 자습서와 데모를 실행합니다. WordPress 개발을 현대화하고 JAMstack의 성능 및 보안 이점을 누리고 싶다면 계속 읽으십시오!