Guillermo Rauch와 함께하는 스매싱 팟캐스트 에피소드 23: Next.js는 무엇인가요?
게시 됨: 2022-03-10오늘은 Next.js에 대해 이야기하겠습니다. 그것은 무엇이며 우리의 웹 개발 워크플로에서 어디에 적합할까요? 저는 공동 제작자 Guillermo Rauch와 이야기를 나누었습니다.
메모 표시
- 기예르모 라우흐 트위터
- 다음.js
주간 업데이트
- “React에서 Props 및 PropTypes 마스터하기”
데이비드 아덴아이 - "Bradbury Thompson의 영감을 받은 디자인 결정: 그래픽 디자인의 예술"
앤디 클라크 - "Flask, Google의 Cloud SQL 및 App Engine을 사용하여 API 설정"
월레 오예칸미 - "Ionic React의 형태와 검증"
제리 나비 - "고객이 디자인을 통해 더 많은 백링크를 얻을 수 있도록 돕는 방법"
수잔 스카카
성적 증명서
Drew McLellan: 그는 Jamstack 워크플로에 적합한 정적 사이트용 클라우드 플랫폼인 Vercel의 설립자이자 CEO입니다. 그는 Next.js의 공동 제작자이기도 합니다. 그는 이전에 LearnBoost 및 CloudUp을 설립했으며 Socket.io, Mongoose 및 SlackIn과 같은 여러 인기 있는 노드 오픈 소스 라이브러리의 작성자로 잘 알려져 있습니다. 그 전에는 MooTools의 핵심 개발자였으므로 그가 JavaScript를 손등처럼 다루는 방법을 알고 있다는 것을 알고 있습니다. 한때 스페인 왕으로부터 왕실의 의뢰를 받아 빙산 상추로 얼음 조각을 만들었다는 사실, 알고 계셨나요? 나의 스매싱 친구 여러분, 기예르모 라우흐를 환영하십시오. 안녕 길예르모, 잘 지내니?
Guillermo Rauch: 정말 잘하고 있습니다. 저를 데려다 주셔서 감사합니다.
Drew: 저는 오늘 Next.js의 전체 세계에 대해 이야기하고 싶었습니다. 처음부터 공동 제작자로 참여했기 때문에 개인적으로 매우 잘 알고 있는 분야이기 때문입니다. Next.js는 Jamstack 공간에서 작업하는 동안 내 레이더에 포착된 프로젝트 이름 중 하나이지만 이전에 실제로 개인적으로 보거나 너무 밀접하게 작업한 것은 아닙니다. Next.js가 무엇인지 잘 모르는 나와 같은 사람들을 위해 Next.js가 무엇인지, 어떤 문제를 해결하려고 하는지에 대한 배경 지식을 제공할 수 있습니다.
Guillermo: Next.js는 실제로 완전히 SSR에 초점을 맞춘 프레임워크가 되기 시작했기 때문에 Next.js는 Jamstack 세계의 매우 흥미로운 구성원입니다. 사람들이 특히 사용자 생성 콘텐츠 또는 동적 콘텐츠 또는 소셜 네트워크 또는 전자 상거래를 원할 때 매우 큰 것을 구축하고 있던 Jamstack 공간 외부에서 많은 채택을 받기 시작했습니다. 매우 크거나 매우 역동적입니다. Jamstack 세계의 많은 사람들이 생각하기에 레이더에 걸렸지만 나중에 Next.js는 정적 최적화 기능을 얻었습니다.
Guillermo: 한편으로는 Next.js를 사용하여 페이지의 최상위 수준에서 데이터 가져오기를 수행하지 않으면 React 페이지는 … Next.js는 단순히 프로덕션을 위한 React 프레임워크이지만 일부 렌더링을 수행할 수 있는 기능이 있습니다. 그런 다음 정적 최적화 기능을 사용할 때 페이지의 최상위 수준에서 데이터 가져오기를 정의하지 않으면 서버 렌더링으로 아무것도 하지 않고 자동으로 HTML로 내보내집니다.
Guillermo: 그런 다음 나중에 정적 사이트 생성 기능도 얻었습니다. 즉, 특수 데이터 후크를 정의할 수 있지만 해당 데이터 후크는 빌드 시 데이터를 가져옵니다. Next.js는 하이브리드, 매우 강력한 동적 및 정적 프레임워크가 되었으며 이제 Jamstack 공간에서도 많이 성장하고 있습니다.
Drew: 사람들은 React가 이미 프레임워크라고 말할 수 있습니다. 분명히 그렇게 설명되는 것을 들었을 것입니다. React의 프레임워크가 된다는 것은 실제로 무엇을 의미합니까?
Guillermo: 그것은 훌륭한 관찰입니다. 왜냐하면 저는 사람들에게 Facebook의 React와 Facebook 외부의 React는 완전히 다른 짐승이라고 항상 지적하기 때문입니다. Facebook의 React는 실제로 서버 렌더링과 함께 사용되지만, 예를 들어 서버 렌더링에서도 Node.js를 사용하지 않고 Hermes라는 고도로 전문화된 가상 머신을 사용하여 일종의 프로덕션 해킹 및 PHP 스택 및 답변과 통신합니다. 이 모든 고급스럽고 이국적인 Facebook 요구 사항.
Guillermo: 그들이 React를 오픈 소스로 만들 때, 그것은 컴포넌트를 오픈 소싱하는 것과 거의 같습니다. 나는 항상 그것을 오픈 소싱 엔진이라고 부르지만 당신에게 차를 주는 것은 아닙니다. 일어난 일은 사람들이 정말로 그것을 가지고 운전하기를 원했고 React와 함께 장소에 가고 싶어했다는 것입니다. 커뮤니티에서 사람들은 자동차를 만들기 시작했고 그들은 React를 자동차의 기본 부분으로 만드는 드라이버, 개발자가 처음에 추구했던 엔진으로 React를 포함했습니다. Next.js, Gatsby, React Static 및 기타 많은 프레임워크가 등장하기 시작하여 "사실 완전히 로드된 페이지와 애플리케이션을 만들고 싶습니다."와 같은 요구 사항을 해결했습니다.
Guillermo: React는 페이지 내의 특정 위젯을 위한 구성 요소 및 엔진과 비슷하지만 Facebook의 경우에는 확실히 그렇습니다. 그들은 알림 배치, 채팅 위젯, 뉴스피드 구성 요소와 같은 것을 위해 그것을 발명했음을 광범위하고 공개적으로 인정할 것입니다. 이러한 구성 요소는 수많은 코드 줄과 함께 프로덕션 기존 앱의 콘텐츠에 포함된 React 경로였습니다. 그리고 다른 JS 라이브러리와 프레임워크까지.
Guillermo: React를 위한 프레임워크를 만드는 것이 의미하는 바는 React를 스토리의 기본 부분으로 만드는 것입니다. 바라건대 이것이 우리가 Next.js로 하려고 하는 것입니다. 학습 곡선은 주로 React에 관한 것입니다. Next.js의 표면, 특히 데이터 가져오기 및 라우팅과 관련하여. 우리는 또한 많은 프로덕션 최적화를 수행하므로 React를 얻을 때 Create React 앱을 얻을 때 Facebook에서 제공하는 부트스트랩 자동차라고 부르고 싶습니다. 아마도 프로덕션 요구 사항이 실제로 충족되지 않을 수 있습니다. . 아니면 Webpack을 설정하고 Babel을 설정하고 서버 렌더링과 정적 생성을 설정하여 직접 하려고 하면 차를 처음부터 조립하는 것도 어렵습니다. Next.js는 이 제로 구성과 React로 전체 큰 것을 구축하는 것과 관련하여 프로덕션에 최적화된 기본값 세트를 제공합니다.
Drew: 따라서 사전 구성된 도구 모음을 사용하여 React 앱 주변에 일종의 생태계를 구축하여 다음을 수행할 수 있도록 하는 것과 같습니다.
길예르모: 맞습니다.
Drew: 본격적으로 시작하고 정적 사이트 생성 또는 서버 렌더링 또는 라우팅을 수행합니다.
Guillermo: 맞습니다. 사전 구성된 이 모든 것의 핵심인 단어를 사용하셨습니다. Next.js의 기고자로서 Google 크롬의 관심을 끌만큼 운이 좋습니다. 이 프로젝트의 리더 중 한 명인 그녀는 Google에서 내부적으로 프레임워크 작업을 할 때 커뮤니티와 오픈 소스가 오늘날 직면하고 있는 것과 동일한 문제를 많이 겪었습니다. 실제로 성능이 뛰어난 웹 앱을 즉시 확장하고 만드는 방법에 대해 Google에는 다양한 경쟁 이니셔티브가 있었습니다.
Guillermo: Google 직원으로 합류하면 프로덕션 준비가 완료된 고성능 애플리케이션을 만들 수 있는 프레임워크가 제공됩니다. Shubie는 많은 이니셔티브의 일부였으며 그녀가 발견한 것은 프레임워크를 대규모로 성공시키는 데 두 가지 핵심 요소가 있다는 것입니다. 하나는 사전 구성으로, 일을 시작하고 새로운 앱을 시작하게 되며 이미 사용할 준비가 되어 있고 해당 시점에 알려진 많은 생산 요구 사항을 충족하는 무언가가 제공되어야 합니다. 제 시간에.
Guillermo: 반면에 우리가 노력하고 있는 또 다른 중요한 단계는 적합성입니다. 가장 최적화된 프로덕션 준비가 완료된 사전 구성된 프레임워크를 제공받을 수 있지만, 예를 들어 많은 종속성 또는 타사 스크립트를 도입하거나 페인팅하는 데 오랜 시간이 걸리는 매우 비효율적인 레이아웃을 사용하는 경우 그런 다음 사전 구성을 낭비하게 될 것입니다. 사전 구성과 시간 경과에 따른 적합성을 혼합함으로써 개발자는 훌륭한 출발점을 가질 수 있을 뿐만 아니라 시간이 지남에 따라 성공할 수 있습니다.
Drew: Next.js의 특징은 상당히 독단적이며 UI 레이어가 React이며 유형 스크립트를 사용하고 Webpack을 사용하며 이 모든 것이 프로젝트에서 선택하고 얻은 것입니다. 내가 틀렸다면 정정해 주세요. 하지만 예를 들어 Next.js 내에서 React를 Vue로 교체할 수 없습니다.
Guillermo: 기술적 의사결정이 일종의 예술과 만나는 좋은 점입니다. 한편으로 저는 Next가 매우 무의미하다고 주장하고 싶습니다. 그 이유는 구체적으로 github.com/vercel/nextjs 및 examples 디렉토리로 이동하면 Next.js와 함께 사용할 수 있는 기술의 조합 폭발. 화재 기반, 그래픽 UL, Apollo, Redux, MobX, CSS 공간에는 더 많은 옵션이 있습니다.
Guillermo: 기본 CSS 포트가 내장되어 있지만 두 가지 방식을 사용할 수 있습니다. 하나는 가져오기 기능이 있고 다른 하나는 Style JSX라고 하는 스타일 태그가 있습니다. 이는 Shadow CSS에 대한 웹 플랫폼 접근 방식과 매우 유사합니다. 내가 의견이 없다는 것을 의미하는 이유는 Next.js가 웹의 "베어메탈"에 매우 가깝게 유지되기를 원하고 오늘로부터 10년 후의 웹이 호환되지 않는 많은 기본 요소를 도입하지 않기를 원하기 때문입니다. 그런 다음 예제를 보면 플러그인할 수 있는 다른 모든 기술이 있음을 알 수 있습니다.
Guillermo: 의견의 기본 수준은 React가 있고 적어도 조만간 이를 대체할 수 없을 것이라는 것입니다. 그런 다음 페이지를 만들 수 있어야 한다는 개념이 있습니다. 이것은 우리가 처음 출시했을 때 일종의 새로운 것과 같았습니다. 모든 사람이 단일 페이지 애플리케이션을 만들려고 하는 것이었습니다. 우리가 깨달은 것은 인터넷이 검색 엔진, Twitter, Facebook, 소셜 네트워크, 이메일 동반자를 통해 뚜렷한 진입점을 만드는 많은 페이지가 있는 웹사이트로 구성되어 있다는 것입니다. 마치 당신이 항상 사람을 진입점으로 안내하는 것처럼 그리고 그 진입점을 통해 오는 사람은 전체 응용 프로그램의 부담을 다운로드할 필요가 없습니다.
Guillermo: 그런 다음 그 경로를 통해 서버 렌더링을 구현한 다음 여러 페이지에 대한 정적 생성 등을 구현하게 되었습니다. 다른 기본 수준의 의견은 다음이 아니라 웹에 대해 작동하는 프레임워크여야 합니다. 그런 다음 React는 데이터 가져오기 및 라우팅 기본 요소가 누락되었으며 이를 추가했습니다. 모든 사람에게 라우터가 필요한 것처럼 처리해야 하는 의견 수준이 있으므로 기본적으로 라우터가 내장되어 있을 수도 있습니다.
Drew: 이러한 기본값을 사용하는 가장 큰 이점은 선택의 복잡성을 많이 없애고 거기에 있고 구성되어 있으며 너무 많이 생각할 필요 없이 바로 사용할 수 있다는 것입니다. -
길예르모: 맞습니다.
Drew: 사용할 구성 요소에 대한 선택의 폭이 너무 많고 압도적이고 생산성을 저해할 수 있는 상황에 있었습니다.
길예르모: 맞습니다.
Drew: 사람들이 Next.js를 사용하는 프로젝트의 종류는 무엇입니까? 기본적으로 프로덕션 React 앱을 빌드할 수 있는 모든 상황을 위한 것입니까, 아니면 특정 유형의 콘텐츠가 많은 사이트에 더 적합합니까? 그런 의미에서 중요합니까?
Guillermo: 예, 이것은 웹에 대한 오래된 논쟁이었습니다. 웹은 앱을 위한 것입니까, 웹은 사이트를 위한 것입니까, 하이브리드입니까? JavaScript 등의 역할은 무엇입니까? 직접적인 대답을 하기는 다소 어렵지만, 웹은 항상 사용자에게 점점 더 역동적이고 개인화되도록 진화하는 콘텐츠의 하이브리드로 진화해 왔다고 생각합니다. 콘텐츠 웹사이트라고 해도 전 세계의 고급 콘텐츠 웹사이트에는 앱과 매우 유사한 코드 기반이 있습니다.
Guillermo: 여기의 좋은 예는 New York Times입니다. 데이터 분석 도구와 대화형 애니메이션이 포함된 위젯을 제공하고 다음에 읽을 기사를 추천하고 구독 모델이 내장되어 있습니다. 콘텐츠의 일부이며 때로는 읽은 기사 수를 계산합니다. 웹이 발명되었을 때 내가 이것을 말했다면 Tim Berners-Lee는 "아니, 그건 미쳤어. 웹에서는 불가능해."라고 말했을 것입니다. 하지만 그것이 오늘날 우리가 가진 웹입니다.
Guillermo: Next.js는 이러한 복잡하고 현대적인 요구 사항을 많이 해결하고 있습니다. 즉, 전자 상거래를 많이 사용하고 그에 대한 콘텐츠도 많이 보게 될 것입니다. 그런데 전자 상거래는 항목을 구매하는 것뿐만 아니라 웹에서 가장 큰 부동산 웹사이트인 realtor.com, zillow.com, trulio.com과 같은 경험을 의미합니다. 전체 카테고리는 모두 Next.js이고 그 다음에는 콘텐츠입니다. 사이트. 우리는 방금 Washtonpost.com을 Vercel 및 Next.js의 고객으로 등록했습니다. 그런 다음 더 새롭고 매우 흥미로운 세 번째 카테고리가 있습니다. 전체 앱과 tiktok.com과 같은 사용자 생성 콘텐츠입니다. 원래의 단일 페이지 응용 프로그램 사용 사례가 거기에 잘 표현되어 있다고 생각할 것입니다.
Guillermo: Next.js는 매우, 매우 빠르게 제공되어야 하고 SEO에 최적화되어야 하는 많은 콘텐츠가 필요할 때 빛을 발합니다. 하루가 끝나면 동적과 정적이 혼합되어 있습니다.
Drew: 이전에 Marcy Sutton과 비슷한 종류의 공간에 있는 Gatsby에 대해 이야기한 적이 있습니다. 문제에 대한 하나 이상의 솔루션을 보고 한 프로젝트에서 다음 프로젝트를 선택할 수 있다는 것은 항상 좋은 일입니다. Next.js와 Gatsby가 같은 종류의 문제 공간에서 운영되고 있으며, 얼마나 유사하거나 유사하지 않다고 말씀하시겠습니까?
Guillermo: 일부 사용 사례에서 중복되는 부분이 있다고 생각합니다. 예를 들어, 내 개인 블로그 rauchg.com은 Next.js에서 실행되며 훌륭한 Gatsby 블로그일 수도 있습니다. 더 작은 정적 웹사이트 공간에는 겹치는 부분이 있으며, 작게는 관련성이 없다는 의미가 아닙니다. 매우 중요하고 매우 중요한 많은 닷컴은 기본적으로 정적인 웹에서 실행되므로 이것이 Jamstack의 장점이라고 생각합니다. Next.js는 페이지를 정적으로 최적화할 수 있고 이를 통해 훌륭한 Lighthouse 점수를 얻을 수 있으므로 중복 사용 사례에 사용할 수 있습니다.
Guillermo: 더 역동적인 요구 사항이 시작되고 페이지가 많으면 한 번에 업데이트해야 할 필요가 있을 때 선이 그려지는 것 같습니다. Gatsby가 이에 대한 솔루션을 만들고 있지만 Next.js는 이미 모든 종류의 데이터베이스, 기본적으로 많은 페이지를 "생성" 또는 "인쇄"하기 위한 모든 종류의 데이터 백엔드와 작동하는 프로덕션 준비 라이브 솔루션을 보유하고 있습니다. 그것이 오늘날 고객들이 Gatsby 대신 Next.js로 가는 곳입니다.
Drew: JavaScript 기반 솔루션이 커짐에 따라 모든 사람이 직면하는 문제 중 하나는 성능이며 어떻게 일이 상당히 느려지기 시작하면 큰 번들 크기를 갖게 되는 것입니다. 전통적으로 코드 분할과 같은 것은 올바르게 구성하기에는 상당히 복잡할 수 있습니다. 코드 분할이 자동이라고 주장하는 Next.js의 기능 중 하나가 바로 이것이었습니다. Next.js는 코드 분할과 관련하여 그 작업을 수행하기 위해 무엇을 합니까?
Guillermo: 당신의 관찰이 100% 맞습니다. 웹에서 가장 큰 것 중 하나이자 웹에서 가장 큰 비중을 차지하는 것 중 하나는 JavaScript인데, 실제 물리적 부피에 관계없이 다른 재료가 다른 밀도와 가중치를 갖는 것처럼 JavaScript는 매우 조밀하고 무거운 요소인 경향이 있습니다. 예를 들어 비동기식으로 처리할 수 있고 메인 스레드에서 벗어난 이미지와 비교하여 JavaScript의 양이 적은 경우에도 JavaScript는 특히 성가신 경향이 있습니다.
Guillermo: Next.js는 번들을 자동으로 최적화하기 위해 엄청난 노력을 기울였습니다. 내가 Next.js에 대한 아이디어를 처음 떠올렸을 때 첫 번째 직관은 예를 들어 10개의 경로를 정의할 것이라는 것이었습니다. Next.js 세계에서 페이지 디렉토리를 만들고 Index.js, About.js, Settings.js, Dashboard.js, termsofservice.js, Signup.js, Login.js에 파일을 놓습니다. 이는 모든 종류의 미디어를 통해 공유할 수 있는 애플리케이션의 진입점이 됩니다.
Guillermo: 이러한 항목을 입력할 때 해당 페이지와 관련된 JS를 가장 먼저 제공한 다음 시스템 내에서 후속 탐색이 매우 원활하도록 공통 번들을 제공하고자 합니다. Next.js도 매우 훌륭합니다. 단일 페이지 애플리케이션처럼 느껴지도록 해당 진입점에 연결된 나머지 페이지를 자동으로 미리 가져옵니다. 많은 사람들이 "내게 몇 가지 경로가 있다는 것을 알면 Create React 앱을 사용하지 않는 이유는 무엇입니까?"라고 말합니다. 저는 항상 그들에게 이렇게 말합니다. , 그 초기 진입점."
Guillermo: 이것이 초기 코드 분할 방식이었지만 시간이 지남에 따라 훨씬 더 정교해졌습니다. Google은 최신 브라우저에 차등 JS를 제공하고 폴리필드가 많은 레거시 JS를 다른 브라우저에 제공하는 Module and No Module이라는 매우 멋진 최적화에 기여했으며 이 최적화는 100% 자동화되어 막대한 비용을 절감합니다. Vercel에서 호스팅하는 Parnaby's라는 고객에게 그것을 주었습니다. 제 생각이 틀리지 않았다면 그것은 매우 매우 중요한 일이었습니다. 코드 크기가 30% 절감된 것과 같았습니다. 이는 Next.js를 JS 번들을 더 최적화한 버전으로 업그레이드했기 때문입니다.
Guillermo: 그것은 우리가 이전에 다루었던 일종의 요점이었습니다. Next.js를 선택하면 시간이 지남에 따라 점점 더 좋아지고 최적이 될 것입니다. 사용자를 대신하여 계속해서 최적화할 것입니다. 다시 말하지만, 그것은 당신이 결코 다루거나 귀찮게 할 필요가 없는 사전 구성이며, 솔직히 말하면 당신이 하고 싶지도 않은 연구입니다. 나는 분명히 이것에 별로 관여하지 않았지만 내부 토론 중 일부를 보고 그들은 Internet Explorer X와 Soho에게만 중요한 이러한 모든 폴리필드에 대해 논의하고 있었던 것처럼 "나는 알고 싶지도 않습니다. , Next.js를 업그레이드하고 이 모든 혜택을 누리세요.”
Drew: 때때로 기본값을 고수하고 가장 일반적인 구성을 고수하면 실제로 Next.js 접근 방식인 것처럼 보이는 큰 이점이 있습니다. 제가 2000년대 초에 PHP를 작성하기 시작했을 때 모든 사람들이 PHP와 MySQL을 사용하던 때가 기억납니다. 당시 저는 Windows에서 왔기 때문에 PHP와 Microsoft Sequel Server를 사용하고 싶었습니다. 당신은 할 수 있지만, 당신은 전체 방법으로 조류에 맞서 수영하고 있습니다. 그런 다음 MySQL로 전환하자마자 전체 생태계가 저를 위해 작동하기 시작했고 그것에 대해 생각할 필요가 없었습니다.
Guillermo: 예, 모든 것이 클릭만 하면 됩니다. 정말 대단한 관찰입니다. 우리는 항상 Babel 생태계가 너무 강력해서 예를 들어 Babel을 다른 것으로 교체함으로써 조금 더 빨라질 수 있다는 것을 알지만, 그러면 그 놀라운 생태계 호환성을 희생해야 합니다. 이것은 이전에 성능에 대해 다루었으며 많은 사람들이 그렇듯이 빌드 성능 및 정적 생성 성능은 큰 병목 현상이며 이는 우리 도구의 성능을 점진적으로 개선하기 위해 매우 부지런한 것입니다.
Guillermo: 예를 들어, Next.js가 현재 하고 있는 일 중 하나는 Webpack 4에서 Webpack 5로 기본값을 업그레이드하는 것인데, 여기에는 몇 가지 중요한 문제가 있습니다. 플래그에 있지만 나중에 기본값이 됩니다. Webpack 5는 놀라운 성능 향상을 제공하지만 Webpack 에코시스템을 희생하는 것이 아니라 점진적으로 개선했습니다. 물론, 희생해야 할 아주 작은 것들이 몇 가지 있었지만, 오늘날 많은 사람들이 간과하고 있는 JS 생태계의 놀라운 이점입니다. 아마도 그들이 "오, 우리는 X Soho에서는 조금 더 빨랐을 수도 있고, Soho에서 MPM은 시간이 덜 걸릴 수도 있습니다.” 그들은 몇 가지 세부 사항을 선택하고 더 큰 그림을 놓칩니다. 생태계 가치는 엄청납니다.
Drew: 다른 것을 사용하여 교체하는 대신 Next.js와 같은 프로젝트에서 모든 구성과 유지 관리 및 그 측면을 수행하는 것의 가치는 놀랍습니다. 왜냐하면 해당 기본값에서 벗어나는 즉시 , 모든 호환성을 유지하고 직접 수행해야 하는 부담을 지고 있습니다. 내가 Next.js에 대해 정말 관심을 가지고 있었던 것 중 하나는 정적 사이트 생성 또는 서버 측 렌더링, 또는 아마도 둘의 하이브리드를 수행하는 데 사용할 수 있는 옵션이 있다는 것입니다. 최근 업데이트에서 이에 대한 최근 변경 사항이 있는 것 같습니다. 이에 대해 잠시 말씀해 주시겠습니까? 그리고 언제 둘 중 하나를 선택할 수 있습니까?
길예르모: 네, 물론입니다. 앞에서 설명한 페이지 시스템과 결합된 이 하이브리드 접근 방식의 핵심 구성 요소 중 하나는 완전히 정적인 페이지나 서버가 렌더링하는 페이지를 가질 수 있다는 것입니다. 완전히 정적인 페이지는 내가 정적 호이스팅이라고 부르는 놀라운 이점이 있습니다. 즉, 해당 자산을 가져와 자동으로 가장자리에 배치할 수 있습니다. 엣지에 배치함으로써 캐시할 수 있고, 선제적으로 캐시할 수 있고, 복제할 수 있고, 요청이 들어올 때 미리 알고 있기 때문에 서버에 닿지 않도록 만들 수 있습니다. 이봐, 슬래시 인덱스는 정적이야."
Guillermo: 이는 전 세계 청중에게 서비스를 제공하는 것과 관련하여 매우, 매우 흥미로운 이점입니다. 특히 Vercel, AWS Amplify 또는 Netlify 등과 같은 최신 에지 네트워크를 배포할 때 기본적으로 자동 CDN을 얻을 수 있습니다. Next.js는 정적이 될 수 있다면 정적이어야 한다는 전제를 가지고 있습니다. 프로젝트를 처음 시작하고 첫 페이지에서 작업 중이거나 프레임워크의 타이어를 걷어차고 있을 때 모든 것이 정적일 수도 있습니다.
Guillermo: 예를 들어 vercel.com과 같은 고급 요구 사항의 경우에도 Next.js의 자체 사용법은 완전히 정적입니다. 완전히 정적 및 정적 사이트 생성의 조합이므로 모든 마케팅 페이지는 정적이고 블로그는 동적 데이터 소스에서 정적으로 생성된 다음 많은 동적 데이터가 포함된 대시보드를 셸이나 스켈레톤으로 전달할 수 있습니다. , 배포 보기, 프로젝트 보기, 로그 보기 등과 관련된 모든 페이지는 기본적으로 클라이언트 측 JavaScript가 있는 정적 페이지입니다.
Guillermo: 매우 빠른 첫 번째 창 성능이 필요한 모든 것이 이미 사전 렌더링되고, SEO가 필요한 모든 것이 이미 사전 렌더링되고, 극도로 동적인 모든 것이 보안에 대해서만 걱정하면 되기 때문에 매우 유용합니다. 예를 들어 CLI에서 사용하거나 통합에서 사용하는 것과 동일한 API 호출을 사용하는 클라이언트 측의 관점에서 볼 수 있습니다. 완전히 정적인 웹사이트, 운영 비용이 매우 저렴하고 확장성이 매우 뛰어납니다.
Guillermo: 이제 블로그에 필요한 한 가지 특정 사항은 데이터를 매우 빠르게 업데이트하고 싶었다는 것입니다. 우리는 오타를 매우 빠르게 수정하고 전체 빌드가 발생할 때까지 기다리지 않고 싶었습니다. 이것은 Next.js의 매우 중요한 이점입니다. 정적에서 동적으로 넘어갈 때 솔루션 사이에서도 이러한 기능을 제공합니다. . 블로그의 경우 증분 정적 생성을 사용했으므로 기본적으로 기본 콘텐츠가 변경될 때 한 번에 한 페이지씩 다시 빌드할 수 있습니다.
Guillermo: 우리 고객 중 한 명인 Washington Post가 언급한 것처럼 블로그 게시물이 몇 백 개뿐 아니라 많은 블로그 게시물이 항상 생성되고 업데이트되고 있다고 상상해 보십시오. 특히 각 사용자에 대한 콘텐츠 사용자 지정을 시작할 때 전체 SSR을 향해 더 많이. 제가 방금 설명한 복잡성의 여정은 마케팅 페이지가 하나에서 시작하여 블로그에 수천 페이지가, 수만 또는 수백만 페이지가 되었습니다. 이것이 바로 자신의 비즈니스를 가로질러 갈 수 있는 Next.js 여정입니다.
Guillermo: 그런 다음 개발자로 시작하여 더 많은 책임에 대한 더 적은 책임 중에서 선택합니다. SSR 사용을 선택하면 이제 서버에서 코드를 실행하고 클라우드에서 코드를 실행하고 더 많은 책임이 있기 때문입니다. 더 많은 힘. 각 종류의 도구를 사용할 위치를 결정할 수 있다는 사실은 Next의 매우 흥미로운 이점이라고 생각합니다.
Drew: 정적 사이트 생성과 서버 측 렌더링을 결합하는 실용성에서 서버 요소 측면에서 어떻게 작동합니까? 이를 달성하기 위해 Vercel과 같은 전용 플랫폼이 필요합니까, 아니면 더 간단하고 간단하게 수행할 수 있는 것입니까?
Guillermo: Next.js는 개발자 서버를 제공하므로 Next를 다운로드하고 Next Dev를 실행하면 이것이 개발 서버입니다. 개발 서버는 Facebook이 출시한 최신 고속 새로 고침 기술이 있는 것처럼 개발에 분명히 최적화되어 있습니다. ... 실제로 Facebook은 이를 출시하지 않았지만 Facebook은 이를 내부적으로 사용하여 최고의 성능과 가장 안정적인 핫 모듈 교체를 얻습니다. , 기본적으로 입력하고 변경 사항이 화면에 반영되므로 개발자 서버입니다.
Guillermo: then Next는 Next Start라는 프로덕션 서버를 제공하고 Next Start는 자체 호스팅을 위한 프레임워크의 모든 기능을 제공합니다. Vercel의 흥미로운 점은 Next를 배포하면 자동으로 최적화되고 100% 서버리스입니다. 즉, 관리, 확장, 캐싱 및 캐싱 유효성 검사, 제거, 복제, 글로벌 장애 조치 등에 대한 책임이 없습니다. 따라서 Next Start를 직접 실행할 때 수행해야 합니다.
Guillermo: 이는 Next.js의 큰 장점이기도 합니다. 예를 들어, Apple.com은 매우 고급스럽고 엄격한 보안 및 개인 정보 보호 요구 사항으로 인해 자체 호스팅하는 Next.js의 dotcom에 여러 가지 속성, 하위 도메인 및 페이지를 가지고 있습니다. . 반면,washtonpost.com은 Vercel을 사용하기 때문에 우리는 이러한 종류의 광범위한 사용자를 보유하고 있으며 모든 사용자를 지원하게 되어 매우 기쁩니다. 제 생각에 서버리스가 지향하는 방향에 대한 좋은 점은 시간이 지남에 따라 향상되는 가장 최적의 성능 측면에서 두 세계의 장점을 모두 제공할 수 있다는 것입니다. 최고의 개발자 경험은 다음과 같습니다. 모든 종류의 인프라에 대해 걱정할 필요가 없습니다."
Drew: Next.js는 Vercel 팀에서 개발 중인 오픈 소스 프로젝트입니다. Vercel 외부에 다른 기여자가 있습니까?
Guillermo: 예, Google Chrome은 적극적으로 서버 PR을 제출하는 주요 도구이므로 최적화를 돕고 파트너와 함께 테스트합니다. 많은 앱이 있으므로 파트너로서 긴밀하게 참여해야 합니다. Facebook, 우리는 Facebook 팀과 좋은 관계를 유지하고 있습니다. 예를 들어, 빠른 새로 고침, 우리는 이를 처음으로 도입한 React 프레임워크였으며 Facebook에서 React와 빠른 새로 고침을 사용하여 배운 모든 것을 안내하는 데 도움이 되었습니다.
Guillermo: 우리는 전자 상거래 및 콘텐츠를 상상하는 것과 같이 다양한 종류의 사용 사례에서 Next.js 앱을 대규모로 배포한 많은 파트너와 협력합니다. 그런 다음에는 Next.js를 개인적으로 사용하는 수많은 독립 기여자뿐 아니라 교육자 및 대기업의 프론트 인프라 팀 구성원도 있습니다. 이는 매우 광범위한 커뮤니티의 노력입니다.
Drew: 누군가가 Vercel에서 상당한 부분을 개발 중이고 특정 플랫폼에 배포하는 데 일종의 고정이 될 것이라는 우려를 가질 수 있다는 우려처럼 들리지만, 전혀 그렇지 않으며 사이트를 개발하여 Firebase나 Netlify에 배포하거나…
길예르모: 네, 물론입니다. 어떤 면에서는 프론트 엔드 시대의 Kubernetes와 많이 비교하고 싶습니다. 왜냐하면 결국 저는 ... Kubernetes는 Linux 프로세스를 실행해야 할 때 거의 모든 사람이 필요로 하는 것이라고 굳게 믿고 있기 때문입니다. , 당신이 오피니언에 대해 이야기하고 그것이 좋은 기술이라고 말하는 것처럼 이것은 매우 독단적이지 않지만 우리가 일종의 잊은 의견이 있습니다. 하루가 끝나면 컨테이너로 패키지된 Linux 프로그램의 특정 악마를 실행하는 것과 같습니다.
Guillermo: Next는 비슷한 입장에 있습니다. 왜냐하면 우리가 React 구성 요소로서 세계의 보편적인 기본 요소로 간주하는 것은 분명히 독단적이기 때문입니다. 그러나 우리는 많은 기업이 Linux에 끌리는 것처럼 생각합니다. React와 Vue에 대해 같은 것을 보고 있지만 Vue에는 운 좋게도 Nuxt도 있습니다. 이는 매우 멋진 솔루션입니다. 아이디어와 원칙에서 Next와 동일합니다. 우리는 Svelte 생태계를 위한 Sapper와 같은 Nuxt와 같은 Next.js와 같은 플랫폼에 끌리고 있습니다.
Guillermo: 저는 이것이 개방형 플랫폼이어야 한다고 생각합니다. 다시 말하지만, 모든 사람이 이것을 필요로 한다면 전체 산업에 걸쳐 바퀴를 재발명하지 않을 수도 있기 때문입니다. 그렇죠? 우리는 그 입장을 매우 환영합니다. 우리는 사람들이 그것을 배치하고 재구성하고 재구축하고 재배포하는 등의 일을 환영합니다.
Drew: 최근에 Next.js의 새 버전이 출시되었습니다. 제 생각에는 버전 9.5입니다. 해당 릴리스에는 어떤 중요한 변경 사항이 있습니까?
Guillermo: 가장 멋진 점은 앞서 말했듯이 많은 것들이 정적으로 시작되었다가 점점 더 역동적으로 변한다는 것입니다. 그건 그렇고, 이것은 WordPress의 벤처였습니다. 처음에 워드프레스는 정적 파일 데이터베이스 접근 방식을 기반으로 했고, 이후에는 PHP가 점점 더 많은 MySQL로 발전하는 과정에서 설명한 것과 같은 데이터베이스가 필요하게 되었습니다. Next.js 9.5의 좋은 점은 증분 정적 생성을 프로덕션 준비 기능으로 만들어 불안정한 플래그에서 제거했다는 것입니다.
Guillermo: 이 기능을 사용하면 모든 정적 이점을 포기하지 않고 동적 서버 렌더링을 위해 전체를 사용하지 않고도 정적에서 동적으로 전환할 수 있으므로 정적 유형의 유용한 수명이 늘어납니다. 예를 들어 Vercel에서 사용하는 방식은 제가 언급했듯이 블로그가 빌드 시 완전히 사전 렌더링되는 것과 같지만 실제로 몇 분 안에 중요한 발표를 하려고 합니다. 우리는 블로그 게시물의 한 글자를 변경할 때마다 5분에서 10분 정도 빌드를 발행하지 않고도 수정하고, 수정하고, 미리 볼 수 있기를 원합니다.
Guillermo: 증분 정적 생성을 사용하면 한 번에 한 페이지를 다시 작성할 수 있습니다. 사이트의 규모에 따라 몇 분 또는 몇 초가 걸리던 작업이 이제는 밀리초가 걸립니다. 다시 말하지만, 정적의 이점 중 어느 것도 포기할 필요가 없었습니다. 그것이 아마도 내가 Next.js 9.5에서 안정화된 것에 대해 가장 흥분되는 부분일 것입니다. 특히 JS 커뮤니티와 React 커뮤니티, 프레임워크 커뮤니티 및 정적 사이트 생성 커뮤니티가 정적 증분을 만드는 이 유니콘에 대해 이야기하고 있기 때문입니다. a long time, so the fact that Next.js did it, it's being used in production and it's there for everybody to use, I think it's a major, major, major milestone.
Guillermo: There's lots of little DX benefits. One that's really nice in my opinion is Next.js, as I said, has a page system. You would argue, “Okay, so let's say that I'm uber.com and I've decided to migrate on Next.js, do I need to migrate every URL inside over to Next.js in order to go live?” This has become a pretty important concern for us, because lots of people choose Next.js, but they already are running big things, so how do you reconcile the two?
Guillermo: One of the things that Next.js allows you to do in 9.5 is you can say, “I want to handle all new pages that I created with Next.js with Next.js, and the rest I want to hand off to a legacy system.” That allows you incremental, incremental is the keyword here today, incremental adoption of Next.js. You can sort of begin to strangle your legacy application with your Next.js optimized application one page at a time, when you deploy and you introduce in your Next.js page, it gets handled by Next. If it doesn't match the Next.js routing system, it goes to the legacy system.
Drew: That sounds incredibly powerful, and the incremental rendering piece of that, I can think of several projects immediately that would really benefit that have maybe 30-minute build times for fixing a typo, as you say. That sort of technology is a big change.
Guillermo: We talked to one of the largest, I believe, use cases in Jamstack in the wild, and it was basically a documentation website and their build times were 40 minutes. We're doing a lot in this space, by the way, like we're making pre-rendering a lot faster as well. One of my intuitions for years to come is that as platforms get better, as the primitives get better, as the build pipelines get better we're going to continue to extend the useful lifetime of statics. Like what ended up taking 40 minutes is going to take four.
Guillermo: A great example is we're rolling out an incremental build cache, as well, system. I sort of pre-announced it on Twitter the other day, we're already seeing 5.5 times faster incremental builds. One of the things that I like about Jamstack is that the core tenet is pre-render as much as possible. I do think that's extremely valuable, because when you're pre-rendering you're not rendering just in time at runtime. Like what otherwise the visitor would incur in in terms of rendering costs on the server gets transferred to build time.
Guillermo: One of the most exciting things that's coming to Next is that without you doing anything as well, the build process is also getting faster. On the Vercel side, we're also taking advantage of some new cloud technology to make pre-rendering a lot faster as well. I think we're always going to live in this hybrid world, but as technology gets better, build times will get better, pre-rendering will get better and faster, and then you'll have more and more opportunities to do kind of a mix of the two.
Drew: Sounds like there's some really exciting things coming in the future for Next.js. Is there anything else we should know before we sort of go away and get started working with Next.js?
Guillermo: Yeah. I think for a lot of people for whom this is new, you can go to nextjs.org/learn, it'll walk you through building your first small static site with Next.js, and then it'll walk you through the journey of adding more and more complexity over time, so it's a really fun tutorial. I recommend also staying tuned for our announcement that I was just starting to share on twitter.com/vercel, where we share a lot of Next.js news. Specifically we highlight a lot of the work that's being done on our open source projects and our community projects and so on. For myself as well, twitter.com/rauchg if you want to stay on top of our thoughts on the ecosystem.
Drew: I've been learning all about Next.js today, what have you been learning about lately, Guillermo?
Guillermo: As a random tangent that I've been learning about, I decided to study more economics, so I've been really concerned with like what is the next big thing that's coming in terms of enabling people at scale to live better lives. I think we're going through a transition period, especially in the US, of noticing that a lot of the institutions that people were “banking on”, like the education system, like the healthcare system, a lot of those, like where you live and whether you're going to own a house or rent and things like that, a lot of these things are changing, they have changed rapidly, and people have lost their compass.
Guillermo: Things like, “Oh, should I go to college? Should I get a student loan?” and things like that, and there is a case to be made for capitalism 3.0, and there is a case to be made for next level of evolution in social and economic systems. I've been just trying to expand my horizons in learning a lot more about what could be next, no pun intended. I've found there's lots of great materials and lots of great books. A lot of people have been thinking about this problem, and there is lots of interesting solutions in the making.
드류: 흥미롭네요. If you, dear listener, would like to hear more from Guillermo, you can find him on Twitter at @RauchG, and you can find more about Next.js and keep up to date with everything that goes on in that space at nextjs.org. Thanks for joining us today, Guillermo. 이별의 말이 있나요?
Guillermo: No, thank you for having me.