[Next.js] You might not need Next.js

서론

next.js가 필요할까?

우리는 next.js에서 어떤 기능을 기능을 사용중인가?
어떤 기술적 이점을 누리고 있는가?

 

Next.js 메인 기능

1. 최적화
2. SSR

라우팅

파일 시스템 기반 라우팅 기능을 제공
레이아웃, 중첩 라우팅, 로딩상태, 에러 상태를 파일 시스템으로 표현할 수 있습니다.

렌더링

클라이언트 렌더링, 서버사이드 렌더링, 정적 렌더링 제공

데이터페칭

fetch API를 이용한 요청 캐싱 기능 제공으로 빠른 응답을 기대할 수 있다.

최적화

이미지 폰트 스크립트 최적화 

미들웨어

인증처리, 요청 데이터 검증(헤더,쿠키)

 

 

폐쇄적인 B2B 서비스에서 Next.js의 기술적 이점

1. SSR

초기 렌더링 속도를 높일 수있다.

RSC

2. SSG

정적 페이지를 빠르게 로딩할 수 있다.

3. 성능 최적화

이미지 최적화, 폰트 최적화

4. API router

SSR이 반드시 필요한가?

 

Server Side Rendering란?

1. 빠른 초기 로딩

- 렌더링을 서버에서 담당하기 때문에 클라이언트 네트워크 환경에 영향을 덜받는다.

- 렌더링된 HTML이 전송되기 때문에 FCP가 빠르다

2. SEO

크롤러가 HTML를 수집할 수 있다.

3. 보안

서버에서 실행되기 때문에 보안이 중요한 로직을 안전하게 관리할 수 있다.
비공개 데이터를 보호할 수 있다.

4.클라이언트 번들 경량

RSC를 활용하면 자바스크립트 번들 크기를 줄일 수 있다.

 

그래서 SSR이 필요할까?

중요한 경우

1. SEO가 중요한 콘턴츠 중심의 웹사이트( 블로그, 뉴스, 이커머스)

2. 초기 로딩이 중요한 경우 (랜딩페이지, 마케팅 사이트)

3. 소셜 미디어 공유 최적화 (링크 프리뷰)

덜 중요한 경우

1. 검색엔진에 노출될 필요가 없는 비공개 애플리케이션(ex. 대시보드, 관리자 패널)

2. 동적 업데이트가 빈번한 애플리케이션(실시간 협업도구, 채팅앱)

3. 정적 사이트 생성으로 충분한 경우 (콘텐츠 변경이 적은 경우)

4. CSR이 비중이 높은 애플리케이션 (사진 편집 도구, https://pixlr.com/kr/editor/)

5. 모바일 앱의 웹

 

Next.js에서 사용중인 기능

1. rewites

주소에 보여지는 경로를 다르게 표현하고 싶을 때 사용하는 옵션.
현재 , 네트워크 클라이언트의 base 경로를 지정하는 방식으로 사용되고 있음. 

이 설정은 각 apiClient의 기본설정을 통해 적용할 수 있다.

async rewrites() {
    return [
        {
            source: '/graphql',
            destination: `${process.env.NEXT_PUBLIC_BACKEND_GRAPHQL_API}${process.env.NEXT_PUBLIC_ENDPOINT}`,
        },
        {
            source: '/v1/:path*',
            destination: `${process.env.NEXT_PUBLIC_REST_API}`,
        },
    ];
},

2.  redirects

경로의 index page를 지정하는 방식으로 사용하고 있음.
이 부분은 컴포넌트단에서 처리 가능하다.

async redirects() {
    return [
        { source: '/transport', destination: '/transport/list', permanent: true },
        { source: '/drive', destination: '/drive/list', permanent: true },
        { source: '/device', destination: '/device/list', permanent: true },
    ];
},

결론: 이점은 존재하지만 Next.js가 필수는 아니다

이미지 최적화, 폰트 최적화, 파일 시스템 베이스 라우팅등 다양한 편의 기능을 제공하지만 가장 핵심적 기능은 역시 SSR입니다. 그렇기 때문에 자연 유입이 중요한 B2C가 아닌 B2B에서는 Next.js가 필수라 할 수 없습니다. 

 

제품의 핵심 요구 조건은 무엇인지?

• 하나의 도메인에서 여러가지 서비스를 서빙한다.
• 서비스간 리소스를 공유할 수 있어야 한다
• 앱 볼륨이 증가함에 따라 발생하는 빌드 및 배포 시간 증가를 해결한다.
• 각 앱은 의존 기업에 따라. 요구조건이 독립적으로 변경될 수 있다.
  • 각 앱의 변경 사항이 상호간 간섭이 발생하면 안 된다.
  • 코드가 격리되어야 한다
  • 각 서비스별 독립적 배포와 롤백이 가능해야 한다.
  • 독립적 서비스의 기능 배포가 다른 서비스에 영향을 끼쳐서는 안 된다.
  • 오션 코닝에서 A기능 배포후 용마에서 B기능을 배포했는데 오션 코닝에서 버그가 발생한 경우
    A기능에 대한 롤백이 용마 B기능에 영향없음을 보장하기 어렵다.

MFA, Micro Frontend Architecture

기획 출처에 따라 코드가 격리되어야 한다.

서로 서비스별 코드 베이스를 분리하여 독립 개발, 독립 배포를 보장한다.

비슷한 요구 조건을 가지고 있지만 고객사에 따라서 어떤 기능이 추가될 지 보장할 수 없다.

따라서 고객사에 따라 코드 베이스가 격리되어야 한다. 모든 고객사의 요구조건을 동시에 충족하는 컴포넌트를 만들고 관리할 수 없다. 특정 시점에 모든 조건을 포괄하는 모듈을 만들더라도 이 모듈이 지속되기 어렵다.

 

ex. 오션 코닝을 배포해도 물리적으로 격리되어 있기 때문에 오션과 격리되어 있기 때문에 영향이 가지 않는다.

 

배포 범위가 줄어든다.

모놀리식 앱은 하위 서비스가 늘어감에 따라 빌드 및 배포 시간이 늘어난다.
MFA의 구조에서는 격리된 코드베이스별 배포가 가능하기 때문에 배포시간이 줄어든다.ㄷ

리소스 재활용할 수 있다.

공용 리소스는 모노 레포로 관리할 수 있다. 

인증 로직은 host앱에서 담당한다.

 

Next.js에서 MFA를 적용할 수 있을까?

Multi Zones

멀티존은 하나의 커다란 애플리케이션을 작은 마이크로 앱으로 나누는 마이크로 프론트엔드의 접근법중 하나입니다.
이 방법은 애플리케니션이 다른 페이지와 연관성이 없는 페이지를 단일 도메인으로 서빙할 때 유용합니다. 

멀티존은 next.js의 rewrites 기능을 활용하여 독립적으로 배포된 next.js앱을 하나의 앱처럼 보이도록 구성할 수 있습니다.

 

 

- 자원이 중복 로딩된다.

- 코드 베이스를 공유할 수 없다

- 각 서비스가 완벽하게 독립적이다

- 개별적 앱이 SSR을 수행할 수 있다.

const { BLOG_URL } = process.env;

/** @type {import('next').NextConfig} */
const nextConfig = {
  async rewrites() {
    return [
      {
        source: "/blog",
        destination: `${BLOG_URL}/blog`,
      },
      {
        source: "/blog/:path+",
        destination: `${BLOG_URL}/blog/:path+`,
      },
    ];
  },
};

module.exports = nextConfig;

https://nextjs.org/docs/pages/building-your-application/deploying/multi-zones

Deploying: Multi Zones | Next.js

https://github.com/vercel/next.js/tree/canary/examples/with-zones

next.js/examples/with-zones at canary · vercel/next.js

https://stackblitz.com/github/vercel/next.js/tree/canary/examples/with-zones?file=README.md

Next.js With Zones Example - StackBlitz

모듈 페더레이션

모듈 페더레이션은 Webpack 5에서 도입된 기능으로, 여러 개의 독립적인 빌드 결과물을 런타임에 동적으로 로드하고 공유할 수 있게 해줍니다. 리액트 마이크로 프론트엔드 아키텍처에서 이를 활용하면, 각 마이크로 프론트엔드를 독립적으로 개발하고 배포하면서도 런타임에 하나의 애플리케이션처럼 통합할 수 있습니다

• 독립적 개발/배포
  각 팀이 자신의 마이크로 프론트엔드를 독립적 환경에서 개발하고 배포할 수 있습니다.
  분리된 서비스간의 기능 개발이 자유롭고 각 앱의 배포주기에 영향을 받지 않는다.
• 코드 공유
  공통 라이브러리나 컴포넌트를 여러 마이크로 프론트엔드 간에 쉽게 공유할 수 있습니다.
• 확장성
  앱의 볼륨이 커짐에 따라 발생하는 복잡도 증가로부터 자유롭다
  특정 서비스의 독립적 확장이 가능하다.(독립적 스케일링)
• 서로 다른 도멘인을 통합할 수 있다
  ex) 토스 (은행, 증권, 보험, 부동산)

next.js-mf

While NextFederationPlugin "works", Next.js is staunchly opposed to the technology and Next is very difficult to support.
This plugin attempts to make the experience as seamless as possible, but it is not perfect.
We are building a micro-frontend ecosystem that is much more powerful than Next.js, built to support micro-frontends from the ground up.

https://www.npmjs.com/package/@module-federation/nextjs-mf

@module-federation/nextjs-mf

• next앱간 컴포넌트를 공유할 수 있다.
• 특정 페이지 혹은 컴포넌트를 공유하는 경우 적합하다.
• next.js에서는 이러한 통합에 부정적 입장, 즉 차기 버전에서 런타임 통합 방식의 지원이 불투명하다
• 라우팅이 host 앱에 의존적이다.

React-MF

리액트 애플리케이션에서 모듈 페더레이션을 통한 마이크로프론트엔드 구현 방법

• 하위 경로에 대한 라우팅이 마이크로 앱에 의존한다.
  • cupang/* 하위의 모든 라우트를 cupang앱에서 결정할 수 있다.
• host앱의 자원을 활용할 수 있다.
  • 인증, 레이아웃
• 마이크로 앱간 독립적 기술 선택이 가능하다.
• host앱과 remote app간 통신이 가능하다 (이벤트버스, storage API, 커스텀이벤트)
• 사례. flex(https://flex.team/blog/2023/09/14/micro-frontends-architecture/)

 

 

 

 

참고

 

https://medium.com/@trustyoo86/module-federation%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-next-js-%EC%95%B1%EA%B0%84%EC%9D%98-%EA%B0%9C%EB%B0%9C-%ED%9A%A8%EC%9C%A8%EC%84%B1%EC%9D%84-%EB%86%92%EC%9D%B4%EA%B8%B0-2-f27467947e78

Module Federation을 이용하여 Next.js 앱간의 개발 효율성을 높이기(2)

 

https://fe-developers.kakaoent.com/2022/220623-webpack-module-federation/

Webpack Module Federation 도입 전에 알아야 할 것들 | 카카오엔터테인먼트 FE 기술블로그

 

https://www.youtube.com/watch?v=-jYSGaPAEHE

 

https://deview.kr/data/deview/session/attach/[116]SSR%ED%99%98%EA%B2%BD%EC%97%90%EC%84%9C%EC%9D%98%20Micro-Frontend%20%EA%B5%AC%ED%98%84%EA%B3%BC%20%ED%8D%BC%ED%8F%AC%EB%A8%BC%EC%8A%A4%20%ED%96%A5%EC%83%81%EC%9D%84%20%EC%9C%84%ED%95%9C%20%EC%BA%90%EC%8B%9C%EC%A0%84%EB%9E%B5.pdf

 

https://www.youtube.com/watch?v=VnJLFwnuLV4