TIR ##4 [Why All React Developers Should Try Next.js]

 

학습을 목적으로 Medium에서 읽은 글을 번역한 글입니다.
번역이 완벽하지 않을 수 있고,
직역하기보다는 문맥에 맞추어 자연스럽게 정리하려고 했습니다.
오류나, 개선하면 좋을 부분들에 대한 피드백은 언제나 환영합니다.😁

 

 

Why All React Developers Should Try Next.js

만약 이 글이 당신의 흥미를 끌었다면 당신은 이미 리액트를 다룰 줄 알고 next.js에 대해 들어봤을 것이다.

만약 next.js가 아직도 당신에게 그저 library에 불과하다면 당신은 아직도 틀에서 벗어나지 못한 것이다.

---

📌 what is it about?

Next.js는 Vercel에 의해 만들어진 리액트 라이브러리이다.

만약 Vue에 대한 경험이 있다면 Nuxt.js와 비교해 볼 수 있다.

수많은 부가기능들을 표준 리액트에서 경험할 수 있다.

 

Next.js의 주 기능들은 이렇다.

1. 최적화 (Optimization)
2. Built-in API
3. Built-in router
4. 서버사이드 렌더링(Server-side rendering)

---

📌 What parts of Next.js are optimized?

정확한 질문은 아마 ‘어떠한 부분이 최적화되지 않았나요? ‘일 것이다.

 

Next.js는 이미 충분히 빠른 리액트를 관리하여 저세상 수준의 속도로 만들어 준다.

만약 가장 대두되는 컴포넌트 최적화 기능을 꼽으라면 주저 없이 Next-Image component를 고를 것이다.

 

리액트에서의 Image 컴포넌트는 HTML의 img태그를 확장한 것이다.

 

만약 Next.js에서 이미지 최적화를 사용한다면 사용한 이미지 파일은 자동으로  lazy loading 될 것이다.

고로, 페이지에서 해당 이미지가 필요한 상황에서만 파일을 받아와 그려낼(렌더링)것이다.

이는 이미지 파일이 페이지의 성능에 영향을 끼치는 것을 방지해준다.

---

📌 Built-In API?

제목을 제대로 본 게 맞다.

Next.js는 built-in API-routes를 가지고 있는 프론트엔드 라이브러리이다.

이 말은, 기술적으로, 하나의 프로젝트에서 혼자서 애플리케이션의 프론트, 백 모든 부분의 코드를 작성할 수 있다는

것을 뜻한다.

 

한 가지 주의할 점은, API-routes에는 당신에게 필요한 몇 가지 기본적인 기능이 빠져있을 수 있다. 

예를 들어, API-routes는 same-origin(동일한 출처)에서의 응답만을 수용하기 때문에 애플리케이션

바깥(출처가 다른)에서의 요청은 접근할 수 없다.

---

📌 Built-in router

만약 리액트를 사용해봤다면 routes와 pathname들을 관리하는 것이 얼마나 고통스러운지 알 수 있다.

Next.js는 자동으로 router를 생성해주는 기능을 제공해줌으로써 이러한 문제점을 해결한다.

 

처음 Next.js프로젝트를 실행하게 되면 pages/라는 특별한 디렉터리가 생길 것이다.

해당 폴더에 존재하는 모든 .jsx, .tsx파일은 각각 새로운 route가 되게 된다!

예를 들어, /pages/hello.jsx라는 경로를 가진 파일이 있다고 가정하자.

Next.js는 자동으로 /hello라는 새로운 route를 만들어 줄 것이다.

 

route parameter와 sub-routes를 이용하여 꽤 복잡한 설정도 구성할 수 있다.

---

📌 Server-side rendered

이 기능은 개인적으로 이해하는데 시간이 조금 걸렸지만 한번 감을 잡게 되면 놀라운 기능이라는 것을 알게 될 것이다.

보통 리액트는 client-side에서 렌더링을 실행한다.

이 뜻은, 클라이언트 측에서 모든 데이터를 받아와 그려줘야 한다는 것인데, 이러한 방법에는 몇 가지 장점들과

주의할 점들이 있다. 

 

페이지의 첫 로딩은 받아와야 할 데이터가 없기 때문에 더 빠르겠지만, SEO(search engine optimize)를 망쳐,

검색엔진의 크롤러가 당신의 페이지의 콘텐츠들을 제대로 정의할 수 없다는 단점도 있다. 

 

반면에 Next.js는 페이지를 쉽게 server side에서 렌더링 할 수 있도록 만들어 준다.

첫 로딩에 시간이 조금 걸릴 수는 있지만, 사용자들이 완성되지 않은 페이지를 먼저 보지 않아도 되고, 

페이지의 SEO도 잘 진행될 것이다.

 

이러한 기능을 위해 Next.js에서는 세 가지 method를 제공한다.

 

🎲  getStaticProps

이러한 경우에 getStaticProps를 사용하는 게 좋다.

• 페이지를 렌더 하는데 필요한 데이터를 사용자의 요청보다 앞서 빌드 단계에서 접근할 수 있다.
• 데이터는 headless CMS에서 받게 된다.
• 데이터는 사용자별이 아닌 공개적으로 캐시 될 수 있다.
• 페이지는 미리 렌더 되어야 하고(seo를 위해) 아주 빨라야 한다.
• getStaticProps는 HTML과 JSON파일을 생성하게 되는데 둘 다 성능을 위해 CDN에 캐시 될 수 있다.

요약하자면, getStaticProps는 외부에서 받아와야 하지만 모든 사용자에게 동일한, 즉 캐시 될 수 있는 데이터에 사용한다.

 

🎲  getStaticPaths

dynamic routes를 사용하는 정적 pre-rendering page에서는 getStaticPaths를 사용하는 것이 좋다.

 

요약하자면 페이지에서 dynamic path를 렌더링 할 경우 getStaticPaths를 사용한다.

 

🎲  getServerSideProps

getServerSideProps는 요청 시 데이터를 받아오는 페이지를 미리 렌더링 해야 할 경우에만 사용한다.

서버에서 모든 요청에 대한 응답을 계산해야 하기 때문에 Time to first byte (TTFB)는 getStaticProps보다 늦을 것이고, 결과는 부가적인 설정 없이는 CDN에 캐시 되지 않을 것이다.

 

getServerSideProps는 getStaticProps와 쉽게 헷갈린다.

 

요약하자면, getServerSideProps는 각 사용자마다 다른 데이터를 위해, getStaitcProps는 모든 사용자에게 같은 데이터를 위해 사용한다.

---

원문

https://javascript.plainenglish.io/why-all-react-developers-should-try-next-js-a7db2b0eb838

Why All React Developers Should Try Next.js

---