2022년 가장 인기 있는 Node.js 프레임워크

Express.js는 Node.js만큼 오래되었으며 Express는 여전히 경이적인 백엔드 프레임워크이지만 새로운 유형의 도구와 키트가 그 흔적을 남기고 있습니다.

가장 주목할만한 것은 메타 프레임워크로 트렌드가 바뀌고 있다는 점입니다. 여기서 React와 같은 인기 있는 프레임워크는 풀 스택 개발을 지원하도록 용도가 변경됩니다. 이 접근 방식의 장점은 특정 프레임워크에서 전문 지식을 유지하면서 동시에 백엔드 작업을 수행할 수 있다는 것입니다. 즉, 전체 스택 개발을 수행합니다.

이 데이터의 출처는 어떻게 됩니까?

모든 데이터는 자바스크립트 현황, 스택 오버플로 개발자 설문조사 및 다양한 프로젝트에 대한 개인적인 경험과 같은 설문조사에서 제공되었습니다. GitHub 별이 가장 많은 Node.js 프레임워크를 기반으로 한 리뷰가 아닙니다.

대신 작년에 얻은 별의 수를 비교했습니다. 이것은 특정 프로젝트가 얼마나 활동적이며 개발자가 이에 얼마나 잘 대응하는지에 대한 확실한 지표입니다.

 실시간 환경에서 이러한 프레임워크를 시도하고 싶다면 개발자를 위한 호스팅 플랫폼에 대한 제 기사를 확인하세요. 각 플랫폼에는 무료 요금제가 있으며 거의 ​​모든 플랫폼에서 GitHub 저장소를 가져와 직접 호스팅할 수 있습니다. 

예를 들어 어떤 리포지토리를 가져와도 몇 분 만에 라이브로 사용할 수 있습니다.

현재 Node.js 트렌드

이 글에서 언급한 많은 프레임워크가 프론트엔드 프레임워크를 기반으로 한다는 것을 이 게시물 전체에서 알 수 있을 것입니다. 이것은 메타 프레임워크 라고도 합니다. 그렇다면 이 문제는 무엇이며 왜 이 접근 방식을 사용합니까?

React와 같은 것을 보면 페이지를 렌더링하는 방식이 CSR(클라이언트 측 렌더링)을 통해 수행됩니다. 요청이 이루어지면 브라우저에는 실제 페이지 내용이 없는 기본 HTML 파일이 제공됩니다. 따라서 브라우저는 페이지 콘텐츠가 포함된 JavaScript 문서를 가져오기 위해 두 번째 여행을 한 다음 전달하고 실제 페이지를 렌더링합니다.

그리고 이것은 사용자가 페이지와 상호 작용할 때마다 계속 발생합니다. HTML은 그대로 유지되지만 다른 경로 요청은 사용자가 원하는 콘텐츠를 렌더링하기 위해 브라우저가 계속 앞뒤로 이동해야 함을 의미합니다.

이는 종종 SPA 또는 단일 페이지 애플리케이션이라고도 합니다.

여기에 CSR 접근 방식의 단점이 있습니다.

• 캐싱 – 모든 페이지 콘텐츠가 JavaScript를 통해 렌더링되기 때문에 페이지에 캐시할 수 있는 실제 HTML 콘텐츠가 없습니다.
• SEO – 크롤러가 "스마트"해지고 있지만 로봇이 JavaScript에만 의존하는 콘텐츠 색인을 생성하는 데는 결정적인 문제가 있습니다.
• 렌더링 – 모든 JavaScript가 로드를 완료할 때까지 초기 렌더링은 느리고 응답하지 않는 경우가 많습니다.

따라서 이러한 맥락에서 Next 및 Nuxt와 같은 프레임워크 이면의 아이디어는 프론트엔드 프레임워크를 사용하되 Node.js를 통해 SSR(Server-Side Rendering)을 제공하는 것입니다.

SSR에 대해 말하면서 - Nick Johnstone 은 "서버 측 렌더링의 터무니없는 복잡성"이라는 제목의 흥미로운 요지를 발표했습니다. 그리고 해당 주제에 대해 상당히 많은 토론이 있는 해당 Hacker News 스레드도 있습니다. 가까운 장래에 크게 바뀌지는 않겠지만 이러한 개념 중 일부는 일부 프레임워크가 작동하는 방식에 상당한 변화를 가져올 것이라고 믿습니다.

#1 – Next.js

React Framework 이상 – Next.js는 엄청나게 빠른 개발 속도 덕분에 계속해서 인기를 얻고 있습니다. Next.js 10에서 Next.js 12로 가는 데 1년밖에 걸리지 않았습니다.

Next.js의 핵심 개념은 React를 기반으로 사용하지만 자체 사양을 통해 모든 서버 측 렌더링 구조를 수행한다는 것입니다. 렌더링이 서버 측에서 수행되기 때문에 클라이언트 측에서 페이지를 렌더링할 필요가 없으므로 상당한 성능 이점과 관련 SEO를 제공합니다.

Next가 대량 채택된 이유 중 하나는 자체 백엔드를 구축할 필요가 없기 때문입니다. 동시에 앱의 성능을 즉시 최적화할 수 있는 의미 있는 방법을 제공합니다. Vercel은 그것을 유지합니다.

#2 – 둥지

NestJS는 조용히 백엔드 커뮤니티로부터 상당한 승인을 받았습니다. Nest 뒤에 있는 주요 철학 중 하나는 React와 같은 프레임워크가 프론트엔드 개발을 가속화하는 반면, 그러한 프레임워크는 애플리케이션 아키텍처 문제를 해결하기 위해 고군분투한다는 것입니다. Nest는 아키텍처 우선 접근 방식을 통해 이 문제를 해결합니다.

물론 백엔드에만 해당됩니다.

Nest는 Angular에서 영감을 받은 세 가지 핵심 구성 요소인 Controllers , Providers 및 Modules 를 기반으로 합니다. 모듈 의 사용은 Nest가 복잡한 애플리케이션 계층의 문제를 해결하려고 시도하는 방법입니다. 각 구성 요소는 자체 컨트롤러, 종속성 및 특정 공급자를 구성하는 별도의 모듈로 분류할 수 있습니다.

#3 – 스트라피

헤드리스는 현재 프론트 엔드 내러티브에서 모든 분노입니다. 그리고 Strapi는 최고의 Headless CMS 프레임워크 중 하나로 자리매김하는 데 큰 역할을 했습니다.

그렇다면 스트라피는 무엇일까요? 가장 실용적인 측면에서, Strapi는 프런트 엔드 애플리케이션의 백엔드입니다. 어떤 의미에서, Stripi는 API를 통해 대부분의 작업을 수행할 수 있기 때문에 Express와 같은 프레임워크를 배울 필요가 없습니다.

여기에는 사용자 정의 UI, GraphQL 및 REST를 위한 즉석 엔드포인트, 사용자 관리(역할 등), 구축할 수 있는 별도의 플러그인 인터페이스를 통한 콘텐츠 관리가 포함됩니다. Strapi는 완전히 프레임워크에 구애받지 않으며 거의 ​​모든 언어, 프레임워크 또는 프론트엔드 라이브러리와 통합됩니다.

#4 – 리믹스

Remix는 React Router를 만든 사람들이 만든 풀 스택 프레임워크입니다.

Remix는 최근 몇 년 동안 가장 빠르게 성장하는 풀 스택 프레임워크 중 하나라고 생각합니다. 어떻게 된 거죠? 첫째, Remix는 일반적인 상태 코드 및 사용자 상호 작용을 위한 간결한 API를 제공하여 Web Standards와 가능한 한 많이 통합하려고 합니다.

기존 프레임워크와 달리 Remix는 워터폴(컴포넌트) 기반 구조를 생성하지 않습니다. 대신 데이터가 서버 측에서 병렬로 로드된 다음 HTML 페이지로 제공됩니다. 이는 또한 사용자가 JavaScript를 비활성화한 경우 JavaScript 기반 기능(예: 양식 제출)으로 인해 사이트가 중단되지 않습니다.

#5 – Nuxt

Nuxt 3(Vue 3용)는 오픈 베타 버전입니다. 계속 지켜봐 주세요.

Nuxt는 강력한 애플리케이션을 구축하기 위한 전체 스택 프레임워크로 Vue를 기반으로 합니다. 풀스택 Vue 개발 경험을 획기적으로 개선하기 위해 만들어진 메타 프레임워크이기도 합니다. Nuxt는 SSR, SPA 및 정적 생성 페이지를 지원합니다.

Vue 개발자의 주요 이점은 Nuxt가 뷰를 미리 렌더링하고 정적 파일로 제공할 수 있다는 것입니다. 이것은 자연스럽게 SEO 최적화에 대한 훌륭한 결과를 가져오고 상호 작용에서 상당한 향상을 제공합니다. 그러나 몇 가지 단점도 있습니다.

Vue에는 지속적인 클라이언트 측 채널이 있지만 Nuxt에는 없습니다. 따라서 Nuxt가 이미 페이지를 렌더링한 후 DOM과 상호 작용하는 것이 어려울 수 있습니다.

#6 – SvelteKit

Svelte는 현재 프론트 엔드 시대에서 멋진 아이 상태를 가지고 있으며 팀은 Sapper를 기반으로(대체하는) 전체 스택 프레임워크인 SvelteKit을 개발 중입니다. SvelteKit은 복잡한 파일 기반 라우팅 시스템으로 두드러집니다.

SvelteKit의 주요 목표는 보다 일반적인 병목 현상을 제거하여 웹 개발을 가속화하는 것입니다. Snowpack, Vite 및 기타 외부 도구를 구현하여 SvelteKit은 기능이 풍부한 개발 경험을 제공할 수 있습니다.

마지막으로 SvelteKit은 Hydration 프로세스를 구현합니다. 서버 측에서 렌더링된 DOM 요소에 대한 활성 상태를 유지하는 기능.

#7 – Fastify

Fastify 프레임워크는 성능에 관한 것이며 개별 벤치마크에 따르면 초당 최대 60,000개의 요청을 처리할 수 있습니다. 후크 및 플러그인을 통해 Fastify를 확장할 수 있습니다(이미 훌륭한 도구 위에 있음). 그리고 TypeScript 우선 프레임워크는 아니지만 Fastify 는 TypeScript를 지원합니다.

플러그인에 대해 말하면 많은 Fastify 개발이 플러그인 을 통해 발생합니다. Fastify에는 커뮤니티 제작 및 Fastify 팀에서 만든 플러그인 모두에 대한 공식 리포지토리가 있습니다. 플러그인 이면의 아이디어는 깨끗한 시스템 아키텍처를 제공하고 대체 프레임워크로 이동할 필요가 없다는 것입니다. 따라서 Fastify는 강력한 실시간 성능으로 오버헤드가 낮은 API를 구축하는 데 특히 유용합니다.

#8 - 레드우드

API가 마음에 드시나요? JAMStack 앱이 마음에 드시나요? 대답이 예라면 RedwoodJS를 사랑하게 될 것입니다. 그것은 많은 현대 기술을 활용하는 풀 스택 웹 앱 프레임워크입니다. 그리고 이러한 기술에는 GraphQL, Prisma, Storybook 및 Jest가 포함됩니다. Redwood의 프론트 엔드는 React를 기반으로 하며, TypeScript도 완벽하게 지원합니다.

#9 – 익스프레스

Express가 은혜에서 떨어졌습니까? 정확히. 이 프레임워크는 여전히 매우 인기 있고 사랑받고 있지만 다른 주요 플레이어만큼 많지는 않습니다. 수년간 Express로 작업한 팀의 경우 근본적인 문제가 없기 때문에 다른 것으로 전환하는 것은 의미가 없습니다. 많은 프레임워크가 여전히 Express를 기반 으로 합니다.

#10 – 아도니스

Adonis는 Node.js용으로 구축된 TypeScript 최초의 백엔드 MVC 프레임워크입니다. Adonis가 스스로를 백엔드 프레임워크로 설명함에도 불구하고 이를 사용하여 전체 스택 개발을 수행하는 것만큼 괜찮습니다.

개발자가 Adonis를 좋아하는 주요 이유 중 하나는 TypeScript에 대한 기본 지원입니다.

또한 ORM(Object Relational-Mapping), 강력한 보안 사례 및 따르기 쉬운 문서에 대한 지원도 제공됩니다.

마지막으로 Adonis는 기본 수준에서 Node.js 생태계와 통합되므로 Node 개발에 대한 사전 경험이 있어야 합니다.

#11 – 키스톤

이 목록의 마지막 Node.js 프레임워크는 Keystone입니다. Express와 마찬가지로 거의 첫날부터 사용되었습니다. 이를 통해 Keystone은 개발자 친화적인 경험을 만들기 위한 구체적인 도구 및 통합을 제공하는 성숙한 프레임워크가 됩니다.

Keystone의 일부 주목할만한 기능(그 중 많은 부분이 수년에 걸쳐 개선됨)에는 GraphQL API를 통해 자동화된 CRUD가 포함되며, 이를 추가로 확장할 수 있습니다. 또한 자신의 React.js 구성 요소를 만들고 구현할 수 있습니다.

Keystone은 다양한 개발 분야에서 사용되며 모바일 앱, 실용적인 웹사이트, 전자 상거래 상점 등에서 잘 작동합니다.

Meta, 네이티브, 그리고 Headless의 핀치

마지막으로 이와 같은 개요를 만든 이후로 꽤 오랜 시간이 걸렸습니다. 그 당시에는 상황이 훨씬 간단했고 Compound와 Locomotive는 어디에도 없지만 Keystone과 Express가 시간의 테스트를 통과하는 것을 보는 것은 좋습니다.

나는 또한 Node.js를 둘러싸고 꽤 많은 소문이 있다고 말할 수 있습니다. 나는 일부 사람들이 불행하고 그것에 갇혀 있다고 생각합니다. 그리고 패키지가 소규모 프로젝트에 불필요한 번들 크기의 더미를 계속 추가함에 따라 패키지 관리자(npm)에 대한 아이디어도 낡아지기 시작했습니다.

그러나 어떤 경우이든 각 프레임워크의 인기는 그 자체로 의미가 있습니다. 전반적으로 개발자들은 메타 프레임워크로 작업하는 것을 기쁘게 생각하며 이는 풀 스택 개발도 간소화한다는 사실과 관련이 있을 수 있습니다. 이렇게 하면 새로 선호하는 프레임워크를 처음부터 다시 배울 필요가 거의 없습니다.