뒤로가기/앞으로가기 캐시 (이해 bfcache)는 브라우저에서 일어나는 최적화로, 앞으로가기나 뒤로가기가 발생했을 때 화면을 즉시 보여주는 역할을 한다. 이는 사용자의 브라우저 사용성을 향상시키는데, 특히 느린 네트워크/디바이스에서 빛을 발한다.

## 브라우저 호환성

bfcache는 [파이어폭스](https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/Using_Firefox_1.5_caching)와 [사파리](https://webkit.org/blog/427/webkit-page-cache-i-the-basics/)에서 몇년전부터 지원하고 있었다. 크롬 역시 마찬가지다

## bfcache란

bfcache는 인메모리 캐시로, 자바스크립트 힙까지 포함해 페이지 전체를 완전히 캐시로 저장해버리는 것을 의미한다. 전체 페이지가 메모리 안에 있기 때문에, 사용자가 이전페이지로 돌아가고자 했을 때 빠르게 전체 페이지를 보여줄 수 있다.

### bfcache가 비활성화 되어 있다면

이전 페이지 로딩을 위해서 새로운 요청을 시도할 것이며, 반복적인 방문에 따라서 웹페이지가 얼마나 최적화 되어 있냐에 따라서 브라우저는 재다운로드, 재 parsing, 재 실행등을 일부 실행하거나 혹은 이를 다 다시 처음부터 시도할 것이다.

### bfcache가 활성화 되어 있다면

전체 페이지가 메모리에 저장되어 있기 때문에, 네트워크 요청을 할 필요 없이 이전 페이지 로딩이 즉시 이루어진다.

크롬의 사용 데이터에 따르면 데스크톱의 탐색중 10%, 모바일 탐색 중 20%가 뒤로가기/또는 앞으로가기에서 이루어진다. bfcache를 이용하게 되면 웹페이지를 로드하는데 소요되는 데이터, 시간 등을 아낄 수 있다.

## 어떻게 동작하는가?

우리가 흔히 알고 있는 HTTP cache와는 동작이 다르다. bfcache는 자바스크립트 힙을 포함해 전체 페이지를 통채로 스냅샷을 떠서 메모리에 올려 버린다. 이에 반해 HTTP 캐시는 이전 요청에서 이루어진 응답에 대해서만 캐싱할 뿐이다. 페이지 로딩에 필요한 모든 요청을 HTTP 캐시로 만족시키는 것은 매우 드물기 때문에, bfcache 복원을 사용한 페이지 방문은 bfcache를 사용하지 않은 '잘 최적화된' 캐시보다 항상 빠르다.

그러나 페이지 스냅샷을 메모리에 올린다는 것은, 현재 실행중인 코드를 보존하려고 할 때 복잡해진다. 예를 들어, 페이지가 bfcache가 되어 있는 동안에 `setTimeout`호출이 있으면 어떻게 해야할까?

정답은 브라우저가 보류중인 timer, 또는 promise의 실행을 일시 중지하고 (기본적으로 자바스크립트 태스크 큐에 있는 모든 작업) 페이지가 bfcache로 부터 복원이 되었을 때 다시 실행하는 것이다.

이는 매우 합리적인 방법으로 보이지만, 때로는 굉장히 복잡한 결과나 이해할 수 없는 행동을 만들어 낼 수도 있다. 만약에 브라우저가 `IndexedDB transaction` 의 일환인 작업을 중지한다고 한다면, 다른 탭에서도 접근할 수 있는 indexedDB의 특성상 다른 탭에서 페이지를 열었을 때 영향을 미칠 수 있다. 그래서 브라우저는, IndexedDB 트랜잭션 또는 다른 페이지에 영향을 줄 수 있는 API 호출 중에는 페이지를 캐싱하려 하지 않는다.

## bfcache의 작업을 api로 살펴보기

bfcache는 브라우저가 자동으로 하는 최적화이지만, 여전히 개발자들이 이 동작을 잘 이해 한다면 페이지를 최적화 하거나 성능을 측정하고 조정하는데 도움을 얻을 수 있다.

bfcache를 관찰할 수 있는 가장 좋은 이벤트는 `pageshow`와 `pagehide`다. [새로운 페이지 라이프 사이클 이벤트](https://developers.google.com/web/updates/2018/07/page-lifecycle-api)인 `freeze` 와 `resume`도 bfcache를 확인하는데 도움을 얻을 수 있다. 예를 들어, CPU 사용량을 최소화 하기 위하여 백그라운드 탭을 프리징할 때에 이 이벤트를 쓸 수 있다. 하지만 이는 오로지 크로미윰 브라우저에서만 확인가능하다.

### bfcache를 복원하는 순간을 확인하기

`pagehide`와 `pageshow`는 쌍으로 일어난다. `pageshow`는 페이지가 정상적으로 로딩 되거나, bfcache 로부터 페이지 복원 될 때 일어난다. `pagehide`는 마찬가지로 페이지가 정상적으로 언로드 되거나, bfcache로 들어가는 순간에 일어난다.

`pagehide`는 `persisted`속성을 가지고 있는데, `false`가 리턴되면 page가 bfcache되지 않음을 의미하는 것이다. 그렇다고 `true` 라고 해서 bfcache를 보장하는 것은 아니다. 단지 브라우저가 페이지를 캐싱 시도했다는 것을 의미하며, 무언가 다른 이유로 인해서 캐싱이 안될 수도 있다.

```javascript
window.addEventListener('pagehide', function (event) {
  if (event.persisted === true) {
    console.log('bfcache가 될 수도 있음')
  } else {
    console.log(
      '정상적으로 unload되며 이전 페이지 상태는 bfcache가 안들어가기 때문에 다 버려짐.',
    )
  }
})
```

비슷하게 `freeze`에도 같은 속성이 있으며, 같은 이유로 캐싱을 보장하지 않는다.

## bfcache로 페이지 최적화 하기

모든 페이지가 bfcache로 처리되는 것은 아니며, 심지어 캐싱이 되었다 하더라도 영원히 남아 있는 것은 아니다. 개발자들이 캐시 히트 레이트를 극대화 하기 위해 bfcache를 가능하게/혹은 불가능하게 만드는 것을 이해하는 것이 중요하다.

### 절대로 `unload` 이벤트를 사용하지 말 것

모든 브라우저에서 bfcache로 최적화하는데 가장 중요한 것은 절대절대로 `unload`이벤트를 임의로 사용해서는 안된다는 것이다. 이 `unload`이벤트는 bfcache 이전에 발생하고, 인터넷의 많은 페이지가 `unload`이벤트가 발행 후에는 페이지가 더이상 존재하지 않는다는 (합리적인) 가정하에 동작하기 때문에, `unload`의 이벤트는 문제를 야기 할 수 있다. 많은 개발자들이 `unload` 이벤트가 더이상 사용자가 페이지 네비게이션을 하지 않을 때 발생한다고 믿고 있는데, 이는 사실이 아니다.

> Many developers treat the unload event as a guaranteed callback and use it as an end-of-session signal to save state and send analytics data, but doing this is extremely unreliable, especially on mobile! The unload event does not fire in many typical unload situations, including closing a tab from the tab switcher on mobile or closing the browser app from the app switcher.

파이어폭스는 `unload`에 리스너가 달려 있을 경우, bfcache에 적합하지 않은 페이지로 처리한다. 사파리는 `unload`이벤트 리스너와 함께 페이지 케싱을 시도하는데, 잠재적인 버그를 줄이고자 유저가 네비게이션을 실행해버리면 `unload` 이벤트를 실행시키지 않는다. 크롬은 현재 [전체 페이지의 65%에 `unload`이벤트를 달았는데](https://www.chromestatus.com/metrics/feature/popularity#DocumentUnloadRegistered) 사파리와 마찬가지로 이를 실행하지 않는다.

`unload`이벤트 대신에 `pagehide`이벤트를 사용하는 것이 좋다.

### 조건이 있을 때만 `beforeunload`이벤트를 추가해라

`beforeunload`는 크롬과 사파리에 영향을 받지 않지만, 파이어 폭스의 경우 bfcache를 무력화 할 수 있으므로 사용해서는 안된다.

`unload`이벤트와는 다르게, 합리적으로 `beforeunload`를 사용할 수 있는 케이스가 존재한다. 예를 들어, 사용자가 데이터를 저장하지 않고 페이지를 떠나려고 하는 경우, `beforeunload`를 사용하여 사용자에게 경고를 하고, 사용이 끝난 즉시 지워버리는 것이 좋다.

🙅‍♂️ 하지 말것

```javascript
// 이벤트가 계속 남아있게 된다.
window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault()
    return (event.returnValue = 'Are you sure you want to exit?')
  }
})
```

🙆 해도 되는 것

```javascript
function beforeUnloadListener(event) {
  event.preventDefault()
  return (event.returnValue = 'Are you sure you want to exit?')
}

onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener)
})

// 더이상 사용이 필요 없으면 바로 지운다.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener)
})
```

### window.opener references의 사용을 피할 것

일부 브라우저 (크롬 86 포함) 페이지를 `window.open`또는 `target=_blank`에 `rel="noopner"`를 명시하지 않고 페이지를 열었을 경우 열린 페이지는 페이지를 이 페이지를 열어준 페이지에 대해서 참조를 사용하게 된다.

또한 보안상의 이유로 인해, `window.opener`의 null이 아닌 참조를 가지고 있는 페이지는 bfcache를 안전하게 사용할 수 없다. 이는 bfcache에 접근을 시도하는 페이지에 대해 위협이 되기 때문이다.

따라서 `window.opener`를 쓸 때는 반드시 `rel="noopener"`를 써야 한다. 만약 열린 윈도우에 대해 제어가 필요하다면 `window.postMessage`를 사용하는게 좋다. 그렇지 않고 윈도우 객체를 직접 참조하게되면, 열린 페이지 또한 열려있는 페이지 모두 bfcache를 누리지 못하게 된다.

### 사용자가 다른 페이지로 가기전에 모든 connection을 close해라.

위에서 언급했던 것처럼, bfcache에 들어가기전에 모든 예약된 자바스크립트 태스크는 중단되고, cache에서 나올때 다시 시작된다. 만약 스케쥴된 자바스크립트 태스크가 단순히 DOM Api에 접근하거나, 현재 페이지와 별개로 작동하는 API라고 한다면, 페이지를 일시정지해서 bfcache로 들어가는 것이 크게 문제가 되지 않는다.

만약 IndexedDB, Web Locks, WebSockets과 같이 다른 페이지에서도 접근할 수 있는 데이터와 관련된 API 라고한다면, 다른 탭의 실행에도 영향을 미칠 수 있기 때문에 문제가 될 수 있다. 따라서 다음 시나리오 상에서는 대부분의 브라우저가 bfcache를 시도하지 않는다.

- 페이지에 끝나지 않은 indexedDB transaction이 있는 경우
- fetch나 XMLHttpRequest가 진행 중인 경우
- WebSocket, WebRTC 연결이 살아 있는 경우

만약 페이지에서 위의 경우에 해당한다면, `pagehide`나 `freeze`이벤트에서 이러한 연결을 모두 끊어 버리는 것이 좋다. 이는 다른 탭에 영향을 주는 위험이 없이 안전하게 cache를 하는 방법이다.

그리고, bfcache로 부터 페이지가 살아난다면, 이러한 API를 다시 열어두면 된다. `pageshow` `resume` 이벤트에서 다시 연결해두면 된다.

> 유저가 페이지르 떠나기전에 해당 API가 사용 중이지 않다면 bfcache는 사용가능하다. 그러나 Embedded Plugins, Workers, Broadcast Channel 등 [일부 API](https://source.chromium.org/chromium/chromium/src/+/master:content/browser/frame_host/back_forward_cache_impl.cc;l=124;drc=e790fb2272990696f1d16a465832692f25506925?originalUrl=https:%2F%2Fcs.chromium.org%2F)들은 사용하게 되면 bfcache가 불가능하게 된다. 크롬이 bfcache 초기 출시 당시 의도적으로 보수적으로 접근하고 있지만, 장기적인 목표로는 최대한 많은 API에서 동작하게 끔 하려고 한다.

### 페이지가 캐싱 가능한지 테스트

page가 unloading시에 캐싱이 되는지 안되는지 확실히 결정할수는 없지만, 뒤로가기나 앞으로가기시에 bfcache가 올바르게 되고 있는지는 확인이 가능하다. 크롬의 경우 bfcache가 최대 3분까지 남아 있으므로, Puppetter나 Webdriver와 같은 테스트 도구로 `pageShow`이벤트의 `persisted`의 속성이 true로 남아있는지 확인하기에 충분하다.

물론 일반적인 상황에서는 캐시가 가능한 길게 남아있지만, 시스템의 메모리가 부족한 아쉬운 상황에서는 언제든 캐시가 날아갈 수 있다. 실패 테스트가 반드시 캐시가 안된다고는 단언할 수 없으므로, 실패의 기준과 테스트 설정을 유심히 해야할 필요가 있다.

> 크롬의 bfcache는 모바일에서만 가능하므로, 데스크톱에서 사용하기 위해서는 [#back-forward-cache 설정을 켜야 한다.](https://www.chromium.org/developers/how-tos/run-chromium-with-flags)

### bfcache를 제거하는 법

최상단 페이지 응답에 아래와 같이 설정해두면 bfcache를 제거할 수 있다.

```
Cache-Control: no-store
```

`no-cache`와 `no-store`등은 bfcache에 영향을 미치지 않는다.

이는 bfcache를 무력화시키는 확실한 방법이지만, [성능과 캐싱을 위해서 각자가 원하는 방법을 적용할 수 있도록 하자는 제안도 존재한다.](https://github.com/whatwg/html/issues/5744) (예를 들어 로그아웃과 같이 명시적인 시점에 bfcache 날린다던지)

## bfcache 가 분석 및 성능 측정에 미치는 영향

만약 분석 도구를 활용하여 사이트의 방문을 추적해본적이 있다면, 크롬이 bfcache를 사용함에 따라서 전체 페이지뷰가 감소한다는 것을 인지했을 수도 있다. 실제로 bfcache를 구현한 브라우저는 다른 브라우저에 비해 페이지뷰를 과소보고 하는 경우가 있는데, 이는 대부분의 트래킹 라이브러리들이 bfcache의 복원을 새로운 페이지뷰로 간주하지 않기 때문이다.

이를 방지하기 위해서는 아래와 같은 코드 추가를 고려해볼 수도 있다.

```javascript
// Send a pageview when the page is first loaded.
gtag('event', 'page_view')

window.addEventListener('pageshow', function (event) {
  if (event.persisted === true) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view')
  }
})
```

### 성능 측정

bfcache는 특히 실제 수집된 성능 지표, 그 중에서도 페이지 로드 시간을 측정하는 지표에 부정적인 영향을 미칠 수 있다. bfcache 네비게이션은 실제 새로운 페이지를 로딩하는게 아니고 기존 페이지를 단순히 복원하는 것이기 때문에, bfcache를 사용하게 되면 수집된 페이지 로드의 총 숫자가 감소한다. 중요한 것은 bfcache로 복원으로 대체되는 페이지 로드가 페이지 속도 측정 중에서 가장 빠른 페이지로드로 인식될 수 있다는 것이다. 그 결과 데이터 집합에서 빠른 페이지 로드가 줄어들어, 사용자가 경험하는 실제 성능이 향상되었음에도 불구하고 그래프 상으로는 속도가 일정하지 않은 것 처럼 보일 수도 있다.

이 문제를 해결하는 데 몇가지 방법이 있는데 그 중 하나는, 모든 페이지 로드 메트릭에 `navigate` `reload` `back_forward` `prerender`와 같은 주석을 달아두는 것이다. 이러한 접근 방식은 TTFB(Time to First Byte)와 같은 사용자 중심 페이지 로드 메트릭에 권장된다. Core Web Vitals와 같은 사용자 중심 메트릭의 경우, 사용자가 경험하는 것을 정확하게 나타내는 값을 보고하는 것이 더 좋다.

### Core Web Vital에 미치는 영향

[Core Web Vital](https://web.dev/vitals/)이란 로딩 속도, 상호작용성, 시각적 안정성 등 다양한 면에 결쳐 웹페이지의 사용자 경험을 측정한다. bfcache 복원으로 사용자는 기존 페이지로드보다 더 빠르게 탐색하게 되므로, Core Web Vital에 이를 반영하는 것이 중요하다. 당연하게도, 사용자는 무슨 기법을 썼든지 간에 아무튼 속도가 빠른 것에만 신경을 쓰기 때문에.

곧 [Chrome User Experience Report](https://developers.google.com/web/tools/chrome-user-experience-report)와 같은 도구에서 bfcache 복원을 별도의 페이지 방문으로 처리하도록 업데이트 될 예정이다.

bfcache 복원에 따른 성능을 측정하기 위한 web performance api는 아직 존재하지 않지만, 기존 API로 대략 유추 해볼 수는 있다.

- [Largest Contentful Paint(LCP)](https://web.dev/lcp/): `pageshow` 이벤트의 타임스템프와 다음 프레임이 페인트 되는 시점의 타임스탬프를 비교하여 사용할 수 있다. (bfcache의 경우 LCP와 FCP의 값은 같다.)
- [First Input Delay(FID)](https://web.dev/fid/): `pageshow`이벤트에 이벤트 리스너를 다시 달아서 bfcache 복원 후 FID의 지연을 보고 할 수 있다.
- [Cumulative Layout Shift(CLS)](https://web.dev/fid/): 기존 performance observer를 계속 사용할 수 있으며, 현재 CLS 값을 0으로 재설정하면 된다.

## 더 읽어보기

- [Firefox Caching](https://developer.mozilla.org/en-US/Firefox/Releases/1.5/Using_Firefox_1.5_caching)
- [Page Cache](https://webkit.org/blog/427/webkit-page-cache-i-the-basics/)
- [브라우저에 따른 bfcache](https://docs.google.com/document/d/1JtDCN9A_1UBlDuwkjn1HWxdhQ1H2un9K4kyPLgBqJUc/edit?usp=sharing)
- [bfcache 테스터](https://back-forward-cache-tester.glitch.me/?persistent_logs=1)

출처: https://web.dev/bfcache/#optimize-your-pages-for-bfcache


항상 브라우저에 감사하십시오 frontend developers.

뒤로가기, 앞으로가기의 캐시 aka bfcache

```javascript
const memoize = (func) => {
  // 메모이제이션을 위한 클로져 생성

  // 메모이제이션 값을 저장해둔다.
  const results = {}

  return (...args) => {
    // 파라미터로 메모이제이션 키 생성
    const memoKey = JSON.stringify(args)

    // 결과가 없으면 메모이제이션 값을 넣어둔다.
    if (!results[memoKey]) {
      results[memoKey] = func(...args)
    }

    // 메모이제이션 값을 리턴
    return results[memoKey]
  }
}
```


자바스크립트로 메모이제이션 구현하기

세상 많은 javascript 패키지에 감사하며 개발을 하고 있지만, 때로는 이러한 오픈소스에도 버그가 존재하곤 한다. 한 달 전 쯤에는, [리액트에서 ie11에 존재하지 않는 `Array.fill()`을 쓰는 바람에 패치를 한 것을 본 적도 있다.](https://github.com/facebook/react/issues/20069) 공짜로 가져다 쓰는 주제에 감사는 못할 망정 비난을 하는 것은 아니지만, 모두가 완벽할 수는 없고, 때로는 이런 버그를 내가 찾아서 적용해야 할 때가 있다. 아래 과정은 이슈 업해서 고쳐지는 것을 기다리기엔 너무 급한 나에게 필요한 방법이다.

## 1. 패치 폴더 만들기

```bash
mkdir patches
```

## 2. 해당 폴더에 패치를 적용할 파일을 만들기

일단 `node_modules` 에 버그를 수정한 패치를 적용해서 작동을 확인했다고 가정하자. (이번 예제에서는 `react-dom`에 `console.log`를 찍어볼 것이다.)

```bash
cp node_modules/react-dom/index.js patches/react-dom-index.js
```

그리고 아래 명령어로 `node_modules`를 다 지운 다음, 다시 설치해서 비교해 볼 것이다.

```bash
rm -rf ./node_modules && npm install
```

## 3. 패치 파일 만들기

그리고 diff 로 비교해보자

```bash
» diff -Naur node_modules/react-dom/index.js patches/react-dom-index.js
--- node_modules/react-dom/index.js     1985-10-26 17:15:00.000000000 +0900
+++ patches/react-dom-index.js  2020-11-23 16:55:32.000000000 +0900
@@ -28,6 +28,8 @@
   }
 }

+console.log('==========REACT DOM START==========')
+
 if (process.env.NODE_ENV === 'production') {
   // DCE check should happen before ReactDOM bundle executes so that
   // DevTools can report bad minification during injection.

```

그리고 이를 `patch`로 export 한다.

```bash
diff -Naur node_modules/react-dom/index.js patches/react-dom-index.js > patches/react-dom-bug.patch
```

```
--- node_modules/react-dom/index.js	1985-10-26 17:15:00.000000000 +0900
+++ patches/react-dom-index.js	2020-11-23 16:55:32.000000000 +0900
@@ -28,6 +28,8 @@
   }
 }

+console.log('==========REACT DOM START==========')
+
 if (process.env.NODE_ENV === 'production') {
   // DCE check should happen before ReactDOM bundle executes so that
   // DevTools can report bad minification during injection.
```

## 4. 적용하기

아까 지우고 다시 설치했기 때문에 버그가 있던 깔끔한 상태로 있을 것이다. 이에 패치 파일을 씌워보자.

```bash
patch --forward node_modules/react-dom/index.js < patches/react-dom-bug.patch
patching file node_modules/react-dom/index.js
```

적용이 잘되었는지 확인해보자. 잘 되었는지 확인 되었다면, 맨처음에 만들었던 파일 (버그 수정버전)을 삭제해도 된다.

```bash
rm patches/react-dom-index.js
```

## 5. `postinstall` 에 걸어두기

[npm postinstall](https://docs.npmjs.com/cli/v6/using-npm/scripts#npm-install)에 걸어두면 설치한 후애 해당 커맨드를 실행한다. `npm install` 과 `npm ci`에서 모두 동작한다.

`package.json`

```json
{
  "postinstall": "patch --forward node_modules/react-dom/index.js < patches/react-dom-bug.patch"
}
```

## 6. 기다리기

이제 오픈소스 컨트리뷰터가 해당 버그를 수정해주시기를 기도하자. 🙏🙏


이러고 있을 때가 아니고 이슈 업해서 오픈소스 컨트리뷰터가 되야 되는데

node_modules에 임시 패치 적용하기

100%의 테스트 리커버리가 도달한 이상적인 세계가 왔다. 오류 처리 또한 완벽했고, 모든 실패는 우아하게 처리되었다. 모든 시스템이 정말로 완벽에 도달했기 때문에, 이런 오류에서의 회복 같은 논의 따위는 필요가 없다.

그러나 나부터 시작해서, 2020년의 지구에는 아직 그런 이상적인 시스템이 있는 곳은 단언코 아무 곳도 없을 것이다. 누군가의 서버는 여전히 프로덕션에서 박살나고 있다.

이 글에서, 서버를 더욱 탄력적으로 만들고 프로세스 관리 능력을 향상시키는 몇가지 개념과 도구를 살펴보자.

## `node index.js`

Nodjs, 특히 서버 관련 작업을 처음 접하는 경우 원격 프로덕션이나, 개발 환경이든간에 동일한 방식으로 앱을 실행한다.

nodejs를 설치하고, repo를 clone하고, `npm install` 이후에 `node index.s`또는 `npm start` 로 시작한다.

이는 모든 프로젝트를 시작하는 완벽한 방법 처럼 보인다. 만약 이게 정말 제대로 작동만 한다면, 우리는 더이상 수정할 필요가 없다.

그러나 사전에 예상하지 못했던 발생할 수가 있다. vm또는 호스트가 재시작 된다면? 서버 크래쉬가 발생한다면?

복구(Recovery)는 다양한 방법으로 처리할 수 있다. 크래시 이후 서버를 다시 시작하는 편리한 솔루션도 있고, 프로덕션을 크래쉬로 부터 안전하게 만드는 것보다 더 우아한 방법들이 많다.

우리가 실행하려는 환경에 따라서, 복구는 다른 특성을 가지고 있다. 개발환경에서의 목표는 편의성이고 (코드를 수정하면 알아서 재시작 되는 것과같은), 프로덕션의 경우에는 오류로부터의 탄력성이라 볼 수 있다.

## 문제가 발생하자 마자 해결하기

개발 환경에서 nodejs 서버를 작성하고 있다고 상상해보자. 몇줄의 코드를 고칠 때마다 탭을 전환하여 `node index`나 `npm start`로 프로세스를 실행한다. 이는 몇번 반복하게 되면 끔찍할 정도로 지루해진다.

코드를 변경한 뒤에 자체적으로 그냥 재시작하면 좋지 않을까?

여기에서 도움이 되는 것이 바로 `nodemon`이다.

```bash
nodemon index.js
```

혹은 `Supervisor`를 동일한 방식으로 사용할 수도 있다.

```bash
supervisor index.js
```

두 서비스 보두 인기만큼이나 유용하다. 두 개의 차이점은, `nodemon`은 코드(파일)이 변경되면 재시작 되는 반면, `supervisor`는 에러가 발생할 때 다시 시작한다는 것이다.

개발 환경에서의 문제는 해결이 쉽다. 그러나 프로덕션 환경의 문제는 다르다. 프로덕션 서버에 내보내기 시작하면 대학을 보낸 부모마냥 안절부절해진다. 여기에서 사용하는 것이 프로세스 관리자다.

## 프로세스 관리

앱을 실행하게 되면, 프로세스가 생성된다.

개발환경에서는, 터미널 윈도우를 열고 코맨드를 실행한다. foreground proccess가 만들어 진것이며, 앱이 실행된다.

그러나 터미널 윈도우를 닫는다면, 앱 또한 종료된다. 또한 터미널 윈도우는 더이상 추가적인 작업을 할 수 없는 상태가 된다. `Ctrl+c`로 끄지 않는 이상, 터미널은 사용할 수 없게 된다.앱 실행이 터미널 윈도우와 강하게 연결되어 있기 때문에, 로그와 에러 또한 볼 수 있다. 그러나 프로덕션 서버에서는 앱을 백그라운드에서 실행해야 하기 때문에 이러한 장점을 잃게 된다.

이 때 등장하는 것이 프로세스 관리자다.

### PM2

nodejs에서 가장 널리 쓰이는 프로세스 관리자는 [PM2](https://github.com/Unitech/pm2)다. `PM2`를 설치하고 아래 명령어로 실행하면 된다.

```bash
pm2 start index.js
```

```bash
===============================================================================
--- PM2 development mode ------------------------------------------------------
Apps started         : src
Processes started    : 1
Watch and Restart    : Enabled
Ignored folder       : node_modules
===============================================================================
```

실행하게 되면, 무언가 다른점을 눈치챌 수 있을 것이다. 마치 아무것도 일어나지 않는 것처럼 보이지만, 앱의 엔드포인트로 가면 앱이 실행중인 것을 알 수 있다. `PM2`는 앞서 언급된 것처럼, 앱을 백그라운드에서 실행하게 해준다. 또한 `--watch` 명령어로 pm2가 파일을 감시하고 재시작하는 것을 볼 수도 있다.

```bash
pm2 start index.js --watch
```

그럼에도 여전히 가시성이 조금은 부족하다. 서버로그를 보기 위해서는, 아래와 같은 명령어를 쓰면 된다.

https://blog.appsignal.com/2020/09/09/nodejs-resiliency-concepts-recovery-and-self-healing.html

| command           | Description                                                                                                           |
| ----------------- | --------------------------------------------------------------------------------------------------------------------- |
| `pm2 list`        | 앱의 목록을 보여준다. pm2에서 관리하고 있는 애플리케이션의 ID를 볼 수 있다. 이 아이디로 아래 명령어를 실행할 수 있다. |
| `pm2 logs <id>`   | 앱의 로그를 확인한다.                                                                                                 |
| `pm2 stop <id>`   | 프로세스를 중단한다. 단순히 중단만 되는 것이므로, 프로세스까지 제거하기 위해서는 `delete` 를 사용해야 한다.           |
| `pm2 delete <id>` | 프로세스를 지운다. 지우게 되면 `stop` 도 이루어진다.                                                                  |

`pm2` 는 설정하기 용이하며, 로드밸런싱도 수행할 수 있고, hot reload도 가능하다.

`pm2`는 놀랍도록 편리하지만, 몇가지더 살펴볼 것이 존재한다.

## Systemd

만약 Linux VM에서 앱을 실행하려고 계획중이라면, 컨테이너와 오케스트레이터 개념을 깊게 들어가기이전에 `systemd`를 언급할 필요가 있다. (그러나 Azure, AWS Lambda, GCP App Engine 등에서 실행하려고 준비중이라면 그다지 필요가 없다.)

`systemd`는 프로세스를 시작, 중지, 재시작을 할수가 있다. VM이 재시작 된다면, `systemd`는 앱이 다시 시작하게끔 도와준다.

`systemd`는 다음 시스템에서 사용가능하다.

- Ubuntu Xenial 또는 그 이상
- Centos 7 / RHGEL 7
- Debian Jessie 또는 그 이상
- Fedora 15 또는 그 이상

추가로 확인해야 할 것은 해당 유저가 `sudo`권한이 있어야 한다는 것이다.

이제부터 예제는 `Ubuntu`를 사용하고 있고, 홈 디렉토리는 `/home/user/`라고 가정하며,`index.js`는 이 홈 디렉토리에 있다고 가정한다.

### systemd 서비스 파일

`systemd` 파일은 서비스에 대한 설정을 보관할 수 있는 시스템영역을 만드는데 도움을 주는 파일이다. 먼저 한번 설정해보자.

`systemd` 파일은 아래 디렉토리에 존재한다.

```bash
/lib/systemd/system
```

```bash
cd /lib/systemd/system
```

```bash
sudo nano myapp.service
```

그리고 이 파일을 만들어보자.

```bash
# /lib/systemd/system/myapp.service

[Unit]
Description=My awesome server
Documentation=https://awesomeserver.com
After=network.target

[Service]
Environment=NODE_PORT=3000
Environment=NODE_ENV=production
Type=simple
User=user
ExecStart=/usr/bin/node /home/user/index.js
Restart=on-failure

[Install]
WantedBy=multi-user.target
```

몇가지 설정들은 꽤 분명하게 되어 있지만, `After` `Type`에 대해서만 알아보자.

`After=network.target`은 포트가 필요하기 때문에, 서버의 네트워킹이 가동되고 실행될 때 까지 기다려야 한다는 것을 의미한다. `Type`은 단순히 미친짓 하지말고 실행하라는 것을 의미한다.

### systemctl로 앱 실행하기

파일을 생성했으니, `systemd`에게 새롭게 변경된 파일을 이용하라고 알려줄 때다. 이 파일에 변화가 있으면, 아래 명령어를 계속 실행해야 한다.

```bash
sudo systemctl daemon-reload
```

이제 `systemctl` 명령을 사용하여 서비스를 시작하고 중지할 수 있어야 한다.

```bash
sudo systemctl start myapp
```

멈추고 싶다면 `stop`을, 재시작하고 싶다면 `restart`를 쓰면 된다.

이제 제일 중요한 부분이다. VM이 실행될 때 애플리케이션이 자동으로 시작되게 하고 싶다면, 아래 명령어를 입력하면 된다.

```bash
sudo systemctl enable myapp
```

작동중지는 `disable`을 쓰면 된다.

이게 전부다. 이제 Node.js가 아닌 프로세스를 관리를 하는 다른 시스템이 생겼다.

하지만 아마도 🤔 요즘 이렇게 리눅스 VM에 직접 서비스를 올려서 굴리는 시스템은 별로 없을 것이다......... 컨테이너로 넘어갈 차례다.

## 컨테이너란 무엇인가

Mesos, CoreOS, LXC, OpenVZ 등 다양한 컨테이너 런타임 환경이 존재하지만, 아마도 가장 유명한 것, 그리고 컨테이너의 진정한 동의어로 취급받는 것은 Docker다. 현재 컨테이너로 굴러가는 시스템의 80%가 Docker로 이루어져 있고, 사람들이 컨테이너를 이야기 하면 아마두 열에 아홉은 도커를 이야기 하고 있다고 봐도 무방하다.

컨테이너가 하는 일은 정확히 무엇인가? 컨테이넌 말그대로 컨테이너다. 그리고 이 컨테이너에는 무엇을 보관하고 있을까?

컨테이너에는 응용프로그램과 그에 필요한 모든 종속성이 포함되어 있다. 단순히 그것 뿐이다. 그렇다면 Nodejs 서버가 가지고 있어야 할 것이 있는지 생각해보자. Nodejs, index.js파일, 그리도 npm 패키지 종속성들이 필요할 것이다. 따라서 컨테이너를 만든다면, 이것이 존재하며 제대로 담겨있는지 확인하고 싶을 것이다. 그리고 컨테이너가 준비되어 있다면, 컨테이너를 컨테이너 엔진(도커)를 이용해 실행 시킬 수 있다.

### Container vs VM

Docker의 마법은 동일한 기반의 물리적 시스템과 운영체제를 사용하여 서로 충돌하지 않고, 다양한 형태의, 다양한 애플리케이션을 원활하게 실행할 수 있다는 것이다.

### 도커 컨테이너 만들기

도커 컨테이너를 만드는 것은 정말로 쉽다. 로컬 머신에 Docker를 먼저 설치하면 된다. Docker는 어떤 운영체제에서든 설치가 가능하지만, 프로덕션 머신에는 Linux 환경에서 설치하기를 권한다.

도커는 `Dockerfile`이라고 불리우는 파일을 참조하며, 도커 이미지라고 불리우는 컨테이너의 레시피를 만드는데 사용할 것이다. 따라서 컨테이너를 만들기 전에 이 파일을 생성해야 한다. `index.js`와 동일한 위치에 생성하면 된다.

```Dockerfile
# Dockerfile

# Base image (we need Node)
FROM node:12

# Work directory
WORKDIR /usr/myapp

# Install dependencies
COPY ./package*.json ./

RUN npm install

# Copy app source code
COPY ./ ./

# Set environment variables you need (if you need any)
ENV NODE_ENV='production'
ENV PORT=3000

# Expose the port 3000 on the container so we can access it
EXPOSE 3000

# Specify your start command, divided by commas
CMD [ "node", "index.js" ]
```

`.dockerignore`를 사용하면 `node_modules`와 같이 복사를 원치 않는 파일목록을 명시할 수 있다. `.gitignore`와 정확히 똑같이 동작한다.

```Dockerfile
# .dockerignore

node_modules
npm-debug.log
```

이제 설정이 완료되었고, Docker Image를 만들 차례다.

이미지는 컨테이너를 만드는 일종의 레시피다. 또는 소프트웨어를 인스톨을 하기 위한 플로피 디스크/씨디롬과 같은 존재로도 볼 수 있다. 이는 실제 작동하는 소프트웨어가 아니지만, 패키징된 소프트웨어 데이터를 포함하고 있다고 보면 된다.

```bash
docker build -t myapp .
```

이미지가 준비되어있다면, 이미지 목록에서 확인할 수 있다.

```bash
docker image ls
```

그리고 실행은 아래와 같이 하면 된다.

```bash
docker run -p 3000:3000 myapp
```

컨테이너에서 시작하는 서버를 볼 수 있고, 그 과정에서 로그도 확인할 수 있다. 백그라운드에서 실행시키기 위해서는 `-d` 플래그를 사용하면 된다. 또한 컨테이너를 백그라운드에서 실행중인 경우, 아래 명령어를 활용하여 컨테이너 목록을 확인할 수 있다.

```bash
docker container ls
```

이제 컨테이너에 대한 이해는 마쳤으므로, 원래 글의 주제인 복구와 매우 밀접한 오케스트레이션에 대해 알아보자.

## Orchestration

이상적으로 생각해봤을때, 레고블록과 같은 인프라는 개별적으로 관리하는 것은 굉장히 손이 많이 가기 때문에 어렵다. 앞서 이야기한 프로세스 관리자 처럼, 다른 존재가 이러한 관리를 대신 해주는 것이 좋을 것이다. 여기에서 오케스트레이터가 활약한다.

오케스트레이터는 컨에테이너를 관리하고 스케줄링 할 수 있도록 도와주며, 여러 위치에 분산되어 흩어져있는 VM (컨테이너 호스트)에 걸쳐서 이러한 작업을 할 수 있도록 해준다.

여기에서 우리가 특히 관심을 가져야 하는 것은 `Replication`이다.

### Replication과 높은 가용성

크래시가 발생했을 때 서버가 재기동하는 것은 좋은일이다. 그러나 재기동 중에는 어떤 일이 생기는가? 사용자들이 서비스가 다시 시작 되길 기다려야 하는가? 우리의 목표는 서비스를 고 가용성으로 만드는 것인데, 이는 사용자들이 서버에서 크래시가 있어도 앱을 사용할 수 있어야 함을 의미한다. 어떻게 하면 가능할까?

답은 간단하다. 서버의 복사본을 만들어두고, 동시에 실행하는 것이다.

처음에 이를 설정하는 것은 골치 아프지만, 다행히도 이 매커니즘을 가능하게 하는 모든 것을 가지고 있다. 일단 앱이 컨테이너화가 되어 있으면, 원하는 만큼의 복사본을 실행할 수 있는데 이를 Replica라고 한다.

이제 컨테이너 오케스트레이션 엔진을 활용하여, 어떻게 이를 설정할지를 알아보자. 여러가지 방법이 있지만, 도커 오케스트레이션 엔진과 가장 쉽게 할 수 있는 방법은 Docker Swarm이다.

### swarm 내의 replication

머신에 Docker가 설치 되어있다면, docker swarm은 비교적 간단하게 시작할 수 있다.

```bash
docker swarm init
```

이 명령어로 Docker swarm을 사용할 수 있으며, 다른 VM을 스웜에 연결하여 분산 클러스터를 구성할 수 있다. 이번 예제에서는, 단순히 하나의 머신만 사용할 것이다.

스웜이 활성화 되어 있으면, 서비스라 불리우는 컴포넌트에 접근할 수 있게 된다. 이는 일종의 마이크로 서비스 아키텍쳐의 빵과 버터인데, replica를 만들기 쉽게 해준다.

이제 서비스를 만들어 보자.

```bash
docker service create --name myawesomeservice --replicas 3 myapp
```

위 명령어는 `myawesomeservice`라 불리우는 서비스를 만들어주며, `myapp`이라고 하는 이미지를 활용하여 3개의 동일한 컨테이너를 만들게 된다.

```bash
docker service ls
```

이제 서버가 복제되어 실행되며, 컨테이너가 크래쉬가 되도 재시작 되며, 프로세스 전체에 결쳐 온전한 컨테이너 엑세스를 제공할 수 있다. 서비스 replica의 수를 조정하기 위해서는 아래 명령어를 활용하면 된다.

```bash
docker service scale <name_of_service>=<number_of_replicas>
```

```bash
docker service scale myapp=5
```

이제 원하는 만큼 복제본을 만들어 실행시킬 수 있다.

### 쿠버네틱스에서의 replication

오케스트레이션을 논하는데 쿠버네틱스를 빼먹으면 섭섭하다. 컨테이너하면 도커 듯이, 오케스트레이션하면 쿠버네틱스다.

개인적인 의견으로는, 도커의 스웜보다 쿠버네틱스가 더 학습하기 어렵다. 따라서 이제 막 컨테이너를 시작했다면, 도커 스웜을 먼저 해보는 것이 좋다. 그렇긴하더라도, 쿠버네틱스 세계가 어떻게 작동하는지 이해하는 것도 나쁘지 않다.

- https://minikube.sigs.k8s.io/docs/start/
- https://labs.play-with-k8s.com/

이 예제에서는 두개의 yaml파일을 만들어 설정을 진행한다. 하나는 A 클러스터 IP 인데, 이는 앱과 통신할 수 있는 포트를 연다. 또다른 하나는 도커 스웜과 같은 서비스이다.

`cluster-ip.yml`

```yaml
# cluster-ip.yml

apiVersion: v1
kind: Service
metadata:
  name: cluster-ip-service
spec:
  type: ClusterIP
  selector:
    component: server
  ports:
    - port: 3000
      targetPort: 3000
```

`development.yml`

```yaml
# deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: server-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      component: server
  template:
    metadata:
      labels:
        component: server
    spec:
      containers:
        - name: server
          image: your_docker_user/your_image
          ports:
            - containerPort: 3000
```

`your_docker_user/your_image`를 실제 도커 유저와 이미지로 교체하고, 도커 레포에 해당 이미지가 호스팅 되고 있는지 확인해야 한다.

이제 아래 명령어를 실행해보자.

```bash
kubectl apply -f .
```

이제 서비스가 실행되고 있는지, 아래 명령어로 확인해볼 수 있다.

```bash
kubectl get deployments
kubectl get services
```

모든 것이 정상적으로 되고 있다면, `cluster-ip-service`에서 보여주는 IP와 포트를 복사하여 브라우저에 붙여넣기 한다면, 애플리케이션에 접속할 수 있을 것이다.

생성된 복제본을 보고 싶다면, 아래 명령어를 활용하면 된다.

```bash
kubectl get pods
```

나열된 pod는 `deployment.yaml`에 지정한 replica의 수와 일치해야 한다. 모든 컴포넌트를 정리하기 위해서는, 아래 명령어를 사용하면 된다.

```bash
kubectl delete -f .
```

## 결론

이제 우리는 고 가용성의 복구 가능한 애플리케이션을 가지고 있다. 물론, 이게 다가 아니다.

실제로 애플리케이션이 고장이 나지 않는데, 어떤 문제가 있는지 어떻게 알까?

로그를 확인해야할까? 만약 엔드포인트를 확인할 때마다 앱이 작동한다면, 아마도 일년에 한두번 정도만 로그를 볼 것이다. 따라서 앱이 개선되고 있는지 확인하기 위해서는 모니터링, 오류처리 및 오류 전파에 대해서 생각해볼 필요가 있다. 문제가 발생할 때마다 인지하고, 서버를 다운시키지 않더라도 문제를 해결할 수 있도록 해봐야 한다.

출처: https://blog.appsignal.com/2020/09/09/nodejs-resiliency-concepts-recovery-and-self-healing.html


아 내 서비스는 완벽해서 그런거 필요 없다니까요?

Nodejs 서비스 Recovery 전략

모든 자바스크립트 프로젝트들은 시작할 때만 하더라도 많은 NPM 패키지를 의존성으로 갖지 않으려고 노력한다. 이런 노력에도 불구하고, 결국 몇몇 패키지를 사용하기 시작한다. `package.json`에 한줄 한줄이 추가될 수록, PR에서 보이는 `package-lock.json`의 추가/삭제 라인 수는 끔찍해진다.

물론 이렇한 과정이 팀리더나 동료들의 반대에 부딪히지는 않는다. 자바스크립트 생태계가 살아있고 계속해서 번창한다는 것은 굉장한 행운이다. 매번 바퀴를 새롭게 발명하거나, 오픈소스 커뮤니티가 해결한 문제를 또 해결하려고 시도해서는 안된다.

블로그를 만들기 위해 gatsby를 쓴다고 가정해보자. 이를 설치하고 dependency에 추가해보자. 이제 1800개의 추가 dependency를 추가했다. 이는 정말 괜찮은 걸까? 자바스크립트의 dependency 트리는 얼마나더 복잡해질 수 있을까? 어떻게 의존성 지옥이 만들어지는 걸까?

## 자바스크립트 패키지

NPM (Node Package Manager)는 세계에서 가장 큰 자바스크립트 패키지 레지스트리르르 보유하고 있다. 이는 RubyGems, PyPi, Maven을 합친 것보다 크다.

![Module Count](./images/module-counts.png)

출처: http://www.modulecounts.com/

정말 많다. 이러한 npm 패키지를 사용하기 위해서는, 프로젝트에 `package.json`을 추가해야 한다.

## package.json

`package.json`은 무엇인가?

- 프로젝트가 의존하고 있는 패키지의 목록
- 시멘틱 버전에 따라서 프로젝트가 의존하고 있는 패키지의 특정버전을 구체적으로 나열
- 빌드를 언제든 다시 만들 수 있게 하여 다른 개발자들이 공유를 쉽게 함

패키지가 다른 패키지에 의존한다고 상상한다면, 왜 `gatsby`가 1.9만개의 추가 종속성을 갖게 되는지 알 수 있을 것이다.

## package.json의 종속성 타입

종속성이 어떻게 누적되는지 이해하기 위해서는, 프로젝트가 가질 수 있는 다양한 종속성 타입을 이해해야 한다.

- `dependencies`: 프로젝트의 코드를 호출하는데 있어 필수적으로 의존하고 있는 종속성
- `devDependencies`: 개발단계에서 필요한 종속성. `prettier`와 같은 코드를 이쁘게 하는 라이브러리 등
- `peerDependencies`: `package.json`에 `peerDependencies`를 설정해둔다면, 패키지를 설치하는 다른 사람들에게 여기에 지정된 버전에 대한 종속성이 필요하다고 말하는 것이다.
- `optionalDependencies`: 옵션 성격의 종속성으로, 이 종속성을 설치 하는데 실패한다 하더라도 설치 과정에 문제가 되지는 않는다.
- `bundleDependencies`: 패키지를 번들링 하는데 같이 들어가게 되는 의존성. NPM에 있지 않은 제3의 라이브러리나, 일부 프로젝트 모듈로 포함하려는 경우 유용하다.

## package-lock.json의 목적

`package-lock.json`은 자동으로 `package.json`이나 `node_modules` 디렉토리가 변할 때 마다 자동으로 생성된다. 이는 설치로 만들어진 정확히 똑같은 의존성 트리를 보관하고 있으며, 후속 설치에도 동일한 트리를 생성할 수 있도록 한다. 이는 나와 다른 사용자가 다른 의존성 트리를 만드는 것을 막는다.

`package.json`에 `react`를 설치한다고 가정해보자. `package-lock.json`에는 이렇게 나와있을 것이다.

```json
{
  "react": {
    "version": "17.0.1",
    "resolved": "https://registry.npmjs.org/react/-/react-17.0.1.tgz",
    "integrity": "sha512-lG9c9UuMHdcAexXtigOZLX8exLWkW0Ku29qPRU8uhF2R9BN96dLCt0psvzPLlHc5OWkgymP3qwTRgbnw5BKx3w==",
    "requires": {
      "loose-envify": "^1.1.0",
      "object-assign": "^4.1.1"
    }
  }
}
```

`package-lock.json`은 프로젝트의 거대한 종속성 목록을 가지고 있다. 여기에는 버전, module의 위치 (URI), 정합성을 위한 해싱값과 패키지가 요구하는 모듈들이 나와있다.

## Gatsby.js의 의존성 살펴보지.

Gatsby는 왜 1800개의 의존성을 갖게 되는 것일까? 답은 의존성의 의존성이다.

```bash
$ npm install --save gatsby

...

+ gatsby@2.27.0
added 1889 packages from 1011 contributors and audited 1889 packages in 51.894s
```

`package.json` 에는 의존성이 딱 하나만 존재하지만,

```json
{
  "name": "test",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "gatsby": "^2.27.0"
  }
}
```

`package-lock.json`에는 이제 만 오천줄이 넘는 종속성이 명시되어있다. 이 문제의 원인은 [gatsby의 package.json](https://github.com/gatsbyjs/gatsby/blob/347be6f6fbaa2f9b2e252e6f329ce7fe96f6f2b2/packages/gatsby/package.json#L12-L162)에 있다.

```bash
test@1.0.0 /Users/yceffort/private/test
└─┬ gatsby@2.27.0
  ├─┬ @babel/core@7.12.3
  │ ├─┬ @babel/helper-module-transforms@7.12.1
  │ │ └── lodash@4.17.20  deduped
  │ └── lodash@4.17.20  deduped
  ├─┬ @babel/traverse@7.12.5
  │ └── lodash@4.17.20  deduped
  ├─┬ @babel/types@7.12.6
  │ └── lodash@4.17.20  deduped
  ├─┬ @typescript-eslint/parser@2.34.0
  │ └─┬ @typescript-eslint/typescript-estree@2.34.0
  │   └── lodash@4.17.20  deduped
  ├─┬ babel-plugin-lodash@3.3.4
  │ └── lodash@4.17.20  deduped
  ├─┬ babel-preset-gatsby@0.7.0
  │ └─┬ @babel/preset-env@7.12.1
  │   ├─┬ @babel/plugin-transform-classes@7.12.1
  │   │ └─┬ @babel/helper-define-map@7.10.5
  │   │   └── lodash@4.17.20  deduped
  │   └─┬ @babel/plugin-transform-sticky-regex@7.12.1
  │     └─┬ @babel/helper-regex@7.10.5
  │       └── lodash@4.17.20  deduped
  ├─┬ css-loader@1.0.1
  │ └── lodash@4.17.20  deduped
  ├─┬ devcert@1.1.3
  │ └── lodash@4.17.20  deduped
  ├─┬ eslint@6.8.0
  │ ├─┬ inquirer@7.3.3
  │ │ └── lodash@4.17.20  deduped
  │ ├── lodash@4.17.20  deduped
  │ └─┬ table@5.4.6
  │   └── lodash@4.17.20  deduped
  ├─┬ eslint-plugin-flowtype@3.13.0
  │ └── lodash@4.17.20  deduped
  ├─┬ gatsby-cli@2.14.0
  │ ├─┬ gatsby-recipes@0.4.0
  │ │ ├─┬ contentful-management@5.28.0
  │ │ │ ├─┬ contentful-sdk-core@6.4.6
  │ │ │ │ └── lodash@4.17.20  deduped
  │ │ │ └── lodash@4.17.20  deduped
  │ │ ├── lodash@4.17.20  deduped
  │ │ └─┬ remark-mdxjs@2.0.0-next.8
  │ │   └─┬ @babel/core@7.10.5
  │ │     └── lodash@4.17.20  deduped
  │ ├── lodash@4.17.20  deduped
  │ └─┬ pretty-error@2.1.2
  │   ├── lodash@4.17.20  deduped
  │   └─┬ renderkid@2.0.4
  │     └── lodash@4.17.20  deduped
  ├─┬ gatsby-plugin-page-creator@2.5.0
  │ ├─┬ gatsby-page-utils@0.4.0
  │ │ └── lodash@4.17.20  deduped
  │ └── lodash@4.17.20  deduped
  ├─┬ gatsby-telemetry@1.5.0
  │ └── lodash@4.17.20  deduped
  ├── lodash@4.17.20
  ├─┬ optimize-css-assets-webpack-plugin@5.0.4
  │ └─┬ last-call-webpack-plugin@3.0.0
  │   └── lodash@4.17.20  deduped
  ├─┬ react-dev-utils@4.2.3
  │ └─┬ inquirer@3.3.0
  │   └── lodash@4.17.20  deduped
  ├─┬ webpack-dev-server@3.11.0
  │ ├─┬ http-proxy-middleware@0.19.1
  │ │ └── lodash@4.17.20  deduped
  │ └─┬ portfinder@1.0.28
  │   └─┬ async@2.6.3
  │     └── lodash@4.17.20  deduped
  └─┬ webpack-merge@4.2.2
    └── lodash@4.17.20  deduped
```

gatsby의 lodash 의존을 살펴보면, 모두 같은 버전의 lodash를 사용하고 있기 때문에, `node_modules` 에는 하나의 `lodash` 만 설치해도 된다는 것을 알 수 있다. 그렇지만 만약 다른 버전에 각각 의존하고 있다면 해당 버전을 모두 설치해야 되므로 사이즈가 커지게 된다.

```bash
» du -sh node_modules
348M	node_modules
```

300메가 정도면 괜찮은 편이다. 만약 `node_modules`에서 무엇이 비중을 많이 차지 하는지 살펴보고 싶다면 아래 명령어를 실행하면 된다.

```bash
» du -sh ./node_modules/* | sort -nr | grep '\dM.*'
 30M	./node_modules/@graphql-tools
 20M	./node_modules/date-fns
 17M	./node_modules/rxjs
 14M	./node_modules/gatsby
 14M	./node_modules/@babel
8.7M	./node_modules/prettier
8.4M	./node_modules/babel-runtime
8.3M	./node_modules/gatsby-recipes
6.9M	./node_modules/core-js
6.8M	./node_modules/core-js-pure
5.5M	./node_modules/eslint
5.1M	./node_modules/moment
5.1M	./node_modules/@types
4.9M	./node_modules/webpack
4.8M	./node_modules/lodash
...
```

(저놈의 graphql...)

`node_modules`의 사이즈를 줄이고, 종속성을 평평하게 만드는 명령어는 `npm dedup`이다. 중복된 종속성을 정리하는데 도움을 준다.

```bash
» npm dedup
audited 1889 packages in 3.36s

134 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
```

[Deduplication](https://docs.npmjs.com/cli/dedupe)은 종속성 사이의 공통 패키지를 찾고, 이러한 패키지가 재사용될 수 있도록 하여 종속성 트리 구조를 단순화 시키는 작업이다.

## 의존성 한눈에 보기

https://npm.anvaka.com/#/view/2d/eslint-config-yceffort

![npm-anvaka](./images/npm-anvaka.png)

http://npm.broofa.com/?q=eslint-config-yceffort

![npm-broofa](./images/npm-broofa.png)

https://packagephobia.com/result?p=eslint-config-yceffort@0.0.5

![npm-phobia](./images/npm-phobia.png)

## npm install, ci

`npm install`이 이따금씩 `package-lock.json`을 업데이트 하는 이유는, `package.json`에 정확하게 지정된 버전이 아닌 시멘틱 버전으로 작성되어 있기 때문이다. 예를 들어 `^1.1.0`으로 설치된 패키지가 있고, 시간이 흘러 `1.1.9`버전이 나온다면 `package-lock.json`은 기존 버전에서 `^1.1.9`로 설치하려 할것이다.

https://github.com/npm/npm/issues/18103

이를 막기 위한 명령어가 `npm ci`다. `package.json`이 아닌 `package-lock.json`에 명시된 버전 그 자체로 `package-lock.json`의 변경이 없이 설치를 수행한다. 많은 프로젝트에서 놓치는 것 중 하나가, 빌드나 배포단계에서 `npm ci`대신 `npm install`을 쓰는 것이다. 이는 개발단계에서는 몰랐던 얘기치 않은 에러를 낳을 수 있다.

https://blog.npmjs.org/post/621733939456933888/npm-v7-series-why-keep-package-lockjson

항상 감사하십시오, javascript developers.


Javascript 8

뒤로가기, 앞으로가기의 캐시 aka bfcache

자바스크립트로 메모이제이션 구현하기

node_modules에 임시 패치 적용하기

Nodejs 서비스 Recovery 전략

자바스크립트 의존성 지옥