WordPress와 Jamstack

최근 NetLify의 Virtual Jamstack Conference에서 NetLify CEO Matt Biilman 및 자동 설립자 인 Matt Mullenweg를 포함하여 패널을 주최했습니다. 논의는 많은 사람들이 "Jamstack vs. WordPress 분쟁"으로 여겨졌다.

나는 개인적으로 이것에 대해 많은 생각을 가지고 있으며 중재자보다 해설자가되기에 더 적합하다고 생각합니다. 이것은 지금 내가 가장 좋아하는 기술 토론 중 하나입니다! 그러니 블로그를 작성하도록 해주세요.

성명서 : Automattic 및 Netlify는이 웹 사이트의 활발한 후원자입니다. 나는 둘 다 사용하는 일부 생산 사이트를 가지고 있으며 솔직히, 나는 그들 모두를 사랑합니다. 이것은 내가 자세히 설명하려고 노력할 주요 요점입니다. WordPress 웹 사이트 에이 기사를 작성하고 게시하고 있습니다.

역사 검토

1. Richard MacManus는“WordPress의 공동 창립자 인 Matt Mullenweg는 Jamstack의 팬이 아닙니다.”라는 기사를 발표했습니다.“Jamstack을 입양하는 대다수의 사람들에게는 반발입니다.”라고 Matt는 말했습니다.
2. Matt Biilmann은 "Mullenweg and Jamstack - Backward 또는 Future?"기사에 응답했으며 "WordPress 시대의 끝"이라는 섹션이 있습니다.
3. 이 기간 동안 사람들은 논평했다. Netlify 이사회 멤버 Ohad Eder-Pressman은 공개 서한을 썼습니다. Sarah Gooding은 WP Tavern (Matt Mullenweg 소유)에서 일부 활동을 요약했습니다. 나도 관여합니다.
4. Matt Mullenweg는 그의 의견을 명확히하고 몇 가지 새로운 의견을 추가했습니다.

토론은 2020 Jamstack Virtual Conference에서 열렸습니다. 현재 공개 비디오 레코드가 없습니다 (죄송합니다).

아키텍처 비교

Jamstack과 WordPress를 비교하는 것은 약간 이상합니다. 실제로 비슷한 점은 웹 사이트를 구축 할 때 선택할 수있는 모든 방법이라는 것입니다. 이 게시물의 대부분은 이것을 명심하고 이런 방식으로 두 가지를 비교합니다. 직접 비교할 수없는 이유는 다음과 같습니다.

• Jamstack은 CDN에 정적 파일을 사용하고 JavaScript에서 액세스하는 서비스를 사용하여 역동적 인 요구를 충족시키는 건축 개념에 대한 광범위한 설명입니다.
• WordPress는 램프 아키텍처를 기반으로 한 CMS입니다.

둘은 정확히 같지 않습니다.

우리가 당분간 아키텍처 에만 초점을 맞추면 비교하는 대상은 다음과 같습니다.

• 정적 호스팅 서비스
• 램프

정적 서비스의 예는 NetLify를 호스팅 (정적)에 사용하고 서비스를 사용하여 수행 해야하는 동적 작업을 수행하는 것입니다. 데이터 저장에는 NetLify의 자체 양식 및 인증 기능 및 Hasura를 사용합니다.

램프 아키텍처에서는 MySQL을 사용하여 데이터를 저장하므로 외부 서비스를 사용할 필요가 없습니다. PHP를 사용할 수도 있습니다. 따라서이 (및 오픈 소스 소프트웨어)를 사용하면 인증에 필요한 모든 것이 있습니다. 그러나 그렇다고해서 서비스를 사용 하지 않는다는 의미는 아닙니다. 서버에 이미 더 많은 기술이 있기 때문에 서비스를 덜 자주 사용하는 것입니다.

Matt B. 호출 램프 아키텍처 "단량체 아키텍처". Matt M.은 이것에 반대하여 그것을 "통합 방법"이라고 불렀습니다. 나는 컴퓨터 과학자가 아니지만 두 진술이 모두 의미가 있다고 생각합니다. Wikipedia의 설명은 다음과 같습니다.

[…] Monolithic 응용 프로그램은 사용자 인터페이스 및 데이터 액세스 코드가 프로그램에 결합되는 단일 계층 소프트웨어 응용 프로그램을 설명합니다.

이 정의에 따르면 WordPress는 모 놀리 식 아키텍처 인 것처럼 보이지만 Wikipedia 기사는 계속됩니다.

[…] 모 놀리 식 응용 프로그램은 모듈 식으로 설계되지 않은 소프트웨어 응용 프로그램을 설명합니다.

이러한 관점에서, WordPress는 모 놀리 식 구조의 정의를 충족하지 않는 것 같습니다. WordPress의 후크 및 플러그인 아키텍처는 모듈 식입니다. ? ‍ ♂️

이 두 명의 큰 사람들 이이 심층적 인 논의를 듣는 것은 흥미로울 것이지만 소프트웨어는 소프트웨어입니다. 자체 호스팅 된 WordPress 웹 사이트는 전체 기술 스택이있는 서버에서 실행됩니다. 이 서버 (예 : 통합)를 최대한 활용하는 것이 합리적입니다. Jamstack 메소드에서 서버는 추상적입니다. 해야 할 다른 모든 일은 다른 서비스 (즉, 통합되지 않은)로 나뉩니다.

WordPress 방법이 외부 서비스를 사용 하지 않는다는 의미는 아닙니다 . 두 아키텍처 모두에서 스트라이프와 같은 전자 상거래 API를 사용할 수 있습니다. 강력한 미디어 스토리지 및 서비스를 위해 Cloudinary와 같은 서비스를 사용할 수 있습니다. WordPress의 JetPack 서비스 (내가 사용하고 사랑하는)조차도 자산 양육권 및 검색 기술을 클라우드 서버로 이동시켜 타사 서비스처럼 실행되는 자체 주최 WordPress 웹 사이트에 큰 힘을 제공합니다. 두 아키텍처 모두 기술 모음입니다.

아키텍처도 "카드의 집"이 아니며 다른 것보다 더 취약하지 않습니다. 모든 웹 사이트는“강도가 가장 약한 링크에 의존한다”는 은유를 적용 할 수 있습니다. WordPress 플러그인이 잘못된 버전을 게시하거나 업로드 할 때 어떻게 든 고장난 경우, 수정 될 때까지 웹 사이트에 문제가 발생할 수 있습니다. 서버리스 데이터베이스의 API 키가 유효하지 않은 경우 수정 될 때까지 Jamstack 웹 사이트에 문제가있을 수 있습니다. Stripe가 다운되면 서비스를 재개 할 때까지 모든 유형의 웹 사이트에서 제품을 판매 할 수 없습니다.

가격

WordPress.com에는 무료 계획이 있으며 웹 사이트를 구축 할 수있는 곳입니다. (몇 가지가 있습니다.) 그러나 월 $ 25의 사업 계획을 사용하지 않는 한 실제로 개발자 수준의 기능에 액세스 할 수 없습니다. 자체 주최 된 WordPress 자체는 오픈 소스이며 무료이지만 자체 호스팅 된 WordPress 웹 사이트를 무료로 시작할 장소를 찾을 수는 없습니다. 저렴한 가격으로 시작하여 점차 증가합니다. WordPress를 실행하려면 램프 호스팅이 필요합니다. 다음은 매우 저렴한 호스팅 계획입니다.

• Bluehost의 "공유"계획은 한 달에 $ 3.95에서 시작합니다.
• Flywheel의 최소 계획은 한 달에 $ 14입니다. (이 웹 사이트는 Flywheel의 프리미엄 프로그램을 사용합니다.)
• Media Temple의 WordPress 관련 호스팅은 한 달에 $ 20부터 시작합니다. (이 웹 사이트는 Media Temple의 프리미엄 프로그램을 오랫동안 사용해 왔습니다.)
• Automatic의 압박 가능한 서비스에는 한 달에 25 달러부터 시작하는 계획이 있습니다.

처음부터 비용이 듭니다.

Jamstack은 무료로 시작하는 것이 더 일반적입니다. 그런 다음 다른 시점에서 비용이 발생합니다. Jamstack은 비교적 새롭기 때문에 시장이 여전히 탐구되고있는 것처럼 느껴집니다.

• Vercel은 팀원이나 암호로 보호 된 웹 사이트와 같은 기능이 필요할 때까지 무료입니다. 단일 비밀번호로 보호 된 웹 사이트는 한 달에 $ 150입니다. 추가 비용없이 Apache를 사용하여 모든 서버에 기본 인증을 추가 할 수 있습니다.
• NetLify는 높은 계획에서 기능을 잠금 해제하고 분석 (한 달에 9 달러) 및 인증 (5,000 명의 활성 사용자의 경우 월 $ 99)과 같은 유료 기능을 제공합니다.
• AWS Amplify는 무료로 시작하지만 AWS의 모든 것과 마찬가지로 사용량은 빌드 분, 스토리지 및 대역폭과 같은 여러 수준으로 수량 기반으로 청구됩니다. 웹 애플리케이션에 하루에 10,000 명의 활성 사용자가 있고 한 달에 두 번 업데이트되며 한 달에 65.98 달러의 예제가 있습니다.
• Azure Static Web Apps는 아직 가격 책정을 출시하지 않았지만 거의 확실히 무료 계층이나 무료 사용 또는 어떻게 든 있습니다.

이 모든 것이 NetLify가 Jamstack 공간에서 유일한 플레이어가 아니라는 것을 상기시킵니다. Jamstack은 정적 호스팅 플러스 서비스를 의미합니다.

Jamstack과 같은 일반적인 진술을 저렴하게 만들 수는 없습니다. 이것은 웹 사이트 사용 및 웹 사이트의 요구에 너무 달려 있습니다. 높은 사용량과 많은 고급 서비스를 위해 Jamstack (서버리스와 마찬가지로)은 매우 비싸 질 수 있습니다. Jamstack은 비즈니스 가격이 한 달에 3,000 달러부터 시작하며 인증, 양식 및 미디어 처리와 같은 기능을 얻을 수 있지만 CMS 또는 데이터 저장소를 얻지 못하면 비용을 크게 만들 수 있습니다.

이 WordPress 사이트는 엔터프라이즈 등급이 아니지만 CloudFlare가 호스트로 직접 대역폭을 줄이고 JetPack의 미디어 호스팅 및 검색 기능 처리에 직접 대역폭을 줄이는 데 도움이되기 위해 서버의 경우 한 달에 약 1,000 달러가 필요하다고 말할 수 있습니다. MailChimp는 뉴스 레터를 보냅니다. Wufoo는 우리의 양식을 지원합니다. 또한 Advanced Custom Fields Pro 및 일부 WooCommerce 애드온과 같은 플러그인도 지불했습니다. 그게 전부는 아닙니다. 총은 한 달에 수천 달러 일 수 있습니다. 이것은 통합 접근 방식에 고유하지는 않지만 WordPress 웹 사이트의 비용도 상당히 높을 수 있음을 설명하는 데 도움이됩니다. 그들은 가격 (비즈니스를위한 일반적인 전략)을 게시하지 않지만 Automattic의 자체 WordPress VIP 호스팅 서비스는 4 자리 이상으로 가격이 책정되며 타사 콘텐츠를 추가해야합니다.

결론 : 가격에는 큰 변화가 없습니다.

성능

웹 페이지 성능의 80%가 프론트 엔드 문제입니다.

이것은 사실이지만 서버 ( 초기 의 20%)를 기반으로합니다. 서버의 첫 번째 요청이 반환하는 데 몇 초가 걸리면 전 세계에서 가장 빠른 인터페이스는 그리 빠르지 않습니다. 빠른 웹 사이트를 원한다면 첫 번째 요청이 매우 빠르지 않도록해야합니다.

슈퍼 빠른 것이 무엇인지 아십니까? Global CDN은 정적 파일을 제공합니다. 백엔드 서버, 호스팅 또는 CMS 상황에 관계없이 이것이 달성하고자하는 것입니다. 이것이 Jamstack (정적 CDN 지원 호스팅)의 기초이지만 WordPress가 그렇게 할 수 없다는 것을 의미하지는 않습니다.

NetLify에 정적 컨텐츠가있는 index.html 파일을 넣으면 매우 빠릅니다. 정적 웹 사이트 생성기가 해당 파일을 생성 할 수 있습니다 (WordPress에서 컨텐츠를 얻을 가능성이 높다는 점을 지적 할 가치가 있습니다). 이것은 매우 굉장합니다.

기본적으로 WordPress는 글로벌 CDN에 캐시 할 수있는 정적 파일을 생성하지 않습니다. WordPress는 단일 소스의 요청에 응답하고 PHP를 실행 한 다음 데이터베이스에서 컨텐츠를 요청한 다음 응답을 조립 한 다음 마지막으로 페이지로 돌아갑니다. 이것은 빠를 수 있지만 글로벌 CDN의 정적 파일보다 훨씬 안정적이며 요청에 의해 압도 될 가능성이 높습니다.

WordPress 호스트는 이것을 알고 있으며 호스팅 수준 에서이 문제를 해결하려고합니다. WP 엔진 방법을 살펴보십시오. 아무것도하지 않으면 페이지 캐싱을 사용하여 웹 사이트가 기본적으로 PHP를 실행하거나 데이터베이스에 액세스하지 않고 정적 자산을 반환 할 수 있습니다. 또한 최적의 캐싱을 위해 CloudFlare 작업을 포함하여 다양한 캐싱 기술을 사용합니다. 내 shoptalkshow.com 웹 사이트는 실제로 글을 쓸 때 다운되었습니다. 나는 호스트 플라이휠에 편지를 써서 무슨 일이 있었는지 보았다. 내가 거기에 가서 스테이징 사이트를 열었을 때, 나는 잘못된 스위치를 전환하여 캐시를 끄는 것으로 밝혀졌습니다. 웹 사이트는 트래픽과 충돌을 직접 처리 할 수 ​​없습니다. 캐시 스위치를 다시 켜면 문제가 즉시 해결되었습니다. 웹 사이트 앞에서 CloudFlare를 사용하지는 않지만해야합니다.

CloudFlare는 WordPress를 더 빨리 만들기위한 마법의 팁의 일부입니다. 자체 주최 WordPress 웹 사이트 앞에 놓으면 속도와 신뢰성을 향상시키는 데 큰 역할을 할 수 있습니다. 누락 된 부품 중 하나는 HTML 자체의 우수한 캐싱으로, 이번 달에 해결되었으며 이제는 캐시를 사용할 수 있습니다. 흥미롭게도 WordPress는 캐시 요청이 정적 HTML 및 정적 자산으로서의 캐시 요청을 의미하며 궁극적으로 Jamstack의 본질입니다.

Matt M.은 WordPress.com이 특정 트래픽 수준에서 출시 된 글로벌 CDN을 사용한다고 언급했습니다. CloudFlare인지 확실하지 않지만 의심하지 않을 것입니다.

WordPress 사이트 앞에서 CloudFlare를 사용한 후, 내가 보는 첫 번째 응답 번호는 CloudFlare가없는 NetLify 사이트와 동일합니다 (NetLify 호스팅 사이트 앞에서 CloudFlare를 사용하지 않는 것이 좋습니다). 이것은 두 자리 자리 밀리 초에 계산됩니다.

이 기초에서 성능에 대한 모든 논의는 프론트 엔드에 따라 다릅니다. 프론트 엔드 속도 전략은 백엔드 서버, 호스팅 또는 CMS 상황에 관계없이 동일합니다.

보안

Jamstack 웹 사이트보다 해킹 된 WordPress 웹 사이트에 대한 더 많은 이야기가 있습니다. 그러나 WordPress가 덜 안전하다고 말하는 것이 공평합니까? WordPress는 약 20 년 동안 주변에 있었고, 그 웹 사이트의 수는 Jamstack보다 몇 배 더 많습니다. 보안을 제쳐두고,이 숫자를 고려할 때, WordPress의 더 많은 이야기를들을 수 있습니다.

Matt M은 Whitehouse.gov가 WordPress를 사용한다고 언급했는데, 이는 분명히 최고 수준의 보안이 필요한 웹 사이트입니다. 이것은 WordPress 자체가 안전하지 않은 소프트웨어라고 말하는 것은 아닙니다. 핵심은 사용 방법입니다. 비밀번호가 안전하지 않습니까? 어떤 플랫폼을 사용하든 안전하지 않습니다. 서버 자체가 파일 권한 또는 액세스 레벨을 전달하는 것이 안전하지 않습니까? 이것은 전적으로 소프트웨어의 잘못이 아니지만 소프트웨어로 인해이 상황에있을 수 있습니다. 최신 버전의 WordPress를 실행하고 있습니까? 사용법은 기껏해야 분산되고 버전이 오래 될수록 보안이 적습니다. 힘든.

매체를 공격하는 것이 더 흥미로울 수 있습니다. 즉, 포인트가 해킹 될 수있는 것 입니다. 정적 파일이 정적 호스팅에 있다면 공격 벡터가 상당히 작다고 말하는 것이 안전하다고 생각합니다. 그러나 여전히 일부가 있습니다.

• 호스팅 계정이 해킹 될 수 있습니다
• GIT 저장소가 해킹 될 수 있습니다
• CloudFlare 계정이 해킹 될 수 있습니다
• 도메인 이름이 도난 당할 수 있습니다 (발생합니다)

WordPress 웹 사이트에 대해서도 마찬가지이지만 다음과 같은 다른 공격 벡터가 있습니다.

• 서버 측 코드 : XSS, 불량 플러그인, 원격 실행 등
• 데이터베이스 취약성
• 이전 버전의 WordPress를 실행하십시오
• 시스템에 로그인은 웹 사이트 자체에 있습니다. 예를 들어, Bad Guys는 /wp-login.php를 공격 할 수 있습니다.

WordPress 웹 사이트에는 더 많은 공격 벡터가 있지만 모든 웹 사이트에 많은 미디어가 있다고 말하는 것이 공정하다고 생각합니다. 모든 웹 사이트에 대한 호스팅 계정은 주요 매체입니다. DNS 체인의 모든 것. 로그인 정보가있는 타사 서비스. API 키가있는 모든 내용.

개인 경험 :이 웹 사이트는 WordPress를 사용하고 해킹 된 적이 없지만 시도되지 않았기 때문이 아닙니다. 정적 웹 사이트 생성기 만 제작 한 사이트보다 WordPress 웹 사이트의 보안에 대해 더 많이 생각해야한다고 생각합니다.

확장 성

모든 방법을 연장하는 데 비용이 듭니다. 이 WordPress 웹 사이트의 규모는 확장되지 않았지만 엔트리 레벨 서버보다 더 까다로운 확장이 필요합니다. CloudFlare를 통해 모든 트래픽을 제공하고 있으므로 지난 30 일의 피크 데이터는 한 달에 5TB 대역폭을 제공하고 있음을 보여줍니다.

Netlify 사업 계획 (한 달에 600GB의 트래픽을받은 다음 추가 100GB마다 20 달러를 청구)에서 계산은 $ 979입니다. 이 웹 사이트가 한 달에 약 $ 1,000의 서버가 필요하다고 말했을 때 기억하십니까? 나는이 숫자를 실행하기 전에 이것을 썼기 때문에 매우 가깝습니다 (굉장했습니다). 이 웹 사이트의 규모에서 Jamstack은 WordPress와 비슷합니다. 모든 호스트는 대역폭을 충전하고 과충전 제한이 있습니다. 15GB 월간 캡에 대한 대역폭에 대해 GB 당 $ 0.15를 증폭시킵니다. 월간 방문자 한도를 기준으로 Flywheel (My WordPress 호스팅) 요금이 부과되며 한도를 초과 한 후 1,000 명당 $ 1가 청구됩니다.

WordPress 확장 스토리는 다음과 같습니다.

• 그것을 처리 할 수 ​​있고 자체 성숙한 캐싱 정책이있는 호스트를 사용하십시오.
• cdn 모든 것 (이것은 일반적으로 cloudflare를 앞에 두는 것을 의미합니다).
• 궁극적으로, 당신은 그것을 지불 할 것입니다.

Jamstack Extension의 이야기는 다음과 같습니다.

• 호스트와 서비스는 모두 스케일링을 위해 구축되었습니다.
• 이 서비스가 이것을 처리 할 수 ​​있는지 아니면 마이그레이션이 필요합니까? 이와 같은 확장 문제.
• 각 서비스의 모든 측면에주의가 필요한 가격이 있다는 사실에 대해 더 많이 고려해야합니다.
• 궁극적으로, 당신은 그것을 지불 할 것입니다.

웹 사이트의 현재 요구와 일치하는 호스트를 찾기 위해 WordPress 호스팅을 마이그레이션해야했습니다. WordPress 웹 사이트를 마이그레이션하는 것은 쉽지 않지만 다른 CMS로 마이그레이션하는 것보다 훨씬 쉽습니다. 예를 들어, 헤드리스 CMS에 Jamstack 웹 사이트를 구축하고 가격이 너무 높아지면 마이그레이션 비용이 호스트를 전환하는 것보다 큽니다.

나는 다른 날에 Dave Rupert (슬랙 대화에서)를 좋아했습니다.

JAMSTACK : 물건을 만들기 위해 무엇이든 사용하십시오. 도움이 될 수있는 추가 기능이 있으며, 우리의 물건을 사용하여 CDN에 배치하여 충돌하지 않도록하십시오.

WordPress : 우리의 물건을 사용하여 물건을 만들고, 당신을 도울 수있는 추가 기능이 있습니다. 어떤 호스트를 사용하여 충돌을 방지해야합니다.

다른 유형의 "확장"이 있습니다. 내가 생각하는 것은 사용자의 수 와 다른 것들입니다. 이것은 가격 계층에 다양한 서비스를 사용하기위한 이해하기 쉬운 지표입니다. 그러나 WordPress에서는 무료입니다. 원하는만큼 사용자를 가질 수 있으며 원하는만큼 세심한 권한을 가질 수 있습니다. 이것은 단지 CM이므로 다른 서비스를 추가하면 여전히 사용자 당 청구 될 수 있습니다. 팀 계정에 대한 사용자 당 vercel 또는 netlify 요금. 콘텐츠 (인기있는 헤드리스 CMS)는 한 달에 $ 489에서 시작합니다. 무료 계정이 제공하지 않는 기능이 필요한 경우 GitHub의 팀 티어조차도 사용자 당 $ 4입니다.

프론트 엔드와 백엔드를 분리하십시오

이것은 사람들이 Jamstack으로 웹 사이트를 구축하는 것에 흥분하게 만드는 큰 요소입니다. 내 웹 사이트의 모든 기능과 내용이 API 뒤에 있으면 프론트 엔드를 원하는대로 구축 할 수 있습니다.

• 완전히 정적 인 웹 사이트를 구축하고 싶으십니까? 자, 빌드 프로세스 중에 해당 API에 액세스하고이를 수행하십시오.
• React 또는 Vue 또는 다른 것을 사용하여 클라이언트 측 렌더링 된 웹 사이트를 구축하고 싶습니까? 매우 좋습니다. 클라이언트 액세스 API.
• 중간, 사전 렌더 일부, 클라이언트 측 렌더링, 서버 측 렌더링을 분할하고 싶습니까? 쿨, 이것은 원하는만큼 액세스 할 수있는 API입니다.

이 유연성은 새로운 빌드에서 훌륭하지만 사람들은 이론적 미래의 유연성 에 대해 똑같이 흥분합니다. 모든 기능과 컨텐츠가 API 중심 인 경우 프론트 엔드와 백엔드를 완전히 분리 할 수 ​​있으므로 향후 양쪽에 더 유연하게 변경할 수 있습니다.

• API가 프론트 엔드가 기대하는 것을 계속 출력하는 한 프론트 엔드에 영향을 미치지 않고 백엔드를 재구성 할 수 있습니다.
• 필요한 데이터를 얻는 한 백엔드에 영향을 미치지 않고 프론트 엔드를 재구성 할 수 있습니다.

특정 크기와 크기의 웹 사이트의 경우이 분리는 "미래에 안전하다"고 느낍니다. 나는이 크기 숫자가 무엇인지 정확히 정확히 정확히 정확하게 지적 할 수는 없지만 존재합니다.

한 당사자 나 다른 당사자에게 맞도록 주요 웹 사이트를 다시 한 번도 한 적이 있다면 백엔드와 프론트 엔드를 분리하는 시스템으로 이동하는 것이 현명한 움직임을 느낍니다.

WordPress 웹 사이트를 분리 할 수 ​​있지만 ( "두 가지 사용"섹션에서 논의하겠습니다) 기본적으로 WordPress는 PHP의 테마로 구축 된 매우 통합 된 솔루션입니다. 분리가 전혀 없습니다.

개발자 경험

Jamstack은 개발자 경험 (DX)을 크게 우선시했습니다. 나는 그것을 "로컬 최적 성"이라고 부르는 것을 들었습니다. 이는 Jamstack의 디자인이 지역 개발 (및 지역 개발자) 경험을 중심으로 한 것을 의미합니다.

• 현지에서 일해야합니다. 편안한 (지역, 빠른, 맞춤형) 개발 환경에서 일합니다.
• Git은 최초의 시민입니다. 생산 지점 (예 : 마스터 또는 메인)으로 밀고 빌드 프로세스가 실행되고 웹 사이트가 배포됩니다. 모든 풀 요청에 대해 프로덕션 웹 사이트의 미리보기 URL을 얻을 수도 있습니다.
• 원하는 도구를 사용하십시오. Hugo에서 웹 사이트를 사전 제작하고 싶습니까? 그냥 해요. 학교에서 Create-React-App을 배웠습니까? 사용되지만. 최신 프레임 워크를 시도하고 싶습니까? 당신이 시도하더라도. 리포지토리에서 원하는 폴더를 빌드하고 배포 할 수 있다는 사실을 활용하여 자신의 길을 자유롭게 구축 할 수 있습니다.
• 당신이 할 필요가없는 것들도 중요합니다. HTTPS를 처리 할 필요가없고 캐시를 처리 할 필요가 없으며 파일 권한에 대해 걱정할 필요가 없으며 CDN을 구성 할 필요가 없습니다. 선임 개발자조차도 더 많은 일을 할 필요가 없다는 것을 감사합니다.

이것은 WordPress가 개발자 경험을 고려하지 않는다고 말하는 것은 아닙니다 (예 : 빌딩 블록과 같은 유용한 작업을 수행하는 CLI가 있습니다). DX는 프로젝트의 핵심만큼 중요하다고 생각하지 않습니다.

• 로컬로 WordPress를 실행하는 것은 까다 롭고 어쨌든 (x) 앰프 스택을 실행 해야하는데, 여기에는 악명 높은 타사 소프트웨어가 포함됩니다. Flywheel에 의해 현지인에게 감사드립니다. 약간의 지침이 있지만 우선 순위처럼 느껴지지 않습니다.
• git에 무엇을 넣어야합니까? 오늘날까지도 여전히 명확하지 않지만 기본적으로 전체 /WP- 콘텐츠 폴더를 사용하기로 결정했습니다. 나에게는 안내 나 모범 사례가 없다는 것이 이상하다고 느낍니다.
• 귀하는 자신의 배포에 대한 책임이 있어야합니다. WordPress 전용 호스트조차도 실제로 그렇게하지 않습니다. 이것은 주로 단지 : 이것은 당신의 SFTP 자격 증명입니다 .
• 현지 개발 및 배포 파이프 라인이 설정되어 있더라도 (저는 매우 만족합니다) (저는 매우 만족합니다) 이것은 데이터베이스의 움직임에 실제로 도움이되지 않으므로 직접 책임을 져야합니다.

이것들은 모두 해결할 수있는 문제이며 WordPress 커뮤니티는 거대하며 많은 관련 정보를 찾을 수 있지만 WordPress가 DX를 핵심으로 사용하지 않는다고 말하는 것이 공정하다고 생각합니다. 이 세월이 지난 후에도 여전히 와일드 웨스트와 비슷합니다.

사실, 나는 많은 사람들이 건강한 지역 개발 환경에 대한 격려의 소외로 인해 지역 개발 환경을 가지고 있지 않다는 것을 알았습니다. 일화이지만 이제는 다른 사람들의 웹 사이트에 전적으로 생산 전용 이라는 두 번의 나 자신이 참여했습니다. 매우 간단한 사이트이고 기본 동작이 크지 않다면 다른 이야기이지만 이러한 사이트는 그렇지 않습니다. 공개 사용자 로그인, 유료 멤버십 및 권한, 페이지 빌더, 맞춤형 단축 코드, 사용자 정의 CSS 및 많은 활성 부품이 포함 된 매우 복잡합니다 (이 사이트보다 훨씬 복잡함). 이것은 나를 매우 두려워합니다. 나는 아무것도 만지고 싶지 않습니다. 사람들이 농담 한 데님 코딩 으로 작업을 수행하기 위해 현장에서 PHP를 편집하고 있습니다. 구문 오류가 발생하면 웹 사이트가 충돌하고 아마도보고있는 페이지도있을 수 있습니다.

특히 좋은 DX가없는 WordPress의 전원은 매우 흥미 롭습니다. DX가 없으면 Jamstack이 없습니다. 이것은 전적으로 개발자를위한 것입니다. WordPress의 경우 대부분의 웹 사이트에는 개발자가 전혀 없을 수 있습니다 . 설치 (또는 WordPress.com의 경우 활성화) 웹 사이트 소유자가 시작합니다. 웹 사이트 소유자 는 개발자와 같으며 많은 힘이 있지만 코드를 전혀 작성하지 않을 수 있습니다.

이를 위해 WordPress가 DX보다 UX에 더 집중한다고 말하고 싶습니다.

CMS 및 최종 사용자 UX

WordPress는 매우 좋은 CMS입니다. 당신이 그것을 좋아하지 않더라도, 그것을 좋아하는 많은 사람들이 있으며, 데이터는 그것을 모두 말합니다. WordPress를 사용하여 웹 사이트를 구축하기로 결정하면 원하는 거의 모든 유형의 웹 사이트를 구축 할 수 있습니다. WordPress에서는 일어나지 않을 것입니다 . 나는 막 다른 길로 나 자신을 밀고 있습니다 .

이것은 큰 문제입니다. Jenn은 WordPress를 사용하는 사람들이 개발자의 요구보다 더 중요하다고 지적하면서 이것을 지적합니다.

WordPress는 많은 일을 할 수 있습니다.

• 블로그 (또는 모든 유형의 콘텐츠 중심 CMS 스타일 웹 사이트)…
  • 컨텐츠 미리보기를 사용하면 Jamstack에서는 가능하지만 까다 롭습니다.
• 사용자/권한 처리…
  • 관리자/CMS 수준에서
  • 사용자 지향 수준 (예 : 포럼, 구독, 소셜 등)에서
• 전자 상거래
• 처리 양식
• 플러그인을 극단적으로 처리합니다

Jamstack은 이러한 모든 것을 확실히 할 수 있지만 이제는 Wild West 시대의 Jamstack입니다. 데이터 저장 방법에 대한 자습서를 살펴보면 일반적으로 클라우드 데이터베이스에 대한 단일 CRUD 기능을 작성하는 방법을 설명하는 것이 포함됩니다. 이것은 근본적인 일입니다. 매우 강력 할 수 있지만 몇 개의 버튼을 클릭하는 것과는 매우 다르며 WordPress가 여러 번 느끼는 방식입니다.

나는 Stripe API를 사용하여 기본 Jamstack 전자 상거래 설정을 함께 만들 수있을 것입니다. 그러나 재고 관리, 운송 영역, 제품 변형 및 전자 상거래 세계에서 어떤 복잡한 것들이 있는지 알고있는 사람이있는 경우 긴장감을 느끼게됩니다.

때때로 우리는 개발자가 스스로 웹 사이트를 구축하는 것입니다 (저는 이것을 많이합니다). 그러나 개발자는 주로 다른 사람들을위한 웹 사이트를 구축하고 있다고 생각합니다. 그래서 가장 중요한 질문은 다음과 같습니다. 내가 구축하는 것이 내가 건축하는 사람들의 능력을 향상 시키는가?

어쨌든 좋은 웹 사이트 관리 경험을 달성 할 수 있지만 WordPress는 의심 할 여지없이 맞춤형 개발에 너무 많은 노력을 기울이지 않고 현장에서 서비스를 제공한다는 것을 입증했습니다.

그러나 Jamstack에는 WordPress에서 구현하고자하는 몇 가지 팁이 있습니다. 저에게 중요한 요령은 사용자 제출 콘텐츠 및 업데이트입니다. 나는 실제로 이것의 혜택을받는 세 곳이 있습니다. 회의에 관한 웹 사이트, 서버리스에 관한 웹 사이트 및 코딩 글꼴에 대한 다가오는 웹 사이트. WordPress는 세 사이트 모두에서 훌륭한 일을 할 수 있습니다. 그러나 내가 정말로 원하는 것은 사람들이 내가 말할 수있는 방식으로 콘텐츠를 업데이트하고 커밋 할 수 있도록하는 것입니다. 예, 좋아 보인다. Jamstack 접근 방식을 채택함으로써 컨텐츠는 공개 Github 저장소에 있으며 누구나 참여할 수 있습니다.

나는 이것이 훌륭하다고 생각한다. NetLify CMS는 공개 생성의 개념을 가지고 있기 때문에 대중의 누군가가 GIT 또는 GITHUB를 이해하거나 이해하도록 요구하는 것은 아니며, 이는 브라우저의 전체 기여 경험을 유지하고 편집을위한 UI를 제공하기 때문입니다.

둘 다 동시에 사용하십시오

이것은 내가 자주 언급되는 중요한 질문입니다. Netlify 자체조차도 "반대 없음"이라고 말합니다.

문제는 이것입니다.

• "a in"jam "은 API를 나타냅니다. API를 사용하여 Build Time 또는 Client에서 웹 사이트를 구축하십시오.
• WordPress 웹 사이트에는 기본적으로 REST API가 있으며 GraphQL API도 가질 수 있습니다).
• 따라서이 API를 사용하여 Jamstack 웹 사이트에서 CMS 데이터를 얻으십시오.

예, 완전히 괜찮습니다. 이것은 효과가 있으며 사람들은 그것을하고 있습니다. 나는 이것이 시원하다고 생각한다.

하지만……

• Jamstack 웹 사이트 외부에서 WordPress 웹 사이트를 실행한다는 것은… WordPress 웹 사이트와 Jamstack 웹 사이트를 실행하고 있습니다. 비용과 기술 부채가 발생합니다.
• 당신은 일반적으로 WordPress의 모든 가치를 얻지는 않습니다. API를 사용하여 데이터를 얻는 것은 아마도 당신이해야 할 일이지만, 이것은 WordPress 테마를 구축하는 매우 다른 방법입니다. WordPress에서 다른 가치를 얻지 못합니다. 내가 생각하는 것은 다음과 같은 상황입니다. 웹 사이트에 멋진 Gutenberg 블록을 추가하는 멋진 플러그인을 찾습니다. 이것은 WordPress 사이트에서 "Just Run"이지만 API에서 HTML을 추출하는 경우 작동하지 않는 특별한 프론트 엔드 동작이있을 수 있습니다. 여기에는 프론트 엔드 호스팅 위치에 합병하는 방법과 직접 업데이트를 유지하는 방법을 알아 내야하는 추가 스크립트와 스타일이 포함되어 있습니다.

다음은 고유 한 "두 가지 모두"접근 방식을 가진 참가자입니다.

• Frontity : WordPress의 React 프레임 워크. 그 뒤에 실행하고 WordPress 웹 사이트뿐만 아니라 노드 서버를 사용할 수 있습니다. 노드 서버는 HTML에 반응하여 모든 페이지에 대해 서버 측 렌더링을 수행 할 수 있지만 여전히 스파를 구축 할 수 있습니다.
• WP2STATIC : 웹 사이트의 정적 버전을 빌드하고 변경 될 때 자동으로 배포하는 WordPress 플러그인.
• Strattic : 그들은 WordPress를 정상적으로 사용할 수있는 동적 WordPress 웹 사이트 ( "준비")를 호스팅합니다. 그런 다음 배포를 선택할 수 있으며 귀하의 웹 사이트의 정적 버전을 호스팅합니다.
• Shifter : Shifter는 귀하를 위해 WordPress 웹 사이트를 주최합니다. 두 가지 옵션이 있습니다. 1) 헤드리스로 실행 (데이터를 얻기 위해 API, REST 또는 GraphQL에 액세스하기 만하면) 또는 2) 정적으로 실행하십시오 (따라서 WordPress에서 원하는 모든 것을 갖추면 웹 사이트의 정적 버전을 생성 할 수 있거나 NetLify와 같은 다른 곳에서 밀어 넣을 수 있습니다).

둘 다 통합하는 다른 많은 방법이 있습니다. 다음은 Geoff와 Sarah가 REST API와 함께 vue/nuxt를 사용하고 NetLify에서 호스팅하여 WordPress와 Jamstack을 사용하는 방법에 대해 이야기합니다.

그들 중 어느 것도 사용되지 않습니다

불분명 한 경우에만 웹 사이트를 구축하는 방법에는 여러 가지가 있습니다. Ruby on Rails 웹 사이트를 구축하는 경우 Jamstack 이나 WordPress가 아닙니다. 서버가 필요하기 때문에 WordPress 웹 사이트와 비슷하다고 생각할 수 있으며 해당 서버를 사용하여 최대한 많이 수행합니다. 또한 API와 조합 서비스가 정적으로 호스팅되지 않더라도 조합 서비스를 장려하기 때문에 Jamstack과 비슷하다고 생각할 수 있습니다.

네트워크는 큽니다. 여러분, 제로섬 게임이 아닙니다. 나는 WordPress가 계속 성장할 것으로 기대하고 네트워크 자체가 증가하고 있기 때문에 Jamstack은 계속 성장하고 있습니다. 우리가 시장 점유율의 비율 만 고려하더라도, 나는 여전히 둘 다 성장하여 다른 것을 더 작은 부문으로 밀어 넣을 것이라고 생각합니다.

선택하다

나는 여기서 논의하지 않을 것입니다. 호의를 피하기 때문이 아니라 필요하지 않기 때문입니다. 나는 손톱을 물고있는 개발자들이 WordPress 또는 Jamstack 방법을 사용하여 웹 사이트를 구축할지 여부를 결정하려고 노력하는 것을 보지 못했습니다. 우리는 기술이 충분히 이해되는 시점에 도달했으며 프로세스는 다음과 같습니다.

1. 올바른 옷을 입으십시오
2. 요구와 결과를 평가합니다
3. 기술 선택

위 내용은 WordPress와 Jamstack의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!