JAMstack 기초: 무엇을, 무엇을, 어떻게

우리는 웹에서 한계를 뛰어 넘는 것을 좋아하므로 새로운 것을 시도하기로 결정했습니다. JavaScript, API 및 마크업을 기반으로 하는 새로운 웹 스택인 JAMstack에 대해 들어본 적이 있을 것입니다. 하지만 이것이 워크플로에 어떤 의미가 있으며 언제 프로젝트에서 의미가 있습니까?

Smashing Membership의 일환으로 매주 라이브 웨비나 시리즈인 Smashing TV 를 운영하고 있습니다. 보잘 것 없습니다. 업계에서 존경받는 실무자가 운영하는 라이브 Q&A가 포함된 실용적이고 실행 가능한 웨비나입니다. 실제로 Smashing TV 일정은 이미 꽤 빡빡해 보이며 Smashing Members에게는 녹음과 함께 무료입니다. 분명히 .

우리는 Phil Hawksworth에게 JAMStack이 실제로 무엇을 의미하는지, 언제 그것이 의미가 있는지, 그리고 이것이 도구 및 프론트 엔드 아키텍처에 어떤 영향을 미치는지 설명하는 웨비나를 진행하도록 요청했습니다. 이제 1시간 길이의 웨비나도 이용할 수 있습니다. 다가오는 SmashingConf Toronto(6월 25-26일)의 공동 MC로 Phil을 환영하고 올해 7월 9-10일에도 공동 주최하는 JAMStack_conf London을 운영하게 되어 매우 기쁩니다. 자, 들어가 봅시다!

Phil Hawksworth: 훌륭합니다. 좋습니다. 그럼 본격적으로 시작하겠습니다. 아주 간단한 인사의 방법으로, 나는 이미 인사를 했습니다. Scott이 저에게 좋은 소개를 해주었습니다. 하지만 네, 저는 현재 Netlify에서 일하고 있으며 그곳에서 개발자 경험 팀에서 일하고 있습니다. Q&A 시간이 충분하기를 바랍니다. 하지만 Scott이 언급한 것처럼 그곳에서 질문할 기회가 없거나 질문을 할 기회가 없다면 Twitter에서 저에게 직접 ping을 보낼 수 있습니다. 제 이름은 Phil Hawksworth입니다. 따라서 언제든지 JAMstack이나 Twitter에서 무엇이든 확실히 질문할 수 있습니다.

필 혹스워스: 하지만 저는 시간을 거슬러 올라가 저에게 매우 강하게 반향을 불러일으키는 이 인용문으로 오늘 시작하고 싶습니다. 이것은 크리에이티브 커먼즈와 개방형 웹에 많은 공헌을 한 훌륭한 Aaron Schwartz의 인용문입니다. 그는 2002년에 자신의 블로그에 이것을 썼습니다. 그는 이렇게 말했습니다. AOL 서버, Postgres 및 Oracle이 설치됩니다.” AOL 서버를 찾아보니 당시에 오픈 소스 웹 서버였음을 상기시켜야 했습니다.

필 혹스워스: 하지만 이것은 저에게 정말 강하게 와 닿습니다. 나는 또한 블로그를 유지하기 위해 인프라를 유지하는 것을 원하지 않습니다. 그리고 그것이 그가 말한 것입니다. 그리고 그것은 자신의 블로그에 있는 이 블로그 게시물에 "구우고, 튀기지 마십시오"라는 제목으로 작성되었습니다. 그는 CMS를 구축한 사람이 최근에 사용하기 시작한 용어를 선택하고 있었고 그는 이 용어를 베이킹(Bake, Don't Fry)에 대해 대중화했습니다. 그가 여기서 말하는 것은 주문형 렌더링이 아닌 사전 렌더링이므로 사람들이 와서 요청할 때 주문형으로 튀기기보다는 미리 콘텐츠를 굽는 것입니다.

Phil Hawksworth: 사전 렌더링 및 렌더링에 대해 이야기할 때 이것이 의미하는 바는 마크업 생성에 대한 것입니다. 나는 때때로 일종의 서버 렌더나 동형 렌더링 또는 이러한 종류의 유행어에 대해 이야기하는 것에 대해 약간 자의식을 느낍니다. 몇 년 전 암스테르담에서 열린 Frontiers Conference에서 제가 서버에서 렌더링에 대해 이야기하고 있을 때 누군가가 저에게 “HTML 생성을 말씀하시는 겁니까? HTML을 출력하는 것뿐인가요?” 그리고 그것은 물론, 내가 의미하는 바입니다.

필 호크스워스: 하지만 이 모든 것은 스택을 단순화하는 데 큰 도움이 됩니다. 우리가 웹 사이트를 제공하는 스택에 대해 생각할 때; 저는 모든 것을 단순화하려고 노력하고 있으며 스택을 단순화하는 데 매우 열심입니다. 그리고 이것이 "JAMstack"이라는 이 기능의 핵심입니다. 저는 이것을 조금 설명하려고 합니다. JAMstack의 "JAM"은 JavaScript, API 및 마크업을 나타냅니다. 그러나 그것이 의미하는 바를 이해하는 데 도움이 되는 것만으로는 충분하지 않습니다. 도대체 그게 무엇을 의미하는 것일까요?

Phil Hawksworth: 음, 앞으로 30분 정도 후에 해보고 싶은 것은 그 정의를 좀 더 확장하고 JAMstack이 무엇인지에 대해 더 자세히 설명하고 싶은 것입니다. JAMstack의 영향과 의미에 대해 조금 이야기하고 싶고 JAMstack을 선택해야 하는 이유에 대해 생각해 보십시오. 그 과정에서 유용할 몇 가지 도구와 서비스를 언급하려고 하고, 여러분이 조사하고 싶어할 만한 몇 가지 리소스로 마무리하고 아마도 여러분을 얻기 위한 몇 가지 첫 번째 단계를 언급할 것입니다. 진행 중.

Phil Hawksworth: 다음 30분 동안의 계획입니다. 하지만 스택 단순화에 대한 이 개념으로 돌아가고 싶습니다. 이 작업에 참여하거나 나중에 이 비디오를 시청하기 위해 온 사람들이 JAMstack이 무엇인지에 대한 개념이 있을 수 있기 때문입니다. 완전히 새로운 용어일 수도 있고 그냥 궁금하실 수도 있습니다. 그러나 궁극적으로 이미 많은 스택이 있습니다. 웹 사이트를 제공할 수 있는 방법은 많이 있습니다. LAMP 스택이든 MAMP 스택이든, 아니면 MEAN 스택이든 간에 우리는 정말 오랫동안 다양한 유형의 인프라를 구축해 온 것 같습니다. 여기 화면에 떠다니는 무리가 있습니다. 그들 중 많은 수가 있습니다.

필 혹스워스: 그렇다면 도대체 왜 또 다른 것이 필요할까요? 글쎄요, JAMstack은 제가 언급했듯이 JavaScript/API/Markup입니다. 하지만 조금 더 설명을 하자면 JAMstack은 JavaScript/ API와 사전 렌더링된 마크업은 웹 서버 없이 제공됩니다. 이 마지막 지점이 일종의 차별화 요소이며, 어쩌면 좀 더 흥미롭고 독특하게 만들 수도 있습니다.

Phil Hawksworth: 웹 서버 없이 무언가를 제공한다는 이 개념은 마법처럼 들리거나 우스꽝스럽게 들립니다. 바라건대, 우리는 그 과정에서 무엇을 알아낼 것입니다. 그러나 이것에 대해 약간의 빛을 비추고 조금 더 자세히 설명하기 위해 때때로 우리가 생각하는 전통적인 스택 또는 웹에서 서비스를 제공하는 전통적인 방법과 비교하는 것이 유용합니다. 자, 잠시만 그렇게 합시다. 전통적인 스택에서 서비스를 받을 때 요청이 어떻게 생겼는지 살펴보겠습니다.

Phil Hawksworth: 이 시나리오에서 누군가가 웹 브라우저를 열고 페이지 보기를 요청했습니다. 그리고 그 요청이 CDN에 도달했을 수도 있지만 아마도 이 사이트를 소유한 사람들로서 우리가 호스팅하고 있는 다른 인프라에 영향을 미쳤을 가능성이 큽니다. 아마도 우리는 분명히 매우 인기 있고 성공적인 광경을 원하기 때문에 많은 부하에서 확장되도록 노력했을 것입니다. 그래서 아마도 로직이 포함된 로드 밸런서가 있을 것입니다. 이 로드 밸런서는 우리가 프로비저닝하고 구성하고 배포한 여러 웹 서버 중 하나에 해당 요청을 처리합니다. 이러한 서버가 여러 개 있을 수 있습니다.

Phil Hawksworth: 이 서버는 "자, 여기 템플릿이 있습니다. 데이터를 채워야 합니다."라고 말하는 논리를 실행합니다. 여러 데이터베이스 서버 중 하나에서 데이터를 가져와 일부 데이터를 조회하고 이를 웹 서버로 반환하고 로드 밸런서를 통해 다시 전달하는 뷰를 생성할 수 있습니다. 아마도 그 과정에서 CDN에 전화를 걸어 일부 자산을 CDN에 숨겼을 것입니다. CDN은 콘텐츠 전달 네트워크이므로 가능한 한 가까운 요청 서비스를 시도하고 받기 위해 인터넷에 분산된 시스템 네트워크입니다. 사용자에게 캐싱과 같은 것을 추가합니다.

Phil Hawksworth: 그래서 우리는 거기에 일부 자산을 숨길 수 있습니다. 그리고 궁극적으로 우리가 구축한 사이트를 경험하게 되는 사용자의 안구와 브라우저로 보기를 반환할 수 있습니다. 따라서 분명히 이는 지나치게 단순화하거나 기존 스택에서 요청을 처리하는 방법에 대한 매우 일반적인 관점입니다. 약간 다른 방식으로 서비스를 제공하는 JAMstack과 비교하면 이렇습니다.

Phil Hawksworth: 다시 동일한 시나리오에서 웹 브라우저에서 시작합니다. 페이지 보기를 요청하고 있으며 해당 페이지는 이미 CDN에 있습니다. 거기에서 정적으로 제공되므로 사용자에게 반환되고 브라우저로 돌아가면 완료됩니다. 따라서 분명히 매우 단순화된 보기이지만 곧바로 복잡성 측면에서 차이점을 볼 수 있습니다. 우리가 코드를 관리해야 하는 장소의 관점에서 보면, 깊이 있는 코드와 그 모든 다른 것들입니다. 따라서 저에게 JAMstack의 핵심 속성 중 하나는 CDN 또는 정적 파일 서버에서 직접 제공될 수 있는 사이트를 구축한다는 의미입니다. CDN은 로드를 처리하기 위해 배치할 수 있지만 궁극적으로 이것은 모든 종류의 정적 파일 서버, 일종의 정적 호스팅 인프라에서 직접 제공될 수 있습니다.

Phil Hawksworth: JAMstack은 일종의 복잡성을 줄일 수 있는 기회를 제공합니다. 다음 30분 동안 몇 번으로 다시 돌아올 다이어그램의 두 부분을 비교하는 것만으로도 복잡성을 줄이고 위험을 줄일 수 있는 기회임을 알 수 있습니다. 따라서 정적 자산을 제공하는 이점 중 일부를 즐길 수 있음을 의미합니다. 정적 자산이 무엇인지에 대해서는 잠시 후에 이야기하겠습니다. 하지만 당신은 이것을 보고 "글쎄요, 하지만 이것은 단지 정적 웹사이트의 새로운 이름이 아닙니까?"라고 생각할 수도 있습니다. 내가 "정적으로 서비스를 제공할 것입니다."라고 말할 때 이는 합리적인 수준입니다.

필 혹스워스: 하지만 다시 그 이야기로 돌아가고 싶습니다. 나는 그것에 대해 조금 더 이야기하고 싶지만, 우선, 일종의 스택 개념에 대해 이야기하고 싶습니다. 스택이란 도대체 무엇입니까? 그리고 저는 스택을 웹사이트나 애플리케이션을 제공하는 기술 레이어라고 생각합니다. 그리고 우리는 빌드 파이프라인이나 개발 프로세스에 대해 이야기하는 것이 아니라 확실히 사이트에 서비스를 제공하는 방식이 개발 방식과 배포 방식 등에 큰 영향을 미칠 수 있습니다.

Phil Hawksworth: 하지만 여기에서는 실제로 웹사이트와 애플리케이션을 사용자에게 제공하는 기술 스택, 기술 계층에 대해 이야기하고 있습니다. 자, 조금 더 비교를 해보겠습니다. 잠시 LAMP 스택에 대해 이야기해 보겠습니다.

Phil Hawksworth: LAMP 스택은 HCP 라우팅 및 정적 자산 제공과 같은 작업을 수행하기 위해 Apache 웹 서버로 구성되어 있음을 기억할 수 있습니다. PHP, 일부 사전 처리, 그래서 꽤 하이퍼 텍스트 처리; 로직을 적용하고 템플릿에 대한 뷰를 구축하고 무엇을 가지고 있는지도 모릅니다. 그리고 내 NISQL에 의해 데이터에 약간의 액세스 권한이 있습니다. 그런 다음 LINUX는 그 모든 것 아래에 있는 운영 체제이며 모든 호흡을 유지합니다. 이 웹 서버로 개념적으로 함께 마무리할 수 있습니다. 그리고 우리는 웹사이트를 제공하기 위해 함께 앉아 있는 이러한 서버 중 다수를 가질 수 있습니다.

Phil Hawksworth: 그것은 일종의 전통적인 LAMP 스택의 모습입니다. JAMstack과 비교해 보면 중요한 변화가 있습니다. 여기서 우리는 운영 체제에 대해 생각하고 웹 사이트를 제공하기 위해 로직을 실행하는 방법에 대해 생각하기보다는 실제로 한 단계 더 올라가고 있습니다. 여기서 우리는 이러한 것들을 정적으로 제공할 것이라고 가정합니다. 따라서 ACP 라우팅을 수행하고 정적 서버에서 자산을 제공합니다. 그것은 합리적으로 할 수 있습니다. 우리는 수년에 걸쳐 정적 웹 사이트 또는 정적 자산을 제공하는 방법을 구축하는 데 매우 능숙했습니다.

Phil Hawksworth: 이것은 CDN일 수 있으며 잠시 후에 이에 대해 다시 이야기하겠습니다. 그러나 우리의 관심 영역은 브라우저에서 더 많이 발생하고 있습니다. 여기에서 마크업이 전달되고 구문 분석됩니다. 이것은 JavaScript가 실행될 수 있는 곳이며 이것은 브라우저에서 발생합니다. 여러 면에서 브라우저는 현대 웹의 런타임이 되었습니다. 서버 인프라 자체에 런타임이 있는 대신 이제 사용자와 브라우저에 더 가까운 수준으로 이동했습니다.

Phil Hawksworth: 데이터 액세스에 관해서는 아마도 외부 API를 통해 발생하고 JavaScript를 통해 이러한 외부 API를 호출하여 서버 액세스를 얻거나 API를 브라우저 API로 생각할 수 있으며 JavaScript와 상호 작용할 수 있습니다. 브라우저에서 바로 사용할 수 있습니다.

Phil Hawksworth: 어느 쪽이든, 여기서 JAMstack에 대한 핵심은 사전 렌더링된 것에 대해 이야기하고 있다는 것입니다. 정적으로 제공되고 브라우저 API, JavaScript를 사용하기 위해 브라우저에서 점진적으로 향상될 수 있습니다. , 그리고 당신은 무엇을 가지고 있습니다.

Phil Hawksworth: 자, 여기에서 간단히 비교를 해 보겠습니다. 다시 말하지만, JAMstack이 브라우저 수준으로 이동했음을 다시 한 번 말씀드리고 싶습니다. 그리고 왼쪽에 LAMP 스택이 있고 오른쪽에 JAMstack이 있는 이 다이어그램의 양면을 보면 LAMP 스택으로 무언가를 구축할 때도 여전히 마크업을 출력합니다. 우리는 여전히 JavaScript를 출력하고 있습니다. 우리는 여전히 API에 액세스하고 있을 수 있습니다. 따라서 여러 면에서 JAMstack은 이전에 구축한 것의 하위 집합과 거의 같습니다.

Phil Hawksworth: 저는 JAMstack이 사이트를 제공하는 데 필요한 일련의 도구와 기술을 보장하기 때문에 보증된 스택이라고 종종 이야기하곤 했습니다. 그러나 어느 쪽이든, 그것은 요청 시 서버에서 로직을 실행하고 수행할 필요가 없는 일종의 사이트를 제공하는 훨씬 단순화된 방법입니다.

Phil Hawksworth: 이것은 많은 일을 할 수 있습니다. 이것은 일종의 배포를 단순화할 수 있으며, 때때로 이 다이어그램을 다시 언급하겠습니다. 코드와 사이트를 배포하는 방법에 대해 생각해보면 첫 배포부터 전체 개발 수명 주기, 웹 사이트 수명 내내 모든 배포에 대해 수행할 수 있습니다. 기존 스택에서는 해당 다이어그램의 모든 상자에 대한 논리와 내용을 변경해야 할 수 있습니다.

Phil Hawksworth: 반면에 JAMstack에서 배포에 대해 이야기할 때 CDN으로 물건을 가져오고 정적 서버로 물건을 가져오는 것이 배포에 수반되는 것입니다. 빌드, 어디에서나 실행할 수 있는 빌드를 실행하는 논리의 종류입니다. 웹 서버를 호스팅하는 동일한 환경에서 실행할 필요가 없습니다. 사실, 그렇지 않습니다! JAMstack에 대한 키를 시작합니다. 우리는 이러한 정적 자산을 제공하는 요청 시간에 발생하는 일과 빌드 시간에 발생하는 일을 구분합니다. 이는 빌드를 위해 실행한 다음 배포에 대한 논리가 될 수 있습니다.

Phil Hawksworth: 따라서 이러한 종류의 분리는 핵심 사항이며 나중에 다시 언급하겠습니다. 우리는 정적 파일을 제공하는 데 매우 능숙하며 CDN으로 항목을 가져오거나 파일 시스템(파일 서버)으로 항목을 가져오는 것은 지난 몇 년 동안 엄청난 발전을 보아온 곳입니다. 이제 우리가 이것을 잘 수행하는 데 도움이 될 수 있는 많은 도구와 프로세스가 있습니다. 정적 자산을 잘 제공하고 해당 환경에 대한 빌드를 가져오는 워크플로를 제공할 수 있는 몇 가지 서비스를 호출하기만 하면 Azure, AWS 및 Google Cloud와 같은 대규모 클라우드 인프라 제공업체를 상상할 수 있는 일반적인 용의자입니다.

Phil Hawksworth: 하지만 다른 사람들도 있습니다. 따라서 오른쪽 상단에 있는 서비스는 Surge라는 서비스로 몇 년 동안 등장했습니다. 이를 통해 빌드 환경에서 명령을 실행하고 자산을 호스팅 환경에 배포할 수 있습니다. 다음 아래에 있는 Netlify는 제가 일하는 곳이며 우리는 거의 같은 일을 하지만 다른 자동화도 있습니다. 다른 시간에 들어갈 수 있습니다. 그리고 맨 아래에 있는 또 다른 정적 호스팅 환경 사이트인 Now.

Phil Hawksworth: 따라서 이를 수행하기 위한 다양한 옵션이 있으며 이 모든 공간은 가능한 한 빨리 CDN에 도달하기 위한 다양한 도구를 제공합니다. 저희가 할 수 있는 가장 원활한 방식으로 귀하의 사이트를 배포합니다. 그리고 그들 모두는 로컬에서 무언가를 실행한다는 원칙을 기반으로 구축한다는 공통점이 있습니다. 저는 종종 정적 사이트 생성기를 빌드에서 실행할 수 있는 것으로 생각합니다. 이 생성기는 실행할 때 콘텐츠 및 템플릿, 아마도 다른 서비스의 데이터를 가져와 정적으로 제공할 수 있는 것을 출력합니다.

Phil Hawksworth: 정적 서버에서 로컬로 미리 볼 수 있습니다. 모든 로컬 개발 환경에서 수행할 수 있는 간단한 작업을 수행한 다음 이를 배포하는 프로세스는 호스팅 환경으로 가져오고 이상적으로는 일종의 확장을 위해 CDN으로 내보내는 것입니다. 따라서 이러한 종류의 기반을 마련하여 JAMstack 사이트와 관련하여 일반적인 오해에 대해 말씀드리고자 합니다. 그리고 JAMstack 사이트를 JavaScript, API 및 마크업으로 설명하는 것으로 이것을 열어서 나 자신에게 어떤 호의도 베풀지 않았습니다. 일반적인 오해는 모든 JAMstack 사이트가 JavaScript와 API, 그리고 마크업이어야 한다는 것입니다. 하지만 우리가 간과한 것은 이 세 가지를 모두 사용할 필요가 없다는 것입니다. , 선택 사항입니다. 우리는 이것을 원하는 만큼 많이 또는 적게 사용할 수 있습니다. LAMP 스택 사이트가 반드시 데이터베이스에 도달할 필요가 없는 것과 같은 방식으로. 이제 저는 과거에 Linux 머신에서 Apache 서버가 제공하는 것을 구축했으며 PHP를 사용하고 있지만 데이터베이스를 사용하지 않았으며 스택 이름을 변경하기 시작하지도 않았습니다. 그것을 위해 반드시.

Phil Hawksworth: JAMstack 사이트가 무엇인지 생각해보면 여러 가지가 있을 수 있습니다. Jekyll과 같은 정적 사이트 생성기로 구축되어 JavaScript가 없는 사이트를 구축하기 위해 YAML 파일에서 콘텐츠를 가져와서 API에 전혀 도달하지 않으며 GitHub 페이지와 같은 곳에서 제공합니다. 또는 JAMstack 사이트가 될 것입니다. 또는 Gatsby와 같은 정적 사이트 생성기를 사용하고 있을 수 있습니다. 이 생성기는 오히려 Jekyll용 Ruby 환경에 있습니다. 이제 이것은 React 에코시스템에 구축된 JavaScript 정적 사이트 생성기입니다.

Phil Hawksworth: 콘텐츠를 다시 가져오는 것일 수 있으며 Markdown 파일을 구성하고 있습니다. API, GraphQL의 API에 대한 호출을 통해 이를 풍부하게 할 수 있습니다. 브라우저에서 템플릿을 채우는 JavaScript 수화 작업과 같이 브라우저에서 작업을 수행할 수 있습니다. 그리고 그것은 Amazon S3에서 제공될 수 있습니다. JAMStack 사이트인가요? 예, 절대적으로!

Phil Hawksworth: Go!로 구축된 다른 정적 사이트 생성기 Hugo로 이동합니다. 다시 말하지만, Markdown 파일에서 콘텐츠를 구성하고 JavaScript를 사용하여 브라우저에서 상호 작용을 추가할 수 있습니다. 외부 API를 호출하지 않고 Google Cloud에서 호스팅할 수 있습니다. 잼스택인가요? 전적으로! 알다시피, 나는 여기에서 테마를 만들고 있습니다. 이제 View 에코시스템에 구축된 또 다른 정적 사이트 생성기인 Nuxt와 같은 것을 사용합니다. 다른 인접 파일에서 콘텐츠를 가져오는 것일 수 있습니까? 다시 말하지만, 우리는 브라우저에서 JavaScript 상호 작용을 사용하고 있을 수 있습니다. 아마도 API를 호출하여 전자 상거래와 같은 작업을 수행하고 다른 정적 사이트를 제공할 수 있습니다. Netlify와 같은 또 다른 호스팅 인프라는 JAMstack입니까? 예, 그렇습니다!

Phil Hawksworth: 하지만 우리는 저울의 이쪽 끝으로 갈 수도 있습니다. 그리고 우리가 직접 만든 수제 자바스크립트를 장인의 손으로 만든 진보적인 수제 웹 앱에 대해 생각해 보십시오. 우리는 그것을 webpack으로 포장하고 있습니다. 아마도 JavaScript 웹 토큰을 사용하고 API를 호출하여 인증을 수행하고, 다른 브라우저 API와 상호 작용하고, Azure에서 호스팅할 수 있습니다. 네, JAMstack도 마찬가지입니다!

Phil Hawksworth: 그리고 아시다시피, 이 모든 것, 그리고 더 많은 것들이 JAMstack으로 간주될 수 있습니다. 왜냐하면 그것들은 모두 공통적으로 하나의 속성을 공유하고 그 중 어느 것도 오리진 서버와 함께 제공되지 않기 때문입니다. 그들 중 누구도 요청 시간에 논리를 수행하는 서버에 도달할 필요가 없습니다. 이것들은 정적 자산으로 제공되고 나중에 JavaScript 및 API 호출로 강화됩니다.

Phil Hawksworth: 다시 말하지만 JAMstack은 CDN에서 직접 제공될 수 있음을 의미합니다. 그래서 저는 이것의 영향과 의미를 몇 가지만 언급하고자 합니다. 왜 우리가 이것을 하고 싶어할까요? 글쎄요, 첫 번째 개념은 보안에 관한 것이며 여기에서 공격에 대한 노출 영역이 크게 줄어듭니다. (이 이전 다이어그램으로 다시 돌아가서) 공격에 대처해야 할 수 있는 장소를 생각한다면 로드 밸런서, 웹 서버, 데이터베이스 서버와 같은 것을 보호해야 합니다. 이 모든 것들이 어떤 종류의 공격, 그리고 실제로 CDN에 의해 ​​침투할 수 없도록 해야 합니다.

Phil Hawksworth: 이 퍼즐에서 더 많은 조각을 꺼낼 수 있다면 공격할 수 있는 장소와 확보해야 하는 장소가 줄어듭니다. 공격할 움직이는 부품이 거의 없다는 것은 매우 가치 있는 일입니다. Netlify에서는 자체 CDN을 운영하므로 이를 통해 들어오는 트래픽을 모니터링할 수 있는 호사를 누리며 Netlify에서 호스팅되는 모든 사이트, 상상할 수 있는 모든 JAMstack 사이트, 그 중 어느 것도 완전히 분리되어 있기 때문에 WordPress 관리 페이지가 있어야 합니다. WordPress 관리자는 없지만 엄청난 양의 트래픽이 발생하여 WP 관리자와 같은 항목을 탐색하고 침입 경로를 찾고 공격 벡터를 찾습니다.

Phil Hawksworth: 나는 Kent C. Dodds가 한 일들 중 일부를 정말 사랑합니다. React 커뮤니티에 익숙하신지 모르겠습니다. 아마도 과거에 Kent C. Dodds를 만났을 것입니다. 그는 WordPress를 사용하지 않지만 여전히 이 URL인 WPAdmin을 라우팅합니다. 나는 그가 그것을 YouTube의 Rick Roll 비디오로 라우팅하곤 했다고 생각합니다. 그는 확실히 그것을 조사하러 간 사람들을 트롤링했습니다. 그러나 요점은 그런 식으로 일을 분리하고, 요청 시간에 발생하는 일에서 발생하는 일을 이동하고 시간을 구축함으로써 노출을 크게 줄일 수 있다는 것입니다. 요청 시간에 움직이는 부품이 없습니다. 움직이는 부품은 모두 빌드 시 완전히 분리됩니다. 잠재적으로 완전히, 음, 필연적으로 완전히 다른 인프라에서.

Phil Hawksworth: 이것은 물론 성능에도 영향을 미칩니다. 여기에서 우리의 오랜 친구로 돌아가서 여기에서 스택 전체에 걸쳐 성능을 개선하고 시도하고 싶을 수 있습니다. 이러한 다른 위치에서 실행해야 하는 로직이 있을 때입니다. 이것이 전통적인 스택에서 자주 발생하는 방식은 성능을 향상시키기 위해 레이어를 추가하기 시작하고 정적 레이어를 추가하는 것입니다. 즉, 정적인 것처럼 행동할 수 있는 방법을 시도하고 찾으십시오. 속도를 높이기 위해 스택의 각 수준에서 해당 논리를 수행할 필요가 없습니다. 그래서 우리는 인프라 전반에 걸쳐 캐싱과 같은 것을 도입하기 시작했습니다. 우리가 찾을 수 있는 명백한 장소는 웹 서버에서 그 논리를 수행하기 보다는 해당 논리를 수행하지 않고 즉시 무언가를 제공하기를 원합니다.

필 호크스워스: 그래서, 그것은 일종의 유사 정적(pseudo-static)이 되는 단계와 같습니다. 마찬가지로 데이터베이스 서버에서 캐시 com 쿼리에 캐싱 레이어를 추가하려고 합니다. 잔액이 적은 경우에도 전체 CDN을 캐시로 생각할 수 있습니다. 그러나 전통적인 스택에서는 모든 것이 캐시되지 않기 때문에 해당 캐시를 관리하는 방법을 알아내야 합니다. 그래서, 거기에 대해 약간의 논리가 있을 것입니다. 동적으로 채워야 하는 것과 캐시할 수 있는 것. 그리고 JAMstack 모델은 모든 것이 캐시됩니다. 배포가 완료된 시점부터 모든 것이 캐시되므로 완전히 다르게 생각할 수 있습니다.

필 혹스워스( Phil Hawksworth): 이것은 스케일링에 대한 일종의 힌트를 주기 시작합니다. 그리고 규모에 따라 대규모 트래픽 로드를 처리하는 방법에 대해 이야기하고 있습니다. 기존 스택은 확장을 위해 인프라를 추가하기 시작합니다. 예, 캐싱합니다. 우리는 기존 스택에 배치하기 시작했습니다. 어느 정도 도움이 될 것입니다. 일반적으로 발생하는 일은 많은 양의 트래픽을 처리하기 위해 인프라 확장을 시작하고 더 많은 서버를 추가하고 이러한 요청을 처리하기 위해 더 많은 부품을 추가하기 시작합니다. 기술 아키텍처를 수행하는 사람에게는 골칫거리가 될 것입니다. 그것은 확실히 저를 위한 것이었고, 이것이 바로 모든 것이 기본적으로 규모를 처리하고 성능을 바로 처리하도록 설계된 CDN에서 모든 것이 제공된다는 것을 알고 있는 JAMstack 접근 방식을 수행하는 데 훨씬 더 기울기 시작한 이유입니다. .

Phil Hawksworth: 그래서 저는 개발자 경험과 이것이 미칠 수 있는 영향에도 고개를 끄덕이고 싶습니다. 이제 개발자 경험이 사용자 경험을 능가하는 것으로 간주되어서는 안 됩니다. 하지만 좋은 개발자 경험은 마찰을 줄이고 개발자가 훌륭한 사용자 경험을 구축하는 데 훨씬 더 나은 작업을 수행할 수 있게 해줄 수 있다고 믿습니다!

Phil Hawksworth: 따라서 개발자 경험이 어디에 있고 개발자가 관심을 가져야 하는 영역이 어디에 있는지 생각할 때 전통적인 스택에서 이러한 모든 인프라의 일부와 이들이 모두 함께 작동하는 방식. JAMstack 세계에서 실제로 우리가 말하는 것은 여기 하단에 있는 이 상자입니다. 빌드와 빌드를 실행하는 방법, 배포를 자동화하여 처음에 서비스를 제공하는 방법은 무엇입니까? 그리고 좋은 점은 JAMstack 모델에서 해당 빌드에서 수행하는 작업은 전적으로 사용자에게 달려 있다는 것입니다.

Phil Hawksworth: 정말 잘 정의된 문제 영역입니다. 궁극적으로 CDN에서 직접 제공할 수 있는 것을 구축하려고 하기 때문입니다. 원하는 도구를 사용하여 무언가를 미리 렌더링하고 싶을 때: Ruby, Python, JavaScript, Go 또는 PHP로 구축된 정적 사이트 생성기이든, 자유롭게 선택할 수 있습니다. 따라서 작업하기에 훨씬 더 좋은 환경을 만들 수 있습니다. 또한 JAMstack 사이트의 실제 속성은 변경 불가능한 원자적 배포로 훨씬 더 쉽게 제공될 수 있다는 점에서 진정한 개발자 자신감을 가질 수 있는 기회를 만듭니다.

Phil Hawksworth: 그리고 저는 잠시 슬라이드에서 벗어나 이것이 의미하는 바를 설명하고 싶습니다. 왜냐하면 불변 배포와 원자적 배포는… 내가 할 일은 내 브라우저로 이동하는 것입니다. 이제 ... 사실, 저는 잠시 돌아가겠습니다. 하게 해주세요... 그냥 하세요.

필 혹스워스: 여기 있습니다. 이것은 더 쉬울 것입니다. 페이지로 바로 이동합니다. 이제 Scott, Scott, 내 브라우저가 표시되지 않으면 알려줄 것입니다. 이제 모든 사람이 내 브라우저를 볼 수 있다고 가정합니다.

Scott: 모든 것이 좋아 보입니다.

필 혹스워스: 훌륭합니다! 매우 감사합니다!

Phil Hawksworth: 여기에서 제가 하는 일은 Netlify를 서비스의 예로 사용하고 있다는 것입니다. 그러나 이것은 정적으로 호스팅할 수 있는 사이트에 공통적인 속성입니다. 따라서 변경할 수 없는 배포에 대해 이야기할 때 우리가 의미하는 바는 오히려 각 코드 배포가 인프라의 여러 다른 부분에 영향을 미치고 많은 것을 변경해야 한다는 것입니다. 여기서 우리는 사이트의 상태를 변경하지 않습니다. 서버. 발생한 모든 배포에 대해 사이트의 완전히 새로운 인스턴스를 만들고 있습니다. 사이트가 정적 자산의 모음이기 때문에 그렇게 할 수 있습니다.

Phil Hawksworth: 여기, 내 웹 사이트에서 발생한 배포를 보고 있습니다. 내가 대접을 해줄게. 당신이 있습니다, 그것이 보이는 것입니다. 그것은 단지 블로그일 뿐이며 특별히 놀랍거나 흥미진진해 보이지는 않습니다. 이것은 정적으로 생성된 블로그이지만 제가 여기에 있는 것은 CDN에서 제공되는 정적 자산의 모음이기 때문에 발생한 모든 배포가 영구적으로 존재한다는 것입니다. 이제, 나는 내 역사가 나를 데려갈 수 있을 때까지 되돌아갈 수 있고, 돌아가서 사이트를 볼 수 있습니다. 그것이 다시 있었던 것처럼... 이것이 언제였습니까? 이것은 2016년 8월이었습니다. 그리고 그것이 일련의 정적 자산 덕분에 영구적으로 존재하는 자체 URL에서 이것을 호스팅할 수 있습니다. 그리고 내가 원하기만 하면 내가 들어가서 게시하기로 결정할 수 있습니다. 전개.

Phil Hawksworth: 이제 제 웹사이트를 보고 있는 모든 사람이 여기에서 제 웹사이트로 돌아가서 해당 페이지를 새로고침하면 이전에 있던 자산으로 CDN에서 직접 서비스를 제공하고 있습니다. 이제 다시 탐색할 수 있습니다. 여기, 당신은 볼 수 있습니다. 이봐, 나는 이것에 대해 강타하고 있었고, 동형 렌더링과 같은 끔찍한 용어를 사용하고 있었고 2016년에 JAMstack에 대해 이야기하고 있었습니다. 그래서 이것이 지금 제 사이트에서 라이브로 제공되고 있습니다. 다시 말하지만, 영원히 지속되는 상호 배포가 있기 때문입니다. 저는 제 나름의, 일종의 마음의 평화를 전할 것입니다. 저는 — 이것이 첫 번째 페이지입니까? 응. 최신 배포로 돌아가겠습니다. 다시 문을 닫고 현실 세계로 돌아가야 합니다. 괜찮은지 확인하겠습니다.

필 혹스워스: 좋아! 엄청난! 이제, 이것은 내 이전 버전 또는 내 최신 버전의 사이트를 제공하는 것으로 돌아갑니다. 다시 기조연설로 돌아가겠습니다. 사물이 불변하고 원자적이기 때문에 이것이 가능합니다. 그 원자적 부분은 다시 한 번 배포가 완전히 포함되었음을 의미합니다. 따라서 웹 서버에서 일부 자산을 사용할 수 있는 지점을 결코 알 수 없지만 일부는 사용할 수 없습니다. 모든 것이 컨텍스트에 있고 모든 것이 있을 때만 완료되면 사이트 제공을 새 버전으로 전환합니다. 다시 말하지만, 이것은 CDN에서 자산 묶음으로 직접 제공되는 JAMstack 사이트로 구축하는 경우 훨씬 더 쉽게 할 수 있는 종류입니다.

Phil Hawksworth: 기조 연설에서 앞뒤로 이동한 후 타이머가 재설정된 것을 확인했습니다. 그래서 6~7분 정도 남은 것 같습니다. 말해봐, 스콧, 만약—

Scott: 네, 아직 10분 정도는 괜찮습니다.

필 혹스워스: 10분? 좋아, 멋져!

스콧: 서두를 필요는 없습니다.

필 혹스워스: 감사합니다. 잘 될 겁니다!

Phil Hawksworth: 따라서 장비를 약간 바꾸고 API와 서비스에 대해 이야기하면(API는 JAMstack의 일부이므로) 우리가 사용할 수 있는 서비스 종류는 대부분 JAMstack입니다. 우리는 사내에서 구축한 서비스를 사용하거나 구매 서비스를 사용할 수 있습니다. 우리를 위해 일을 할 수 있는 다양한 제공자가 있으며 그것이 그들의 전문성이기 때문입니다. API를 통해 우리는 콘텐츠 관리 시스템에서 콘텐츠를 서비스로 가져올 수 있으며, 이를 위해 뛰어난 콘텐츠 관리 경험을 제공한 다음 API를 통해 콘텐츠를 노출하는 것을 전문으로 하는 다양한 공급자가 있습니다. 그들을 끌어들일 수 있습니다.

Phil Hawksworth: 마찬가지로 자산을 제공할 수 있는 다양한 방법이 있습니다. Cloudary와 같은 사람들은 이미지 최적화를 수행하고 API를 통해 사이트에 직접 자산을 제공하는 데 능숙합니다. 아니면 전자 상거래는 어떻습니까? API를 제공할 수 있는 Stripe 또는 Snipcart와 같은 곳이 있으므로 이러한 서비스를 직접 구축할 필요가 없고 전자 상거래 엔진을 구축할 때 수반되는 매우 복잡한 문제에 빠질 필요가 없습니다. 마찬가지로 Oauth를 사용하는 Auth0과 같은 사람들의 ID입니다. 사용할 수 있는 서비스가 많이 있으며 브라우저나 빌드 시 또는 때로는 둘의 조합에서 API를 통해 이러한 것들을 사용할 수 있습니다.

Phil Hawksworth: Now, some people might think, “Well, that's fine, but I don't want to give the keys to the kingdom away. I don't want to risk giving these services over to external providers,” and to that, I say, well, you know, vendors who provide a single service really depend on its success. If there's a company that's core business, or entire business, is in building-out an e-Commerce engine, an e-Commerce service for you, they're doing that for all of their clients, all of their customers, so they really depend on its success and they have the specialist skills to do that.

Phil Hawksworth: So, that kind of de-risks it from you a great deal. Especially when you start to factor in the fact that you can have your technical and service-level contracts to give you that extra security. But it's not all about bought services, it's also about services you can build yourselves. Now, there's a number of ways that this can happen, but sometimes, you absolutely need a little bit of logic on the server. And so far, I've just been talking about taking the server out of the equation. So, how do we do that?

Phil Hawksworth: Well, this is where serverless can really come to the rescue. Serverless and JAMstack, they just fit together really beautifully. And when I'm talking about serverless, I'm talking about no functions as a service. I know that serverless can be a bit of a loaded term, but here, I'm talking about functions as a service. Because functions as a service can start to enable a real micro-services architecture. Using things like AWS Lambda or Google Cloud functions or similar functions as a service, can allow you to build out server infrastructure without a server. Now, you can start deploying JavaScript logic to something that just runs on demand.

Phil Hawksworth: And that means, you can start supplementing some of these other services with, maybe, very targeted small services you build yourselves that can run the serverless functions. These kind of smaller services are easier to reason about, understand, build out and they create much greater agility. I want to just mention a few examples and results from JAMstack sites. I'm not going to go down the server list avenue too much, right now. We can, maybe, come back to that in the questions. I really just kind of want to switch gear and, thinking about time a little bit, talk about some examples and results.

Phil Hawksworth: Because there are some types of sites that lend themselves in a very obvious way to a JAMstack site. Things like the documentation for React, or Vuejs, those [inaudible 00:32:40], pre-rendered JAMstacks sites. As do sites for large companies, such as Citrix, this is a great example of Citrix multi-language documentation. You can actually view the video from the JAMstack conference that happened in New York, where Beth Pollock had worked on this project, talked about the change that went on in that project. From building on traditional, non-enterprised infrastructure to a JAMstack approach and building with Jekyll, which is not necessarily the fastest generating static site generator, but still, they saw a huge improvement.

Phil Hawksworth: Beth talked about the turnaround time for updates went from weeks to minutes. Maybe people are kind of frowning at the idea of weeks for updates to sites, but sometimes in big complex infrastructure, with lots of stakeholders and lots of moving parts, this really is the situation we're often finding ourselves in. Beth also talked about estimating the annual cost savings for this move to a JAMstack site. To get the site running properly, estimated their savings of around 65%. That's huge kind of savings. Changing gear to a slightly different type of site, something a little closer to home, Smashing Magazine itself is a JAMstack site, which might be a little bit surprising, because on one hand, yes, there's lots of articles and it's also content, which is published regularly, but not every minute of the day, for sure.

Phil Hawksworth: So, that might lend itself, perhaps, for something that's pre-generated, but of course, there's also a membership area and an event section, and a job board, and e-Commerce, and all of these things. This is all possible on the JAMstack because not only are we pre-rendering, but we're also enriching things with JavaScript and the front end to call out to APIs, which let some of these things happen. The project that I think I saw Vitaly arrive in the call, so that's going to be good, we might be able to come back to this in a few minutes.

Phil Hawksworth: But the project that migrated, Smashing Magazine onto a JAMstack approach, I believe, simplified the number of platforms from five, effectively down to one. And I'm using Vitaly's words directly here: Vitaly talked about having some caching issues, trying to make the site go quickly, using probably every single WordPress caching plug-in out there, and goodness knows, there are a few of them! So, Smashing Magazine saw an improvement in performance, time to first load went from 800 milliseconds to 80 milliseconds. Again, I'm simplifying the infrastructure that served the site up in the first place. So, it's kind of interesting to see the performance gains that can happen there.

Phil Hawksworth: Another totally different type of site. This is from the Google Chrome team, who built this out to demonstrate at Google I/O this year. This very much feels like an application. This is Minesweeper in a browser. I apologize if you're watching me play this. I'm not playing it while talking to you; I recorded this sometime ago and it's agony to see how terrible I seem to be at Minesweeper while trying to record. That's not a mine, that can't be!

Phil Hawksworth: Anyway, we'll move on.

Phil Hawksworth: The point of that is, this is something that feels very much more like an app, and it was built in a way to be very responsible about the way it used JavaScript. The payload to interactive was 25KB. This progressively would download and use other resources along the way, but it meant that the time to interact was under five seconds on a very slow 3G network. So, you can be very responsible with the way you use JavaScript and still package up JavaScript, as part of the experience for a JAMstack site.

Phil Hawksworth: So, I'm kind of mindful of time. We're almost out of time, so what is the JAMstack? Well, it's kind of where we started from. JAMstack sites are rendered in advance: they're not dependent on an origin server (that's kind of key), and they may be progressively enhanced in the browser with JavaScript. But as we've shown, you don't have to use JavaScript at all. You might just be serving that statically, ready to go, without that. It's an option available to you.

Phil Hawksworth: This key tenant, I think of, JAMstack sites is they're served without web service. They're pre-rendered and done in advance.

Phil Hawksworth: If you're interested in more, it's already been mentioned a little bit, there is a conference in London in July — July 9th and 10th. The speakers are going to be talking about all kinds of things to do with performance in the browser, things that you can do in the browser, results of building on the JAMstack and things to do with serverless.

Phil Hawksworth: There's also a bunch of links in this deck that I will share, after this presentation, including various bits and pieces to do with static site generation, things like headless CMS, the jamstack.org site itself, and a great set of resources on a website called “The New Dynamic” which is just always full of latest information on JAMstack. We're out of time, so I'll wrap it up there, and then head back across to questions. So, thanks very much for joining and I'd love to take questions.

Scott: Thanks, Phil. That was amazing, thank you. You made me feel quite old when you pulled up the Minesweeper reference, so—

Phil Hawksworth: (laughs) Yeah, I can't take any credit for that, but it's kind of fascinating to see that as well.

Scott: So, I do think Vitaly is here.

Vitaly: Yes, always in the back.

Phil Hawksworth: I see Vitaly's smiling face.

Vitaly: Hello everyone!

Phil Hawksworth: So, I'm going to hand it over to Vitaly for the Q&A, because I seem to have a bit of a lag on my end, so I don't want to hold you guys up. Vitaly, I'll hand it over to you.

Scott: Okay. Thanks, Scott.

Vitaly: Thanks, Scott.

Vitaly: Hello—

Vitaly: Oh, no, I'm back. 여러분, 안녕하세요. Now Scott is back but Phil is gone.

Scott: I'm still here! Still waiting for everything.

Vitaly: Phil is talking. Aw, Phil, I've been missing you! I haven't seen you, for what, for days, now? It's like, “How unbelievable!” Phil, I have questions!

Vitaly: So, yeah. It's been interesting for us, actually, to move from WordPress to JAMstack — it was quite a journey. It was quite a project, and the remaining moving parts and all. So, it was actually quite an undertaking. So, I'm wondering, though, what would you say, like if we look at the state of things and if we look in the complexes, itself, that applications have. Especially if you might deal with a lot of legacy, imagine you have to deal with five platforms, maybe seven platforms here, and different things. Maybe, you have an old legacy project in Ruby, you have something lying on PHP, and it's all kind of connected, but in a hacky way. 오른쪽? It might seem like an incredible effort to move to JAMstack. So, what would be the first step?

Scott: So … I mean, I think you're absolutely right, first of all. Re-platforming any site is a big effort, for sure. Particularly if there's lots of legacy. Now, the thing that I think is kind of interesting is an approach that I've seen getting more popular, is in identifying attributes of the site, parts of the site, that might lend themself more immediately to being pre-generated and served statically than others. You don't necessarily have to everything as a big bang. You don't have to do the entire experience in one go. So, one of the examples I shared, kind of, briefly was the Citrix documentations site.

Scott: They didn't migrate all of Citrix.com across to being JAMstack. They identified a particular part that made sense to be pre-rendered, and they built that part out. And then, what they did was they started to put routing in front of all the requests that would come into their infrastructure. So, it would say, “Okay, well, if it's in this part of the past the domain, either in the sub-domain or maybe, through to a path, route that through something which is static, then the rest of it, pass that through to the rest of the infrastructure.

Scott: And I've seen that happen, time and time again, where with some intelligent redirects, which, thankfully, is something that you can do reasonably simply on the JAMstack. You can start to put fairly expressive redirect engines in front of the site. It means that you can pass things through just that section of the site that you tried to take on as a JAMstack project. So, choosing something and focusing on that first, rather than trying to do a big bang, where you do all of the legacy and migration in one. I think that's key, because, yeah, trying to do everything at once is pretty tough.

Vitaly: It's interesting, because just, I think, two days, maybe even today, Chris Coyier wrote an article renaming JAMstack to SHAMstack where, essentially, it's all about JavaScript in which we need think about steady coasting, because JavaScript could be hosted steadily as well. And it's interesting, because he was saying exactly that. He actually — when we think about JAMstack, very often, we kind of tend to stay in camps. It's either, fully rendered and it lives a static-thing. Somewhere there, in a box and it's served from a city and that's it, or it's fully-expressive and reactive and everything you ever wanted. And actually, he was really right about a few things, like identifying some of the things that you can off-load, to aesthetic-side, generated assets, so to say, to that area.

Vitaly: And, JAMstackify, if you might, say some of the fragments of your architecture. Well, that's a new term, I'm just going to coin, right there! JAMstackify.

Phil Hawksworth: I'm going to register the domain quickly, before anybody else.

Phil Hawksworth: And it's a nice approach. I think, it kind of makes my eye twitch a little bit when I hear that Chris Coyier has been redubbing it the SHAMstack, because it makes it sound like he thinks it's a shambles. But I know that he's really talking about static-hosting and markup, which I—

Vitaly: Yes, that's right.

Phil Hawksworth: 저는 JAMstack이라는 용어가 정말 오해의 소지가 있기 때문에 정말 좋아합니다. JAMstack은 너무 많은 다른 것들을 다루려고 하고 제가 하려고 했던 요점은 아마도 그 슬라이드에서 여러 번 두드렸을 것입니다. 모든 종류가 될 수 있다는 것입니다. 것의. 너무 광범위하지만 핵심은 사이트의 핵심을 정적으로 미리 렌더링하고 호스팅하는 것입니다. React 사이트가 어디에 있어야 하는지에 대해 종교 전쟁을 하는 것은 매우 쉽습니다. JAMstack 사이트가 되려면 React 앱이어야 하고, React 앱이므로 JAMstack일 수 없습니다. 그러나 실제로 핵심은 JavaScript를 사용하는지 여부, API를 호출하는지 여부, 사전 렌더링하고 매우 성능이 좋은 정적 호스트에 항목을 가져오는 경우 JAMstack의 핵심입니다.

비탈리: 네, 물론입니다.

Phil Hawksworth: 브라우저가 훨씬 더 많은 기능을 제공하고 있으며 브라우저 자체에 있는 API를 통해 훨씬 더 많은 작업을 수행할 수 있어 매우 다행입니다. 그래서 그런 종류의 문은 훨씬 더 열리지만 JAMstack 사이트로 구축하는 모든 것이 모든 것을 사용해야 한다는 의미는 아닙니다. 우리가 전달하려는 것에 따라 그러한 것들을 배포하기 위해 사용하는 도구를 선택하기 시작해야 합니다.

비탈리: 물론이죠. 여기 도란이 있습니다. 도란, 알 것 같아요, 도란. 도란을 아는 느낌이 든다. 그는 “서버리스가 [00:44:36 들리지 않음]부터 JAMstack과의 완벽한 통합에 끌릴 것으로 예상하십니까? JAM에서 A라고 하는 것.

Phil Hawksworth: 훌륭한 질문입니다. 제 생각에 서버리스 기능은 JAMstack 사이트와 매우 잘 어울리기 때문입니다. 여러 면에서 실제로 누군가 JAMstack 사이트가 서버리스인지 물어본 적이 있기 때문입니다. 그 질문은 서버리스가 로드된 용어이기 때문입니다. 그러나 여러 가지 면에서 내가 원서버가 없다는 이야기를 몇 번이고 반복해서 말했기 때문에 꽝입니다. 관리할 서버 인프라가 없습니다. 사실, 세상은 또 다른 유행어가 필요하기 때문에 "Web Serverless"라는 블로그 게시물을 쓴 적이 있습니다. 그렇죠?

Phil Hawksworth: 그리고 실제로, 그 요점은 그렇습니다. 우리는 서버 없이 구축하고 있습니다. 우리는 이러한 서버를 관리하고 싶지 않으며 서버리스 기능 또는 서비스로서의 기능이 완벽하게 들어 맞습니다. 따라서 요청하려는 API가 필요한 경우에는 브라우저에서 직접 요청하는 것이 합리적이지 않습니다. 따라서 예를 들어 해당 요청에 비밀이나 키가 있는 경우 해당 요청(해당 정보)이 클라이언트에 노출되는 것을 원하지 않을 수 있습니다. 그러나 우리는 확실히 그러한 것들을 대리할 수 있으며 일반적으로 그 때 우리가 해야 할 일은 서버를 스핀업하고 요청을 처리하고 보안 인증을 추가하고 해당 요청을 전달하는 것 이상을 효과적으로 수행하는 일부 인프라를 갖는 것입니다. , 다시 프록시합니다.

필 혹스워스: 서버리스 기능은 이를 위해 완벽합니다. 그들은 그것을 위해 절대적으로 이상적입니다. 그래서 저는 때때로 서버리스 기능 또는 서비스의 기능을 거의 탈출구와 같이 생각합니다. 여기에서 서버에는 일부 논리만 필요하지만 전체 인프라를 만들 필요는 없습니다. 그리고 이를 통해 점점 더 많은 일을 할 수 있고, 서비스로서의 기능이 성숙해지는 개발 워크플로를 위한 개발 파이프라인을 만들 수 있습니다. JavaScript 개발자가 이러한 것들을 구축할 수 있는 것이 점점 더 접근 가능해지고 있습니다. 하여튼 이 두 가지가 정말 잘 어울리는 것 같아요.

Vitaly: 좋습니다. 매우 포괄적인 답변입니다. 사실, 저는 얼마 전에 Amazon의 프론트 엔드 엔지니어가 그들이 사용하는 서버리스 및 Lamda 기능에 대해 이야기하는 강연에 참석했습니다. 저는 거의 자리를 비웠습니다. 그는 항상 Docker와 Kubernetes에 대해 이야기했고 Devox World와 같은 모든 것에 대해 저는 거기에 앉아서 생각했습니다. 무슨 일인지 이해가 안 돼요!” 무슨 일이 일어나고 있는지 전혀 몰랐습니다.

필 혹스워스: 맞아요. 하지만 문제는, 예전에는… 전… 제가 그 세계를 이해하지 못한다는 것을 인정했지만 전혀 다른 분야를 위한 것이기 때문에 이해하고 싶은 마음은 없었습니다. . 그리고 그 규율은 여전히 ​​정말 중요합니다. 인프라를 설계하는 사람들은 여전히 ​​중요합니다. 하지만 지금은 유혹을 받고 있는 것 같아요. 프론트 엔드 개발 배경을 가진 사람으로서, JavaScript 개발자로서 저는 그 세계에서 놀고 싶은 유혹을 훨씬 더 많이 받습니다. 왜냐하면 도구가 일종의 나에게 다가오고 있기 때문입니다.

필 혹스워스: 내가 예전에 얼룩덜룩했던 곳인 내 자신의 실험이 아니라 이러한 것들 중 일부를 사용하고 안전하게 전달할 수 있을 가능성이 훨씬 더 큽니다. 그래서 웹 개발자로서 우리가 더욱 강력해지고 있다는 느낌이 들며, 이는 저에게 흥미진진한 일입니다.

비탈리: 파워레인저처럼요?

Vitaly: 하지만 한 가지 묻고 싶은 것은 사실 우리가 이미, 아마도 일주일 전에 논의한 내용입니다. 하지만 세션에서 언급한 한 가지는 모든 단일 배포의 독립 실행형 인스턴스를 갖는 것은 정말 멋진 일입니다. 하지만 문제는 수만 페이지가 포함된 큰 과제가 있는 경우 매번 모든 것을 다시 배포하고 싶지 않다는 것입니다. 따라서 본질적으로 사물의 정적 측면을 주로 사용하는 경우와 같습니다. 그래서, 우리는 잠시 동안 이 아이디어를 가지고 있었고 이것이 실제로 당신이 지난 시간에 제기한 것이라는 것을 압니다. 원자적 배치의 아이디어.

Vitaly: 실제로 말 그대로 설정의 서로 다른 두 버전의 스냅샷 간에 일종의 div가 제공되었던 곳입니다. 따라서 모든 곳에서 헤더를 변경하면 모든 단일 페이지를 재배포해야 합니다. 그러나 캐러셀과 같은 구성 요소를 변경하면 1000페이지에만 영향을 줄 수 있으므로 15000페이지를 다시 배포하는 것이 좋습니다. 그러나 이것은 1000뿐입니다. 그래서, 우리가 거기에 갈 수 있습니까? 그것은 외부에 있는 마법 같은 아이디어입니까, 아니면 현시점에서 상당히 가시적인 것입니까?

Phil Hawksworth: 아마도 이것이 정적 사이트 생성기 및 이런 종류의 모델을 위한 성배라고 생각합니다. 왜냐하면 확실히 극복해야 할 가장 큰 장애물을 식별했기 때문입니다. 또는 부딪히는 가장 큰 천장. 그리고 그것은 수만, 수십만, 또는 수백만 개의 URL을 가진 웹사이트입니다. 빌드가 매우 길어질 수 있다는 개념입니다. 코드 변경에 따라 변경될 URL을 감지하는 것은 어려운 일입니다. 극복할 수 없는 것은 아니지만 큰 도전입니다. 전체 사이트에서 종속성 그래프가 무엇인지 이해하고 이를 지능적으로 배포하는 것은 정말 어려운 일입니다.

Phil Hawksworth: 언급했듯이 구성 요소 변경은 매우 광범위한 영향을 미칠 수 있지만 어떻게 작동할지 알기는 항상 어렵습니다. 따라서 여러 정적 사이트 생성기, 해당 과제 뒤에 약간의 무게를 두고 부분 재생 및 증분 빌드를 수행하는 방법을 파악하려는 프로젝트가 있습니다. 나는 그것이 언젠가 해결될 것이라는 전망에 매우 흥분되지만, 현재로서는 확실히 큰 도전입니다. 사이트를 논리적으로 공유하려는 시도와 같은 작업을 시작할 수 있으며 마이그레이션 문제와 유사한 종류에 대해 다시 생각할 수 있습니다. 글쎄요, 제가 아는 이 섹션은 사용하는 자산의 종류 또는 거기에 있는 콘텐츠 유형과 관련하여 독립적이므로 개별적으로 배포할 수 있습니다.

Phil Hawksworth: 하지만 그것은 나에게 이상적이지 않습니다. 그것은 정말로 완벽한 시나리오가 아닙니다. 개념 증명으로 제가 조금 탐구한 접근 방식 중 하나는 404를 지능적으로 사용하는 것과 같은 작업을 수행하는 방법에 대해 생각하는 것입니다. 예를 들어, 매우 큰 간판, 아마도 뉴스 사이트의 큰 사용 사례는 속보 기사가 발생했을 때 URL이 필요할 때 URL을 먼저 배포해야 한다는 것입니다. 그들은 거기에 URL을 얻을 필요가 있습니다. BBC 뉴스와 같은 뉴스 기사가 웹사이트에 도착한 다음 시간이 지나면 웹사이트에 점진적으로 추가되지만 먼저 도착하는 것이 중요합니다. 따라서 10분, 20분이 걸리는 빌드가 무엇이든 간에 문제가 될 수 있습니다.

Phil Hawksworth: 하지만 콘텐츠가 추상화되어 있고 API에서 호출되는 데 사용되었을 수 있습니다. 나는 Contentful, Sanity 또는 그와 같은 추상화된 콘텐츠 관리 시스템에 대해 언급했습니다. 콘텐츠 API가 있는 모든 것은 해당 콘텐츠 구조로 변경되어 빌드를 트리거하고 실행을 거치지만 발생할 수 있는 다른 문제는 해당 URL을 게시한 다음 해당 URL을 공개하는 것입니다. , 빌드가 실행되지 않았더라도 누군가가 해당 URL을 눌렀을 때 404의 첫 번째 중지가 "우리는 그것을 얻지 못했습니다"라고 말하는 대신 실제로 해당 API를 직접 누르는 것이라면 다음과 같이 말할 수 있습니다. , "글쎄요, 빌드가 아직 완료되지 않았지만 클라이언트에서 할 수 있습니다." API로 직접 이동하여 가져오고 클라이언트에 채울 수 있습니다.

비탈리: 흠, 흥미롭군요.

Phil Hawksworth: 따라서 빌드가 아직 진행 중인 동안에도 이러한 항목을 채우기 시작할 수 있습니다. 그리고 빌드가 완료되면 당연히 404에 도달하지 않을 것입니다. 정적으로 실행 중인 페이지에 도달할 것입니다. 따라서 이를 해결하기 위한 기술과 전략이 있습니다. 하지만 여전히 매우 길고 모호한 답변입니다. 죄송합니다. 하지만 제 결론은 그렇습니다. 그건 도전입니다. 우리는 더 나은 전략을 얻을 것입니다.

비탈리: 네, 좋습니다. 그래서, 궁금합니다. 그래서 이 시점에서 우리는 콘텐츠 제공 측면에서의 성능뿐만 아니라 빌드 속도 측면에서의 성능 측면에서 실제로 생각하지 않습니다. 건물 배포처럼. 그래서 이것은 또한 우리가 꽤 오랜 시간 동안 찾고 있는 것이기도 합니다.

비탈리: 한 가지 더 묻고 싶은 것이 있습니다. 이것은 당신이 언급한 이 기술처럼 흥미롭습니다. 이에 대해 어떻게 알 수 있습니까? 이것은 사람들이 자신의 블로그에 게시하는 경향이 있는 것입니다. 또는 일종의 매체인지 아니면 JAMstack의 사례 스튜디오를 얻을 수 있는 중앙 저장소가 있습니까? JAMstack—회사가 언로드하는 동안 어떻게 이동했는지 또는 이전에 실패했는지 잼스택.

Phil Hawksworth: 현재로서는 이 풍경이 조금씩 성숙해지고 있습니다. 내 말은, 이러한 예 중 일부는, 제 생각에 저는 매우 운이 좋은 위치에 있습니다. 저는 장난감을 가지고 노는 역할을 하는 곳에서 일하며 흥미로운 사용 방법을 고안하고 실험을 시작합니다. 그들과 함께. 따라서 이러한 개념 증명은 일종의 실험을 통해 이러한 문제를 해결하려고 시도하는 것입니다. 하지만 앞서 언급했듯이 뉴욕에서 열린 JAMstack 컨퍼런스에서 보여진 사례 연구와 확실히 이와 같은 이벤트에서 우리는 모범 사례 또는 업계 관행 및 업계 접근 방식이 그런 종류의 이야기를 하는 것을 보기 시작했습니다. 이벤트. 그리고 확실히, 나는 우리가 이 정보를 훨씬 더 쉽게 공유할 수 있도록 더 많은 것을 보고 더 많은 사례 연구를 통해 Smashing Magazine과 같은 장소에 오르고 싶습니다.

Phil Hawksworth: 제 생각에는 대기업과 엔터프라이즈 공간에서 서로 다른 장소에서 다른 방식으로 JAMstack을 점차적으로 채택하고 있다고 생각합니다. 경험, 우리 모두는 그로부터 배울 수 있습니다. 그러나 저는 이러한 사례 연구가 점점 더 많이 출판되어 특히 이러한 종류의 도전을 극복하는 방법에 대해 기댈 수 있기를 바랍니다.

Vitaly: 알겠습니다. 그럼 마지막 질문일 것입니다. 저는 항상 질문을 읽는 것을 좋아하기 때문입니다. 그래서 JAMstack 랜드, 무언가를 바꿀 수 있다면 배포를 넘어서 간절히 보고 싶은 것이 있을지도 모릅니다. 정말 당신을 매우 행복하게 만드는 다른 것이 있습니까? 그것이 당신의 하루를 만들 것입니까? 그게 뭐지? JAMstack의 위시리스트에 무엇이 있습니까?

필 혹스워스: 질문입니다. 내 말은, 우리가 증분 빌드에 대해 이야기하지 않았다면—

비탈리: 우리는 했다. 너무 늦었어, 지금. 이 카드는 이미 통과되었습니다. 우리는 다른 것이 필요합니다.

필 혹스워스: 그래서—

Vitaly: 제 말은, 플랫폼에서와 같이 뒤쪽 플랫폼을 보면 정말 많은 흥미로운 일들이 일어나고 있다는 것입니다. 우리는 Houdini, 웹 구성 요소 및 모든 것을 가지고 있습니다. 모든 올바른 구성 요소의 전체 환경을 변경할 수 있기 때문입니다. 다른 한편으로 우리는 SS NGS와 함께 이 모든 마법과도 같은 멋진 세상을 가지고 있으며, 물론 분명히 단일 페이지 응용 프로그램과 모든 것 또한 가지고 있습니다. 가장 흥분되는 것은 무엇입니까?

Phil Hawksworth: 진행 중인 작업이 너무 많고 흥미진진하며 브라우저에서 사용할 수 있는 새로운 기능이 너무 많기 때문에 여기서는 말을 아꼈습니다. 제가 정말 신나는 것은 절제하는 사람들(웃음) 그리고 제가 말했듯이 무뚝뚝한 대답이지만, 저는 더 많은 청중들에 대해 사려 깊게 절제된 훌륭한 처형을 보는 것을 좋아합니다. 가장 빛나는 새 JavaScript 라이브러리나 새 브라우저 API로 빌드하는 것은 정말 재미있고 만족스럽습니다. 이 새 브라우저 API는 지금 우리에게 절실히 필요한 브라우저의 기능을 긁고 냄새를 맡을 수 있습니다.

필 혹스워스: 하지만 저는 제가 알고 있는 것들이 많은 곳에서 효과가 있을 것이라는 것을 보는 것을 정말 좋아합니다. 그들은 정말 성능이 좋고, 멋진 장난감을 가지고 있는 CEO와 CTO의 책상 위에 있을 뿐만 아니라 훨씬 더 낮은 전력의 장치를 가지고 있는 사람들에게도 존재하는 브라우저에 공감할 것입니다. 네트워크 조건이 까다롭거나 그런 것들이 있습니다. 저는 플랫폼에 공감하고 더 많은 청중을 동정하는 방식으로 전달되는 흥미로운 경험과 풍부한 경험을 보는 것을 좋아합니다. 웹을 구축하는 개발자인 우리보다 웹이 훨씬 더 멀리 도달한다고 생각하기 때문입니다. . 그리고 더 많은 사람들에게 다가갈 수 있는 방식으로 흥미로운 일을 하는 것을 보고 흥분됩니다.

필 호크스워스: 그건 아마도 당신이 원하는 대답이 아닐 것입니다.

비탈리: 오, 좋은 결말이네요. 정말 고맙습니다. 아니, 완벽해, 정말이야. 좋아, 나는 모든 것이 잘 된 것을 느꼈다! 함께해주셔서 감사합니다! 스캇에게 나눠줄게!

필 혹스워스: 훌륭합니다!

비탈리: 저는 단지 질문과 답변을 하기 위해 왔습니다. 정말 감사합니다, 필! 나는 아직 여기 있지만 Scott, 무대는 이제 당신 것입니다! Smashing TV에서 다음에 나올 내용을 공유해 주시겠습니까?

Scott: 먼저 할게요. 먼저 Phil, 스크래치 및 스니프 API 구현이 어떻게 작동하는지 보고 싶습니다. 매우 흥미롭게 들립니다. 그리고 Vitaly, JAMstackify는 이미 사용 중입니다.

비탈리: (낙심하며) 잡았다?! 우리가 그것을 살 수 있습니까?

스콧: 아니요, 존재합니다!

비탈리: 글쎄, 너무 늦었어. 나는 항상 늦는다.

필 혹스워스: 나름대로 흥미롭습니다.

비탈리: 그게 내 인생의 이야기야. 나는 항상 늦는다.

Scott: 다음 회원이 될 것입니다. 13일 목요일에는 제 할아버지인 Zach Leatherman이 그가 가장 잘 이야기하는 글꼴에 대해 이야기하는 것 같습니다. 그래서 그는 글꼴 구현의 다섯 가지 Y에 대해 이야기하고 있습니다. 그리고 19일에 발표할 Eva Faria와 함께 JavaScript와 CSS를 사용하여 비디오를 편집하는 것에도 매우 관심이 있습니다. 따라서 두 가지 모두에 대해 계속 지켜봐 주십시오.

Scott: 다음 주 목요일에는 Zach Leatherman과 함께하고 19일에는 Eva와 함께 JavaScript 및 CSS로 비디오 편집에 대해 이야기할 예정입니다. 그래서, 그 쪽지에서 Phil, 더 이상 당신을 볼 수 없습니다, 당신은 여전히 ​​거기에 있습니까?

필 혹스워스: 나 여기 있어!

Scott: 그런 점에서 모든 분들께 감사드립니다! 또한 토론토 지역에 가까운 사람이 있습니까? 또는 토론토를 방문하고 싶었던 사람이 있습니까? 6월 말에 컨퍼런스가 있고 아직 티켓이 몇 장 남아 있습니다. 그래서, 아마도 우리는 그곳에서 여러분 중 일부를 보게 될 것입니다.

비탈리: 다른 모든 분들, 정말 감사합니다!

비탈리: 아, 그런데 한 가지만 더! Phil이 언급했을 수도 있지만 7월에 런던에서 JAMstack 컨퍼런스도 있습니다. 따라서 주의해야 할 사항이기도 합니다. 하지만 난 서명을 하고 내 샐러드를 사러 갈거야! 당신이 무엇을-

Scott: 좋아, 안녕, 모두들!

비탈리: 좋아, 안녕, 모두들.

랩입니다!

지속적이고 친절한 지원을 아끼지 않으신 Smashing Member께 진심으로 감사드립니다. 앞으로 더 많은 웨비나를 개최할 수 있기를 고대합니다.

또한 Phil은 다음 주 SmashingConf Toronto 2019와 JAMstack_conf에서 MC를 맡을 예정입니다. 그곳에서도 뵙고 싶습니다!

이 일련의 인터뷰가 유용하다고 생각하는지, 인터뷰하기를 원하는 사람, 또는 어떤 주제를 다루기를 원하는지 알려주시면 바로 안내해 드리겠습니다.