Jamstack에 대한 5 가지 신화

Jamstack은 새로운 것이 아닙니다. 이 용어는 2016 년에 공식적으로 등장했지만 기술과 건축은 오랫동안 존재 해 왔습니다. 최근 Jamstack은 광범위한 관심을 받았으며 주요 웹 사이트 및 간행물은 관련 보고서를 게시했으며 많은 활동, 뉴스 레터, 팟 캐스트 등이 Jamstack에 중점을두고 있습니다. Jamstack을 밀접하게 따르는 개발자로서, 나는 트위터에서 관련 토론이 크게 증가했으며, 그 중 많은 사람들이 처음 개념에 노출되었습니다.

뜨거운 토론에는 비판도 수반됩니다. 비판 중 일부는 정당화되며 나중에 일부에 대해 이야기하겠습니다. 그러나 다른 사람들은 Jamstack에 대한 지속적인 일반적인 오해에 근거한 것 같습니다. 이것이 바로 내가 먼저 해결할 것입니다. Jamstack에 대한 5 가지 일반적인 오해를 살펴보고 하나씩 반박합시다. 많은 오해와 마찬가지로, 그들은 일반적으로 실제 상황에 기반을두고 있지만 잘못된 결론으로 ​​이어집니다.

오해 1 : Jamstack은 정적 웹 사이트의 교체 포장입니다.

Jamstack 99.9%는 브랜드 마케팅이고 0.1%는 실제 콘텐츠입니다. ?? https://www.php.cn/link/33f976eca39cccf5a14627fc9f6cf1b9

- Nicole Sullivan - Black Lives Matter (@stubbornella) 2020 년 2 월 9 일

예, 앞에서 언급했듯이 "Jamstack"이라는 용어는 아마도 우리가 이전에 "정적 웹 사이트"라고 불렀던 것의 재 포장 일 것입니다. 이것은 아직 완전히 형성되지 않은 제품을 오도하거나 판매하는 것이 아닙니다. "정적 웹 사이트"라는 용어는 사람들이 무엇을 구축하는지에 대해서는 오랫동안 설명 할 수 없었습니다. 정적 웹 사이트 생성기 (SSG)로 구축 된 웹 사이트에는 종종 다양한 동적 컨텐츠와 기능이 포함되어 있습니다.

정적 웹 사이트는 주로 블로그와 문서로 간주되며 사용자 인터페이스는 주로 수정됩니다. 상호 작용의 범위는 단지 내장 된 주석 및 연락 양식 일 수 있습니다. 반면 Jamstack 웹 사이트에는 사용자 인증, 동적 컨텐츠, 전자 상거래, 사용자 생성 컨텐츠 등과 같은 기능이 포함되어 있습니다.

증거가 필요하십니까? Jamstack으로 제작 된 유명한 회사와 웹 사이트에는 Smashing Magazine, Sphero, Postman, Prima, Impossible Foods 및 Trinet이 포함됩니다.

오해 2 : Jamstack 웹 사이트는 깨지기 쉽습니다

Jay Freestone, "Jamstack에 대한 질문 : 백엔드가 필요할 수 있습니다"라는 기사에서

Smashing Magazine의 종속성 목록을 읽는 것은 Algolia, Gocommerce, Gotrue, Gotell 및 다양한 Netlify Services를 포함한 서버의 Node_modules와 같습니다. 아웃소싱 (그리고 언제) 아웃소싱 할 수있는 것이 무엇인지 아는 것은 큰 가치가 있지만“재단으로 돌아 가려는 명백한 시도에서 복잡성이 도입된다는 점에 주목할 가치가 있습니다. 그렇다고해서 많은 다른 타사 서비스에 의존하는 잠재적 취약성을 말할 필요는 없습니다.

예, Jamstack을 정적 웹 사이트와 구별하는 동적 기능을 구현하기 위해 Jamstack 프로젝트는 일반적으로 퍼스트 파티 또는 타사 서비스를 포함한 다양한 서비스에 의존합니다. 일부는 이것이 Jamstack 웹 사이트를 두 가지 이유로 특히 취약하게 만든다고 생각합니다. 첫째, 일부 부품이 실패하면 전체 웹 사이트의 기능이 중단 될 것이라고 말합니다. 둘째, 인프라는 가지고 있지 않은 도구와 서비스에 너무 의존하게됩니다.

첫 번째 논쟁을 해결합시다. Jamstack 웹 사이트의 대부분의 콘텐츠는 사전 렌더링해야합니다. 즉, 사용자가 웹 사이트를 방문하면 페이지와 대부분의 콘텐츠가 CDN에서 정적 리소스로 전달됩니다. 그렇기 때문에 Jamstack은 대부분의 속도와 보안을 얻습니다. 쇼핑 카트, 인증, 사용자 생성 콘텐츠 및 검색과 같은 동적 기능은 서버리스 기능과 API의 조합에 의존하지 않습니다.

광범위하게 말하면, 응용 프로그램은 API에 연결하는 백엔드 역할을하는 서버리스 기능을 호출합니다. 예를 들어, 전자 상거래 기능이 Stripe의 API에 의존하고 스트라이프가 줄어드면 전자 상거래 기능이 작동하지 않습니다. 그러나 웹 사이트는 다운되지 않을 것입니다. 사용자에게 문제를 말 함으로써이 문제를 우아하게 처리 할 수 ​​있습니다. 전자 상거래의 Stripe API에 의존하는 서버 측 렌더링 페이지는 동일한 문제에 직면하게됩니다. 서버 측 렌더링 페이지가 여전히 지불을 위해 백엔드 코드를 비동기로 호출한다고 가정하면 Jamstack 버전보다 더 취약하거나 취약하지 않습니다. 반면, 서버 측 렌더링이 실제로 API 호출에 의존하는 경우 사용자는 응답을 기다리거나 오류 메시지를받을 수 있습니다 (네트워크를 사용하는 사람은 이에 매우 익숙합니다).

두 번째 인수는 Jamstack 웹 응용 프로그램과 서버 측 렌더링 응용 프로그램이 제 3 자에게 의존하는 정도를 측정하기가 어렵습니다. 오늘날 많은 서버 측 렌더링 애플리케이션은 여전히 ​​많은 기능을 구현하기 위해 API에 의존하고 있습니다. 이는 더 빠른 개발, 제공 업체의 특정 전문 분야의 전문 분야, 법률 및 기타 규정 준수 문제에 대한 책임을 오프로드하는 등을 활용할 수 있기 때문입니다. 이 경우 서버 측 렌더링 된 버전은 Jamstack 버전보다 다시 의존적이거나 의존적이지 않습니다. 응용 프로그램이 주로 내부 또는 수제 솔루션에 의존하는 경우 상황이 다를 수 있습니다.

오해 3 : 컨텐츠를 편집하기가 어렵습니다

Kev Quirk, "정적 웹 사이트 생성기를 사용하지 않는 이유"기사에서 :

Linux 상자에 SSH를 사용한 다음 VIM의 기사를 편집 해야하는 것은 모바일 쓰기와 관련하여 입력에 매우 높은 장벽 인 것 같습니다. 당신이 좋아하든 아니든, 오늘날의 세계는 모바일 우선이므로 모바일 쓰기는 쉬워야합니다.

이 문제는 과거에 정적 웹 사이트의 유산 인 것 같습니다. 분명히, 웹 사이트 콘텐츠를 편집하기 위해 Linux 상자를 입력하는 SSH가 필요하지 않습니다. 완전 무료 및 오픈 소스부터 대기업에 컨텐츠를 제공하는 상용 제품에 이르기까지 다양한 헤드리스 CMS 옵션이 있습니다. 그들이 제공하는 편집 기능은 전통적인 CMS와 비슷합니다 (이전에 대해 이야기했습니다). 요점은 블로그 측면 프로젝트에서도 Markdown, Yaml 또는 JSON 파일을 수동으로 편집 할 이유가 없다는 것입니다. 이 모든 부분을 어떻게 연결하는지 잘 모르시겠습니까? 우리도 해결책이 있습니다!

합리적인 비판은 헤드리스 CMS와 빌드 프로세스가 편집중인 컨텐츠와 웹 사이트의 변경 사이에 연결이 끊어 질 수 있다는 것입니다. 출판 전 또는 복잡한 빌드 미리보기 프로세스가없는 라이브 웹 사이트에 대한 변경의 영향을 정확하게 미리 보는 것은 어렵습니다. 생태계는이 문제를 해결하고 있습니다. Stackbit (내가 일하는 곳)과 같은 회사는이 프로세스를 원활하게 만드는 도구를 구축하고 있습니다.

우리는이 문제를 해결하기 위해 최선을 다하는 유일한 사람이 아닙니다. 다른 솔루션으로는 Tinacms 및 Gatsby Preview가 있습니다. Jamstack의 Wix와 같은 도구에서 Wysiwyg 편집의 단순성을 구현하려고합니다.

4 : Jamstack의 SEO는 어렵습니다

Kym Ellis, "Jamstack이 마케팅의 의미"기사에서 :

플러그인 개념을 포기하고 "HTML"Jamstack 웹 사이트를 선택한다고해서 기능을 포기하거나 갑자기 웹 사이트 및 콘텐츠를 관리하기 위해 프론트 엔드 개발자와 같은 코딩을 배워야한다는 의미는 아닙니다.

나는이 문제가 최근 몇 년 동안 자주 발생하는 것을 보지 못했고, SEO와 관련된 메타 데이터를 관리 할 때 YAML 기반 프론트 매스터의 수동 편집과 관련된 메타 데이터를 관리 할 때 대부분 정적 웹 사이트 시대의 유산 비판이라고 생각합니다. 사람들은 SEO를 올바르게 수행하는 것이 지루하고 유지하기가 어려울 수 있다고 걱정합니다. 특히 각 생성 된 고유 한 페이지에 다른 메타 데이터를 주입하거나 JSON-LD와 같은 구조화 된 데이터를 생성하려면 검색 목록을 향상시키는 데 필수적입니다.

Jamstack의 컨텐츠 관리 발전은 종종 SEO 메타 데이터 유지의 복잡성을 해결합니다. 또한, 페이지가 사전 렌더링되기 때문에 필요한 메타 데이터가 존재한다면 사이트 맵을 추가하고 JSON-LD를 추가하는 것은 비교적 간단합니다. 사전 렌더링을 사용하면 인덱싱 웹 사이트가 필요한 검색 엔진 (예 : Google)을 쉽게 만들 수 있으며 CDN과 결합되어 웹 사이트 순위를 향상시키는 성능 벤치 마크를 쉽게 달성 할 수 있습니다.

기본적으로 Jamstack은 "Technical SEO"에 능숙하며 컨텐츠 편집기에게 키워드 및 기타 메타 데이터를 제공합니다. Jamstack과 SEO에 대한보다 포괄적 인 이해를 위해서는 Bejamas의 Jamstack SEO 가이드를 확인하는 것이 좋습니다.

5 : Jamstack에는 많은 JavaScript 프레임 워크가 필요합니다

"Jamstack"의 장점을 장려하는 아름다운 웹 사이트는 최신 프레임 워크에 집착하는 일반 웹 사이트를 경영진에게 판매하려고하면 매우 유용합니다.

- Jdietrich, 해커 뉴스

최근 Jamstack은 프론트 엔드 JavaScript 프레임 워크와 동의어가 된 것 같습니다. 실제로, 가장 유명한 솔루션 중 다수는 Gatsby (React), Next.js (React), Nuxt (Vue), Vuepress (Vue), Gridsome (Vue) 및 Scully (Angular)를 포함한 프론트 엔드 프레임 워크에 의존합니다. 이것은 Jamstack의 "J"에 대한 혼란으로 인해 악화 된 것 같습니다. JavaScript의 약자이지만 모든 Jamstack 솔루션이 JavaScript 기반이라는 의미는 아니며 NPM 또는 JavaScript 프레임 워크가 모두 필요하다는 의미는 아닙니다.

실제로, 가장 널리 사용되는 가장 많이 사용되는 많은 도구는 JavaScript, 특히 Hugo (Go), Jekyll (Ruby), Pelican (Python) 및 최근에 출시 된 Bridgetown (Ruby)으로 제작되지 않았습니다. 동시에 Eleventy와 같은 도구는 JavaScript로 제작되었지만 JavaScript 프레임 워크에 의존하지 않습니다. 이러한 도구 중 어느 것도 JavaScript 프레임 워크 사용을 방해하지 않지만 필요하지 않습니다.

여기서 요점은 JavaScript 프레임 워크를 포기하거나 도구를 사용하지 않는 것입니다. 이들은 많은 개발자들이 성공적으로 사용하는 훌륭한 도구입니다. JavaScript 프레임 워크는 매우 복잡한 작업을 단순화 할 수있는 매우 강력한 도구가 될 수 있습니다. 여기서 요점은 Jamstack을 사용하기 위해 JavaScript 프레임 워크를 요구한다는 아이디어가 잘못되었다는 것입니다. Jamstack은 460 스타일을 가지고 있습니다!

우리가 개선 할 수있는 곳

그게 사실인가요? Jamstack은 모든 것이 완벽 할뿐만 아니라 매우 쉽습니다. 불행히도. Jamstack은 많은 합리적인 비판을 가지고 있습니다.

간단

Sebastian de Deyne, 기사에서 "Jamstack을 다루고 나서 생각하고 질문 할 것":

내 경험상 Jamstack (JavaScript, API 및 Tags)은 더 이상 좋지 않을 때까지 훌륭합니다. 언젠가는 동적 콘텐츠를 추가해야 할 때, 오늘은 항상 온다. 나는 머리를 긁기 시작한다.

솔직히 말해서 Jamstack을 시작하는 것은 쉽지 않습니다. 물론 정적 웹 사이트 생성기를 사용하여 블로그 나 간단한 웹 사이트를 구축하는 것은 특히 어렵지 않을 수 있습니다. 그러나 역동적 인 기능을 갖춘 실제 웹 사이트를 구축하려고하면 상황이 빠르게 복잡해집니다.

일반적으로 작업을 완료하기 위해 많은 옵션을 발견하여 장단점을 어렵게 만듭니다. Jamstack의 가장 좋은 측면 중 하나는 규범이 아니지만 접근 할 수없는 것처럼 보이게하여 복잡한 작업에 적합하지 않을 수 있다는 인상을 남길 수 있다는 것입니다.

바인딩 서비스

이러한 역동적 인 기능을 실제로 구축하기 시작하면 웹 사이트가 다양한 서비스 및 API에 의존 할 수 있습니다. 컨텐츠를 얻으려면 Headless CMS에 전화를 걸고 API의 서버리스 기능을 호출하여 지불 거래를 수행하고 Algolia와 같은 검색 서비스 등을 수행하는 것은 매우 복잡한 작업이 될 수 있습니다. 각 섹션에는 일반적으로 자체 대시 보드 및 API/SDK 업데이트가 있다는 사실을 추가하면 상황이 훨씬 복잡해집니다.

그렇기 때문에 Stackbit과 같은 서비스와 Redwoodjs와 같은 도구가 Jamstack 웹 사이트 뒤에 다른 부분을 모아서 해당 부품을보다 쉽게 ​​구축하고 관리 할 수 ​​있기 때문에 중요하다고 생각합니다.

프레임 워크의 과도한 사용

제 생각에, 현대 프론트 엔드 개발에서 JavaScript 프레임 워크에 대한 우리의 의존성은 최근에 의문의 여지가 많았습니다. Tim Kadlec의 최근 기사에서 알 수 있듯이 트레이드 오프가 있습니다. 앞에서 말했듯이 Jamstack에서 작업하기 위해 JavaScript 프레임 워크가 필요하지 않습니다.

그러나 이러한 인상은 많은 Jamstack 도구가 JavaScript 프레임 워크에 의존하고 Jamstack을 가르치는 방식은 주로 프레임 워크 사용에 중점을두기 때문에 발생합니다. 많은 Jamstack 개발자가 JavaScript 프레임 워크에 익숙하며 각 도구를 가르치는 것은 불가능하므로 원하는 도구를 선택하는 것은 불가능합니다. 그럼에도 불구하고, 나는 개인적으로 Jamstack의 장기적인 성공은 유연성에 달려 있다고 생각합니다. (위의 단순성을 언급했지만) JavaScript 프레임 워크 사용 여부에 관계없이 다양한 솔루션을 보여줄 필요가 있습니다.

다음에 갈 곳

와우, 당신은 그것을했다! 나는 내가 할 말이 많을 것임을 알고 있습니다. 아마도 내가 글을 쓰기 시작했을 때 깨달았을 것보다 더 많은 것을 알고 있습니다. 그래서 나는 긴 결론으로 ​​당신을 괴롭히지 않을 것입니다.

서버 측 렌더링을 통해 Jamstack을 언제 그리고 언제 선택하지 않을지에 대한 좋은 기사를 찾고 있다면 Chris Coyier의 최근 기사 STATIC인지 확인하십시오. 》.

위 내용은 Jamstack에 대한 5 가지 신화의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!