👉 Front-end

🎈 Webpack이란 무엇인가?

웹 사이트를 구성할 때 js, css, images 파일등 수 많은 파일들이 모여 웹사이트를 구성하게 됩니다.
따라서 웹 사이트에 접속했을 때 굉장히 많은 파일이 다운로드될 수 있는데 이것에 비례하여 서버의 자원을 소모하고 웹사이트가 느리게 로딩됩니다.
또한, 많은 자바스크립트 패키지등을 사용하다보면 각각의 서로의 다른 패키지들이 서로 같은 이름이나 함수를 사용하게 되면서 애플리케이션이 깨지게 되는데 이러한 현상을 해결하기 위해 나온 개념이 묶는다는 개념의 번들러가 등장하게 되었습니다.

webpack, broserify, parcel등과 같은 도구들이 번들러에 속합니다.

웹팩은 모던 자바스크립트 애플리케이션을 위한 정적 모듈러입니다.
모듈 번들러란 웹 애플리케이션을 구성하는 자원(HTML, CSS, JavaScript, images 등)을 모두 각각의 모듈로 보고 이를 조합해서 병합된 하나의 결과물을 만드는 도구를 의미합니다. 간단하게 표현하자면 웹팩이란 여러 파일을 하나 이상의 파일로 합쳐주는 자바스크립트 번들러입니다.

이러한 웹팩은 왜 등장하게 되었을까요?
위에서 언급하였듯 수 많은 파일이 모여 하나의 웹 사이트를 구성하게 됩니다. 인터넷의 발전으로 웹 어플리케이션의 복잡도가 증가하면서 자바스크립트의 코드의 양이 방대해지고 이러한 코드를 쉽게 유지보수하기 위해 모듈로서 관리하는 방법이 필요하게 되었습니다.
자바스크립트에서는 ES2015(ES6) 이전에는 모듈로서 관리하는 방법으로 AMD, CommonJS등이 존재하였으나 하나의 표준이 아닌 사용하는 사람에 따라 원하는 것을 선택하는 방식으로 사용해왔습니다.
그 후, ES6 이후부터 자바스크립트에서 표준 모듈 시스템을 제안하였고 이것이 export/import 방식입니다.

그러나, 모든 브라우저에서 ES6 방식의 모듈 시스템을 지원하지는 않았습니다. 따라서 개발자들은 브라우저와 버전에 상관없이 편리한 모듈 시스템을 사용하기를 원했고, 이러한 배경에 의해 등장하게된 툴이 웹팩입니다.

조금 더 세분화하자면 웹팩의 등장 배경을 아래와 같이 정리할 수 있습니다.

1. 파일 단위의 자바스크립트 모듈 관리의 필요성
2. 웹 개발 작업 자동화 도구(Web Task Manager)
3. 웹 애플리케이션의 빠른 로딩 속도와 높은 성능

웹팩에서 지칭하는 모듈은 자바스크립트 모듈 뿐만이 아닌 HTML, CSS, JavaScript, Images, Font등 모든 파일 하나하나 모듈이라 지칭하며 웹 애플리케이션을 구성하는 모든 자원을 모듈이라 보면 됩니다. 보통 모듈 번들링에서는 빌드, 번들링, 변환 이 세 단어는 모두 같은 의미로 사용됩니다.

웹팩으로 해결하려는 문제

1. 자바스크립트 변수 유효 범위 문제

• ES6의 모듈 문법과 번들링으로 해결

2. 브라우저별 HTTP 요청 숫자의 제약

• 웹팩은 여러 파일을 하나 이상의 파일로 합쳐 맨 처음 언급하였던 서버로부터 파일을 다운로드 받는 횟수가 줄어들게 되고 이 효과로 인해 브라우저별 HTTP 요청 숫자 제약을 피할 수 있습니다.

3. 사용하지 않는 코드의 관리
4. Dynamic Loading 및 Lazy Loading 미지원 문제

• 이전에 Require.js와 같은 라이브러를 사용하지 않는 이상 동적으로 원하는 순간에 모듈을 로딩하는 것이 불가능했습니다. 웹팩에서는 Code Splitting 기능을 이용하여 원하는 모듈을 원하는 타이밍에 로딩할 수 있습니다.

🎈 Babel vs Terser vs SWC

바벨 (Babel)

바벨은 자바스크립트 빌드 툴 중 트랜스파일러(Transpiler) 라는 영역에 속합니다.

바벨이 트랜스파일러인 이유는, 최신 자바스크립트 문법으로 작성된 코드를 구버전 브라우저도 이해할 수 있는 수준의 오래된 자바스크립트 코드로 변환해 주는 소프트웨어이기 때문입니다. 즉, 바벨은 트랜스파일러로써 유사한 두 언어 사이에서의 변환 기능을 제공해줍니다.

Terser

Terser라는 빌드 툴에 대해 처음 들어보는 분이 있으실 거로 생각합니다. 사실, 우리가 Terser라는 툴을 직접 다룰 일은 많지 않습니다. 대부분의 프레임워크에서는 이미 Terser에 대한 세팅이 기본적으로 되어있으며, 더욱이 Webpack의 경우 v4 이후 버전부터 별도의 설정 없이도 프로덕션 모드에서 자동으로 Terser 툴을 사용하도록 세팅되어 있기 때문입니다.

Terser 공식 웹사이트에서는 Terser라는 툴을 다음과 같이 소개하고 있습니다.

ES6+를 위한 자바스크립트 parser, mangler 그리고 compressor

Terser가 mangler로써 하는 역할은 우리가 코드에서 사용한 변수 / 함수 / 속성들의 이름을 매우 단순화된 이름으로 변경해주는 것입니다. 우리가 어떤 언어로 프로그래밍을 하는지와 무관하게, 변수나 함수의 이름을 정할 때에는 항상 의미 있는 네이밍을 사용하라는 격언이 언제나 등장합니다. 좋은 네이밍은 그 변수나 함수가 어떤 역할을 하는지 코드 전체를 보지 않더라도 대략적으로 이해할 수 있게 해주기 때문에, 코드의 가독성을 매우 향상시킬 수 있습니다.
하지만, 컴퓨터 입장에서 이 네이밍은 전혀 중요하지 않습니다. 우리가 특정 메뉴가 보여져야 하는지의 여부를 관리하는 Boolean 타입 변수의 이름을 isMenuVisible이라고 짓든지 아니면 단순히 b라고 짓든지 와 상관 없이, 컴퓨터는 그저 하나의 똑같은 불리언 변수로 취급합니다. 우리가 코드의 가독성을 위해 붙여준 이름들은 결과적으로 코드의 길이를 길게 만들기 때문에, 소스 파일의 크기가 커질 수밖에 없습니다.
mangler는 우리의 소스코드에 존재하는 네이밍들을 의미 없는 문자로 바꿔버립니다. isMenuVisible 이라는 변수명을 단순히 a로 바꿔버리면, 13글자를 한 글자로 줄일 수 있습니다. 이러한 최적화 과정을 통해 실제 프로덕션 환경에서 사용될 우리의 코드 사이즈를 획기적으로 줄일 수 있습니다. 물론 우리의 코드는 엉망이 되겠지만 말이죠(mangled).

Terser가 compressor로써 하는 역할은 우리의 자바스크립트 코드를 분석한 후, 더 짧은 코드를 통해 동일한 기능을 구현할 방법이 있는지 확인하고 그 방향으로 코드를 변환해 주는 것입니다.

mangle 하는 과정이나 compress 하는 과정과 같이, 우리가 작성한 코드를 동일한 기능을 제공하는 경량화된 코드로 변환해 주는 일련의 작업을 minify 혹은 minification(코드 경량화) 이라고 부릅니다. 그리고 코드 경량화 작업을 해주는 툴을 우리는 minifier라고 부릅니다. 따라서, Terser는 우리가 작성한 자바스크립트 코드를 프로덕션에서 더욱 경량화된 상태로 제공될 수 있도록 도와주는 minifier 빌드 툴이라고 할 수 있습니다.

SWC(Speedy Web Compiler)

SWC는 자바스크립트 프로젝트의 컴파일과 번들링 모두에 사용될 수 있는, Rust라는 언어로 제작된 빌드 툴입니다. SWC는 Speedy Web Compiler의 약자로, 말 그대로 매우 빠른 웹 컴파일러의 기능을 제공하는 툴입니다.

Next.js에서는 SWC를 기반으로 개발한 컴파일러를 통해 기존 빌드에 활용하던 바벨과 Terser를 대체합니다. 즉, Next.js의 빌드 과정 중 트랜스파일링을 수행했던 바벨과, 코드 경량화를 수행했던 Terser가 SWC로 대체된다는 뜻입니다. SWC로 교체함으로써 트랜스파일링은 무려 17배나 빨라졌다고 하며, 코드 경량화 작업은 7배가 빨라졌다고 합니다.

그렇다면, SWC라는 툴이 바벨이나 Terser보다 월등하게 빠른 이유가 대체 뭘까요? 가장 큰 이유는 바로 Rust라는 프로그래밍 언어가 이벤트 루프 기반의 싱글 스레드 언어인 자바스크립트와는 다르게 병렬 처리를 고려해서 설계된 언어라는 점입니다.

자바스크립트는 한 개의 스레드만을 사용하는 싱글 스레드 언어이기 때문에, 이러한 자바스크립트 언어로 구현된 바벨과 Terser는 한 번에 한 개의 파일만을 변환할 수 있습니다. 자바스크립트와는 달리 병렬 처리가 가능하도록 설계된 Rust 언어로 작성된 SWC는 의존성이 없는 파일들을 동시에 변환할 수 있습니다. 따라서, 만약 현재 컴퓨터가 최대 4개의 작업을 동시에 할 수 있다면 SWC를 사용한 빌드 속도는 바벨이나 Terser를 통해 빌드했을 때 보다 최대 4배까지 더 빨라질 수 있을 것입니다.

• https://fe-developers.kakaoent.com/2022/220217-learn-babel-terser-swc/

🎈 컴파일러 vs 트랜스파일러

컴파일러

컴퓨터가 0과 1만을 이해할 수 있습니다.(기계어) 하지만 컴퓨터에서 동작할 어떤 프로그램을 구현할 때, 프로그래머는 0과 1로 프로그램을 작성하는 것이 아니라 자바스크립트나 C++와 같은 프로그래밍 언어를 사용해 프로그램을 작성합니다.

컴퓨터에 우리가 작성한 코드를 이해시키기 위해서는, 컴퓨터가 이해하는 기계어와 1대 1로 대응되는 저급 프로그래밍 언어(어셈블리어라고 부릅니다)로 번역하는 과정이 필요합니다.

우리는 프로그래밍의 영역에서 이러한 언어 간의 번역(변환)을 담당하는 번역가를 컴파일러라고 부릅니다.

한 언어로 작성된 코드를 동일한 기능을 제공하는 다른 언어의 코드로 변환해주는 역할만 제공한다면 그 소프트웨어는 컴파일러라고 할 수 있습니다.

트랜스파일러

트랜스파일러는 위에서 설명한 컴파일러의 하위분류입니다. 언어를 변환해 주는 기능을 제공하는 소프트웨어인 것은 일반적인 컴파일러와 동일하지만, 트랜스파일러는 완전히 다른 두 언어 사이를 변환해 주는 것이 아니라 유사한 두 언어 사이에서 변환해주는 한정된 역할을 제공해 주는 소프트웨어라는 점이 다릅니다.

🎈 프론트엔드 렌더링: SSG vs ISR vs SSR vs CSR - 언제 어떤 것을 사용해야 할까요?

정적 페이지 생성 (SSG, Static Site Generation)

SSG는 raw 데이터와 템플릿 세트를 바탕으로 완전히 정적인 HTML 웹 사이트를 생성하는 방법입니다. 기본적으로 정적 사이트 생성은 각각의 HTML 페이지 코딩 작업을 자동화하고 해당 페이지를 미리 사용자에게 제공할 수 있도록 준비합니다. 간단히 말해서, SSG는 웹 사이트의 모든 페이지를 미리 렌더링하고 클라이언트 요청에 따라 페이지를 제공합니다.

장점

1. SSG는 데이터베이스 또는 서버 측 프로세스가 거의 필요하지 않은 완전히 정적인 HTML 기반 사이트를 생성할 수 있는 기능을 제공합니다.
2. 정적 사이트는 미리 만들어져 사용자에게 제공될 준비가 되어 있기 때문에 가장 빠른 형식의 웹 페이지입니다.
3. 웹사이트가 미리 만들어졌기 때문에 콘텐츠가 훨씬 더 안전합니다.
4. 검색 엔진 최적화(SEO)에 유리합니다.

단점

1. 콘텐츠를 편집하고 올리는 것이 어렵습니다. 편집자들은 단순한 웹 앱 인터페이스가 아닌 Git 저장소의 접근 권한을 요구할 수 있습니다.
2. 콘텐츠를 업데이트하려면 사이트를 다시 빌드하고 테스트한 후 최종적으로 배포해야 합니다.
3. 대규모 웹 사이트의 경우 빌드가 오래 걸리는 것은 말할 것도 없고, 관리하는 것도 매우 번거롭습니다.

SSG는 장점이 많지만 제품 쇼케이스 웹사이트처럼 내용이 거의 변하지 않는 웹사이트인 경우에만 사용해야 합니다.
블로그의 경우, 수정할 때마다 사이트를 다시 배포해도 괜찮다면 SSG를 사용할 수 있습니다.
약간의 동적인 콘텐츠라도 포함하고 있는 사이트라면 SSG를 절대 사용하지 마세요.

서버 사이드 렌더링 (SSR, Server-Side Rendering)

서버 사이드 렌더링(SSR)은 브라우저에서 웹 페이지를 렌더링하는 대신 서버에서 웹 페이지를 생성하는 방법입니다. 서버에서 완전히 렌더링 된 페이지를 클라이언트로 보냅니다. 클라이언트의 자바스크립트 번들이 SPA 프레임워크의 작동을 대신합니다.

SSR에서는 페이지가 서버에서 렌더링 되어 클라이언트로 전송되기 때문에 동적 데이터를 사용하면서도 여전히 우수한 SEO를 유지할 수 있습니다.

장점

1. 동적 콘텐츠가 포함된 페이지를 만드는 데 사용할 수 있습니다.
2. SSR은 SSG만큼 빠르지는 않지만 페이지가 로드되는 즉시 콘텐츠가 나타나므로 유저가 빠르게 콘텐츠를 확인할 수 있습니다.
3. 검색 엔진 최적화(SEO)에 유리합니다.

단점

1. SSR은 모든 요청이 서버에서 처리되기 때문에 서버에 높은 연산 능력을 필요로 합니다.
2. SSR 사이트는 공격할 수 있는 지점이 더 많으므로 보안을 유지하기가 더 어렵습니다.
3. 캐싱에 복잡한 구성이 많이 필요합니다.

SSR은 서버 비용을 크게 증가시킬 가능성이 있으므로, 매우 빈번하게 변경되고 SEO에 크게 의존하는 매우 동적인 콘텐츠를 포함하고 있는 사이트인 경우에만 사용해야 합니다. 예를 들어 오가닉(organic) 검색에서 사용자를 모으는 주식 시세 표시기 웹사이트라면 SSR이 필요합니다.

점진적 정적 재생성 (ISR, Incremental Static Regeneration)

점진적 정적 재생성(ISR)을 사용하면 전체 사이트를 재빌드할 필요 없이 페이지별로 정적 생성을 사용할 수 있습니다. ISR을 사용하면 정적 사이트의 이점을 유지하면서 수많은 페이지로 확장할 수 있습니다.

ISR은 SSG와 SSR의 장점이 합쳐져 보다 효율적이고 확장 가능한 솔루션을 제공하기 때문에 매우 효과적입니다.

장점

1. SSG와 동일하게 ISR도 페이지를 미리 렌더링하고 캐시하기 때문에 매우 굉장히 빠릅니다.
2. 내용 변경되어도 사이트를 다시 배포할 필요가 없습니다.
3. 검색 엔진 최적화(SEO)에 유리합니다.

단점

1. ISR에는 한 가지 큰 단점이 있는데, 콘텐츠가 변경된 후에 사이트를 방문하게 되어도 이전의 콘텐츠를 보게 됩니다. 새 버전의 웹사이트는 아직 확인할 수 없습니다.

ISR은 이상적으로는 콘텐츠가 동적이지만 자주 변경되지 않는 사이트인 경우 ISR을 사용하는 것이 좋습니다. 그 예시로는 블로그나 개인 웹사이트가 있습니다.

클라이언트 사이드 렌더링 (CSR, Client-Side Rendering)

클라이언트 사이드 렌더링(CSR)은 자바스크립트를 사용하여 브라우저에서 직접 페이지를 렌더링하는 것을 의미합니다. 모든 로직, 데이터 페칭, 템플릿 및 라우팅은 서버가 아닌 클라이언트에서 처리됩니다.

CSR에서 서버는 빈 HTML 페이지와 모든 로직을 처리하는 자바스크립트 번들을 반환합니다.

장점

1. 동적 콘텐츠가 포함된 페이지를 만드는 데 사용할 수 있습니다.
2. SSG와 달리 서버 비용이 높지 않습니다.
3. 처음 로드한 후 다른 페이지를 로드하는 속도가 매우 빠릅니다.

단점

1. 검색 엔진 최적화(SEO)가 잘되지 않습니다.
2. 느린 초기 로드 시간과 상호 작용하기 위한 시간이 성능 저하를 일으킵니다.

CSR은 SEO에 크게 의존하지 않는 모든 사이트에 이상적입니다. Tauri 또는 Electron과 같은 도구를 사용하여 풍부한 사이트 상호작용과 웹, 크로스 플랫폼 어플리케이션을 만드는 데 사용할 수 있습니다.

🎈 Yarn Berry를 사용하는 이유

Yarn Berry를 사용하는 이유는 기존에 사용했던 npm, yarn v1에서 발생하는 문제점이 존재하기 때문입니다.

기존에 의존성을 node_modules를 통해 관리하였는데 npm은 패키지를 찾기 위해서 계속 상위 디렉토리의 node_modules 폴더를 탐색합니다. 따라서 패키지를 바로 찾지 못할수록 readdir, stat과 같은 느린 I/O 호출이 반복됩니다. 경우에 따라서는 I/O 호출이 중간에 실패하기도 합니다.

npm은 패키지를 찾지 못하면 상위 디렉토리의 node_modules 폴더를 계속 검색합니다. 이 특성 때문에 어떤 의존성을 찾을 수 있는지는 해당 패키지의 상위 디렉토리 환경에 따라 달라집니다.
예를 들어, 상위 디렉토리가 어떤 node_modules를 포함하고 있는지에 따라 의존성을 불러올 수 있기도 하고, 없기도 합니다. 다른 버전의 의존성을 잘못 불러올 수 있는 여지도 존재합니다.

또한 npm을 구성하는 node_modules 디렉토리 구조는 매우 큰 공간을 차지합니다. node_modules 폴더는 복잡하기 때문에 설치가 유효한지 검증하기 어렵습니다. 예를 들어, 수백 개의 패키지가 서로를 의존하는 복잡한 의존성 트리에서 node_modules 디렉토리 구조는 깊어집니다. 이렇게 깊은 트리 구조에서 의존성이 잘 설치되어 있는지 검증하려면 많은 수의 I/O 호출이 필요합니다. 일반적으로 디스크 I/O 호출은 메모리의 자료구조를 다루는 것보다 훨씬 느립니다. 이런 문제로 인해 yarn v1이나 npm은 기본적인 의존성 트리의 유효성까지만 검증하고, 각 패키지의 내용이 올바른지는 확인하지 않습니다.

그리고 npm 및 yarn v1에서는 중복해서 설치되는 node_modules를 아끼기 위해 끌어올리기(Hoisting) 기법을 사용합니다. 끌어올리기에 따라 직접 의존하고 있지 않은 라이브러리를 require() 할 수 있는 현상을 유령 의존성(Phantom Dependency)이라고 부릅니다. 유령 의존성 현상이 발생할 때, package.json에 명시하지 않은 라이브러리를 조용히 사용할 수 있게 됩니다.

yarn berry는 위에서 언급한 문제를 Plug’n’Play (PnP) 방법을 통해 해결합니다.
yarn berry는 node_modules를 생성하지 않습니다. 대신 .yarn/cache 폴더에 의존성의 정보가 저장되고, .pnp.cjs 파일에 의존성을 찾을 수 있는 정보가 기록됩니다. .pnp.cjs를 이용하면 디스크 I/O 없이 어떤 패키지가 어떤 라이브러리에 의존하는지, 각 라이브러리는 어디에 위치하는지를 바로 알 수 있습니다.

yarn berry의 PnP 시스템에서 각 의존성은 zip 아카이브로 관리됩니다. 이후 .pnp.cjs 파일이 지정하는 바에 따라 동적으로 zip 아카이브의 내용이 참조됩니다. zip 아카이브로 의존성을 관리하면 더 이상 node_modules 디렉토리 구조를 생성할 필요가 없기 때문에 설치가 신속히 완료되고, 각 패키지는 버전마다 하나의 zip 아카이브만을 가지기 때문에 중복해서 설치되지 않습니다. 그리고 의존성을 구성하는 파일의 수가 많지 않으므로, 변경 사항을 감지하거나 전체 의존성을 삭제하는 작업이 빠릅니다.

yarn PnP는 node_modules에서와 같이 의존성을 끌어올리지 않습니다. 이로써 각 패키지들은 자신이 package.json에 기술하는 의존성에만 접근할 수 있습니다. 기존에 환경에 따라 우연히 작동할 수 있었던 코드들이 보다 엄격히 관리되는 것입니다. 이로써 예기치 못한 버그를 쉽게 일으키던 유령 의존성 현상을 근본적으로 막을 수 있습니다.

yarn PnP은 의존성을 압축 파일로 관리하기 때문에 의존성의 용량이 작습니다. 또한 각 의존성은 하나의 zip 파일로만 표현되기 때문에 의존성을 구성하는 파일의 숫자가 npm만큼 많지 않습니다. 이처럼 용량과 파일의 숫자가 적기 때문에 yarn berry를 사용하면 의존성을 Git으로 관리할 수 있습니다. 이렇게 yarn berry에서 의존성을 버전 관리에 포함하는 것을 Zero-Install이라고 합니다.

이처럼 의존성을 버전 관리에 포함하면 새로 저장소를 복제하거나 브랜치를 바꾸었다고 해서 yarn install을 실행하지 않아도 되고 이에 따라 CI에서 의존성 설치하는 시간을 크게 절약할 수 있습니다.

https://toss.tech/article/node-modules-and-yarn-berry

🎈 Next.js의 작동 방식

https://nextjs.org/learn/foundations/how-nextjs-works https://velog.io/@surim014/how-next.js-works

🎈 Vercel Edge Function

Vercel의 Edge Functions를 사용하면 경량 Edge Runtime으로 동적이고 개인화된 콘텐츠를 제공할 수 있습니다.

Vercel Edge Runtime은 평균적으로 Serverless Functions보다 성능이 뛰어나고 비용 효율적입니다. Edge Functions는 Edge Network에 전 세계적으로 배포되며 이를 트리거하는 사용자와 가장 가까운 지역에서 자동으로 실행될 수 있습니다. 또한 cold boots가 없으므로 코드를 실행하기 전에 시작하는 데 추가 시간이 필요하지 않습니다.

Edge Functions는 OAuth 콜백 실행, 웹후크 요청 응답 또는 짧은 시간 제한 내에 요청이 완료되지 않으면 실패하는 API와 상호 작용과 같이 가능한 한 빨리 네트워크를 통해 데이터와 상호 작용해야 할 때 유용합니다.

Edge Function의 작동 방식

Edge Functions는 Chrome 브라우저에서 사용 하는 것과 동일한 고성능 V8 JavaScript 및 WebAssembly 엔진을 기반으로 하는 Vercel의 Edge Runtime을 사용합니다.

V8 엔진을 사용하면 컨테이너나 가상 머신이 필요하지 않은 격리된 실행 환경에서 Edge Functions를 실행할 수 있습니다. 이것은 Edge Runtime을 여러 면에서 제한하지만 동시에 경량화합니다. Edge Function 프로세스를 시작하려면 서버리스 기능보다 적은 리소스가 필요하므로 cold boot 시간을 효과적으로 제거합니다.

Edge Functions의 보편적 이점은 Edge Runtime입니다. 비용 효율적이고 리소스를 최소화합니다. 그러나 Edge Functions를 사용하여 특정 컨텍스트에서 낮은 대기 시간으로 동적 콘텐츠를 제공할 수도 있습니다.

모든 Edge 기능이 복제되어 Vercel의 Edge Network에 있는 데이터 센터의 글로벌 네트워크에 배포되기 때문에 낮은 대기 시간으로 동적 콘텐츠를 제공할 수 있습니다. 사용자에게 가장 가까운 데이터 센터 또는 데이터베이스 근처 지역에서 호출할 수 있습니다. 또한 지역에 따라 개인화된 콘텐츠를 빠른 속도로 제공할 수 있습니다.

Edge Functions는 캐시 이후에도 실행되며 응답을 캐시하고 반환할 수 있습니다.

엣지 함수를 사용하는 이유

Edge Functions는 전 세계적으로 분산된 사용자 기반에 대해 평균적으로 Serverless Functions보다 더 빠른 응답을 제공할 수 있습니다. 다음은 Edge Functions가 제공하는 몇 가지 구체적인 이점입니다.

1. 네트워크 사용 비용 감소 Edge Functions는 지리적으로 사용자 근처 또는 데이터베이스 근처에서 실행할 수 있으므로 네트워크 요청은 serverless function보다 더 짧은 거리를 이동하고 더 낮은 비용을 발생시킬 수 있습니다.
   서버리스 함수는 일반적으로 한 지역에서 배포 및 호출되므로 때때로 사용자에게 응답을 제공하기 전에 데이터베이스에 도달하기 위해 멀리 이동합니다.
2. 대기 시간 감소 데이터베이스나 지리적으로 멀리 떨어진 종속성에 의존하지 않는 Edge Functions는 사용자 근처에서 실행되도록 구성할 수 있습니다. 이로 인해 Serverless Functions보다 훨씬 짧은 대기 시간으로 응답이 사용자에게 전달될 수 있습니다.
3. 개인화된 동적 콘텐츠 Edge Functions에서 사용자 지정 코드를 사용하여 사용자가 함수를 호출하는 Edge 네트워크의 데이터 센터를 기반으로 콘텐츠를 전달할 수 있습니다.
4. 저수준 언어 지원 C 또는 Rust와 같은 언어로 작성된 라이브러리 및 도구를 컴파일하고 Edge Functions에서 사용할 수 있습니다. 자세한 내용은 WebAssembly 문서를 참조하십시오.

Edge Function regions

Edge Functions의 장점 중 하나는 방문자와 지리적으로 가까운 데이터 센터에서 실행할 수 있어 네트워크 요청 시간이 단축된다는 것입니다. 그러나 함수가 방문자로부터 멀리 떨어진 데이터 소스에 의존하는 경우 이 이점이 완화됩니다.

예를 들어 일본의 방문자가 미국에 있는 데이터베이스에 의존하는 함수를 호출한다고 가정합니다. 이 기능은 에지 네트워크의 일본에 있는 시스템에서 호출 되지만 최종 응답에는 Japan -> US -> Japan 왕복이 필요하므로 방문자에게 전체 응답 시간이 걸립니다.

Edge Function의 효율적인 라우팅을 보장하기 위해 함수가 실행되어야 하는 지역을 지정할 수 있습니다. 그렇게 하려면 configEdge Function이 내보내는 객체를 편집하십시오.

export const config = {
  runtime: 'edge', // this is a pre-requisite
  regions: ['iad1'], // only execute this function on iad1
};

제한 사항

모든 솔루션과 마찬가지로 Edge Functions는 모든 사용 사례에 적합하지 않을 수 있으며 알아야 할 몇 가지 제한 사항이 있습니다.

1. 데이터 원본과 Edge Function이 실행되는 위치 사이의 거리로 인해 요청에 원치 않는 대기 시간이 추가될 수 있습니다. 잠재적으로 이 문제를 완화하려면 Vercel에서 지역 Edge Function 실행에 대한 가이드를 읽으십시오.
2. Edge Function의 최대 크기는 함수에 번들로 제공되는 모든 코드를 포함하여 4MB 입니다.
3. 대부분의 기본 Node.js API는 지원되지 않습니다. 여기에서 지원되는 Node.js API 목록을 참조하세요.
4. 서버리스 기능과의 비교
5. edge function 사용시 Next.js에서 해당 페이지의 정적 생성(Static Generation)이 비활성화됩니다. Edge 런타임은 각 요청마다 새로운 환경에서 코드를 실행합니다. 이는 정적으로 생성된 콘텐츠와 맞지 않습니다. 증분 정적 재생성(ISR)을 사용할 때, Edge 런타임과 ISR을 함께 사용할 때 다음과 같은 상황이 발생할 수 있습니다.
   1. 오래된(stale) 페이지 재생성: 페이지가 오래되어 재생성이 필요한 경우, HTML과 JSON 버전을 동시에 생성합니다.
   2. On-demand ISR with fallback: 'blocking': 페이지는 요청 시 동기적으로 HTML을 렌더링합니다. 그 후 백그라운드에서 HTML과 JSON 버전 모두에 대한 재검증(revalidation)이 이루어집니다.
   3. Edge 런타임을 사용할 때 정적 생성이 비활성화되지만, ISR과 같은 기능을 통해 여전히 효율적인 콘텐츠 갱신과 제공이 가능합니다. 다만, 이 과정에서 여러 로그가 발생할 수 있음을 알려주는 것입니다.

자세한 내용은 Edge Functions 제한 페이지를 참조하세요.

https://vercel.com/docs/concepts/functions/edge-functions

🎈 Edge Middleware

Edge Middleware는 요청이 사이트에서 처리 되기 전에 실행되는 코드입니다. 요청에 따라 응답을 수정할 수 있습니다. 캐시보다 먼저 실행되기 때문에 미들웨어를 사용하는 것은 정적으로 생성된 콘텐츠에 개인화를 제공하는 효과적인 방법입니다. 들어오는 요청에 따라 응답을 반환하기 전에 사용자 지정 논리를 실행하고 재작성, 리디렉션, 헤더 추가 등을 수행할 수 있습니다.

Edge 미들웨어를 사용하면 사이트 방문자에게 빠르고 개인화된 콘텐츠를 제공할 수 있습니다. Vercel의 Edge Network에 전역적으로 배포되며 서버 측 로직을 방문자의 출처에 가까운 Edge로 이동할 수 있습니다.

미들웨어는 Chrome 브라우저에서 사용하는 것과 동일한 고성능 V8 JavaScript 및 WebAssembly 엔진 에 구축된 Vercel Edge Runtime을 사용합니다. Edge Runtime은 다음과 같은 Web Standard API의 하위 집합을 노출하고 확장합니다. FetchEvent, Response, 그리고 Request, 들어오는 요청에 따라 응답을 조작하고 구성하는 방법을 더 잘 제어할 수 있습니다. 미들웨어 작성에 대한 자세한 내용은 미들웨어 API 가이드를 참조하세요.

개발자는 Edge Middleware를 통해 애플리케이션에 추가 크기를 추가하지 않고도 사용자 경험을 보다 효과적으로 제어할 수 있으므로 성능이 향상됩니다. 최종 사용자는 edge에서 실행되기 때문에 대기 시간이 매우 짧은 사전 렌더링되고 개인화된 콘텐츠를 경험합니다.

미들웨어의 일반적인 사용 사례는 다음과 같습니다.

• 입증(Authentication)
• 지리적 위치(Geolocation)
• 쿠키 작업(Working with cookies)
• A/B 테스트(A/B testing)
• 봇 보호(Bot protection)
• 재작성(Rewrites)

https://vercel.com/docs/concepts/functions/edge-middleware

🎈 모노레포란?

모노레포는 단 하나의 버전으로 관리되는 모놀리식 애플리케이션 방식과 각각의 모듈이 분산된 멀티레포의 문제를 해결하기 위해 탄생했습니다. 모노레포는 두 개 이상의 프로젝트가 동일한 저장소에 저장되는 소프트웨어 개발 전략입니다. 멀티레포처럼 각각의 모듈이 분리되어 있지만 하나의 동일한 저장소에 저장되는 점이 다른 점입니다.

모노레포는 멀티레포의 문제를 해결해줍니다.

1. 더 쉬운 프로젝트 생성 모노레포에서는 저장소 생성을 새롭게 할 필요가 없으며, 개발 환경과 CI/CD, 빌드 등의 과정에 기존 DevOps를 이용하므로 새 프로젝트 생성에 대한 오버헤드가 없습니다.
2. 더 쉬운 의존성 관리 공통으로 사용되는 의존성 패키지가 같은 저장소에 있으므로 버전이 지정된 패키지를 npm registry와 같은 곳에 publish할 필요가 없습니다.
3. 단일화된 관리 포인트 개발환경 및 DevOps에 대한 업데이트를 한 번에 반영할 수 있습니다.
4. 일관된 개발자 경험 제공 애플리케이션을 일관되게 구축하고 테스트할 수 있으며, 개발자는 다른 팀의 애플리케이션에 자신 있게 기여하고 변경 사항이 안전한지 확인할 수 있다.
5. 프로젝트들에 걸친 원자적 커밋 커밋할 때마다 모든 것이 함께 작동하고 변경 사항의 영향을 받는 조직에서 쉽게 변화를 확인할 수 있습니다.
6. 서로 의존하는 저장소들의 리팩터링 비용 감소 모노레포는 대규모 변경을 훨씬 더 간단하게 만듭니다. 100개의 라이브러리로 만든 10개의 앱을 리팩터링하고 변경을 커밋하기 전에 모두 작동하는지 확인할 수 있습니다.
7. 테스트 및 빌드 범위 최소화 소스 변경 시 모든 프로젝트를 다시 빌드하거나 다시 테스트하지 않습니다. 대신 변경 사항의 영향을 받는 프로젝트만 다시 테스트하고 빌드합니다.

그렇지만 항상 모노레포를 사용하는게 좋은 것은 아닙니다. 다음과 같은 상황에서 사용하는게 좋습니다.

• 유사한 제품의 집합
• 여러 프로젝트의 변화를 한눈에 파악해야 할 때
• 호스트 애플리케이션을 플러그인 등으로 확장할 때
• 공통 기능을 재사용하는 관련된 프로젝트의 집합
• 유사한 DevOps로 구성된 프로젝트의 집합

모노레포를 구축하려고 할 때 관리 용이성, 속도 그리고 프로젝트 구조 관리 측면에서 다음과 같은 사항을 고려해야 합니다.

• 관리 측면
  • 코드 공유: 서로 다른 프로젝트 간에 쉽게 소스 코드를 공유
  • 일관성 있는 도구: 서로 다른 프로젝트들(심지어 서로 다른 프레임워크를 사용하더라도)에서 일관된 개발 경험을 제공
  • 스케폴딩: 새로운 프로젝트를 생성할 때 초기 코드를 쉽게 생성
  • 프로젝트 제약 및 가시성(visibility): 저장소 내에서 의존 관계를 제한하는 규칙 정의 지원. 예를 들어, 일부 프로젝트를 팀 전용으로 표시하거나 특정 프레임워크을 사용 중임을 기술.
• 속도 측면
  • 로컬 캐싱: 같은 머신에서 같은 것을 두 번 빌드하거나 테스트하지 않음
  • 분산 캐싱: 다양한 환경에서 캐시 아티팩트를 공유. 즉, 조직 단위로 여러 CI 환경에 걸쳐 같은 것을 두 번 빌드, 테스트하지 않음
  • 로컬 작업 오케스트레이션: 빌드 및 테스트 등의 작업을 순서에 맞게 병렬로 진행
  • 분산 작업 진행: 단일 시스템에서 실행되어 여러 시스템에 명령을 전달
  • 변화에 영향을 받는 프로젝트 감지: 변경의 영향을 받을 수 있는 항목을 결정하여 영향을 받는 프로젝트만 빌드/테스트
• 구조 파악 측면
  • 워크스페이스 분석: 추가 구성 없이 주어진 워크스페이스의 의존성 관계를 분석
  • 의존성 그래프 시각화: 프로젝트 및 작업 간의 종속 관계를 시각화

모노레포 구축을 도와주는 도구로는 Lerna, yarn, nx, turborepo 등이 있습니다.

https://d2.naver.com/helloworld/0923884