모든 자바스크립트 프로젝트들은 시작할 때만 하더라도 많은 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.

자바스크립트 의존성 지옥

모든 자바스크립트 프로젝트들은 시작할 때만 하더라도 많은 NPM 패키지를 의존성으로 갖지 않으려고 노력한다. 이런 노력에도 불구하고, 결국 몇몇 패키지를 사용하기 시작한다. <code>package.json</code>에 한줄 한줄이 추가될 수록, PR에서 보이는 <code>package-lock.json</code>의 추가/삭제 라인 수는 끔찍해진다.
물론 이렇한 과정이 팀리더나 동료들의 반대에 부딪히지는 않는다. 자바스크립트 생태계가 살아있고 계속해서 번창한다는 것은 굉장한 행운이다. 매번 바퀴를 새롭게 발명하거나, 오픈소스 커뮤니티가 해결한 문제를 또 해결하려고 시도해서는 안된다.
블로그를 만들기 위해 gatsby를 쓴다고 가정해보자. 이를 설치하고 dependency에 추가해보자. 이제 1800개의 추가 dependency를 추가했다. 이는 정말 괜찮은 걸까? 자바스크립트의 dependency 트리는 얼마나더 복잡해질 수 있을까? 어떻게 의존성 지옥이 만들어지는 걸까?
<h2 id="자바스크립트-패키지">자바스크립트 패키지</h2>
NPM (Node Package Manager)는 세계에서 가장 큰 자바스크립트 패키지 레지스트리르르 보유하고 있다. 이는 RubyGems, PyPi, Maven을 합친 것보다 크다.
<img src="./images/module-counts.png" alt="Module Count">
출처: <a href="http://www.modulecounts.com/">http://www.modulecounts.com/</a>
정말 많다. 이러한 npm 패키지를 사용하기 위해서는, 프로젝트에 <code>package.json</code>을 추가해야 한다.
<h2 id="packagejson">package.json</h2>
<code>package.json</code>은 무엇인가?
<ul>
<li>프로젝트가 의존하고 있는 패키지의 목록</li>
<li>시멘틱 버전에 따라서 프로젝트가 의존하고 있는 패키지의 특정버전을 구체적으로 나열</li>
<li>빌드를 언제든 다시 만들 수 있게 하여 다른 개발자들이 공유를 쉽게 함</li>
</ul>
패키지가 다른 패키지에 의존한다고 상상한다면, 왜 <code>gatsby</code>가 1.9만개의 추가 종속성을 갖게 되는지 알 수 있을 것이다.
<h2 id="packagejson의-종속성-타입">package.json의 종속성 타입</h2>
종속성이 어떻게 누적되는지 이해하기 위해서는, 프로젝트가 가질 수 있는 다양한 종속성 타입을 이해해야 한다.
<ul>
<li><code>dependencies</code>: 프로젝트의 코드를 호출하는데 있어 필수적으로 의존하고 있는 종속성</li>
<li><code>devDependencies</code>: 개발단계에서 필요한 종속성. <code>prettier</code>와 같은 코드를 이쁘게 하는 라이브러리 등</li>
<li><code>peerDependencies</code>: <code>package.json</code>에 <code>peerDependencies</code>를 설정해둔다면, 패키지를 설치하는 다른 사람들에게 여기에 지정된 버전에 대한 종속성이 필요하다고 말하는 것이다.</li>
<li><code>optionalDependencies</code>: 옵션 성격의 종속성으로, 이 종속성을 설치 하는데 실패한다 하더라도 설치 과정에 문제가 되지는 않는다.</li>
<li><code>bundleDependencies</code>: 패키지를 번들링 하는데 같이 들어가게 되는 의존성. NPM에 있지 않은 제3의 라이브러리나, 일부 프로젝트 모듈로 포함하려는 경우 유용하다.</li>
</ul>
<h2 id="package-lockjson의-목적">package-lock.json의 목적</h2>
<code>package-lock.json</code>은 자동으로 <code>package.json</code>이나 <code>node_modules</code> 디렉토리가 변할 때 마다 자동으로 생성된다. 이는 설치로 만들어진 정확히 똑같은 의존성 트리를 보관하고 있으며, 후속 설치에도 동일한 트리를 생성할 수 있도록 한다. 이는 나와 다른 사용자가 다른 의존성 트리를 만드는 것을 막는다.
<code>package.json</code>에 <code>react</code>를 설치한다고 가정해보자. <code>package-lock.json</code>에는 이렇게 나와있을 것이다.
<pre class="language-json"><code class="language-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"
 }
 },
}
</code></pre>
<code>package-lock.json</code>은 프로젝트의 거대한 종속성 목록을 가지고 있다. 여기에는 버전, module의 위치 (URI), 정합성을 위한 해싱값과 패키지가 요구하는 모듈들이 나와있다.
<h2 id="gatsbyjs의-의존성-살펴보지">Gatsby.js의 의존성 살펴보지.</h2>
Gatsby는 왜 1800개의 의존성을 갖게 되는 것일까? 답은 의존성의 의존성이다.
<pre class="language-bash"><code class="language-bash">$ npm install --save gatsby

...

+ gatsby@2.27.0
added 1889 packages from 1011 contributors and audited 1889 packages in 51.894s
</code></pre>
<code>package.json</code> 에는 의존성이 딱 하나만 존재하지만,
<pre class="language-json"><code class="language-json">{
 "name": "test",
 "version": "1.0.0",
 "description": "",
 "main": "index.js",
 "scripts": {
 "test": "echo \"Error: no test specified\" &#x26;&#x26; exit 1"
 },
 "author": "",
 "license": "ISC",
 "dependencies": {
 "gatsby": "^2.27.0"
 }
}
</code></pre>
<code>package-lock.json</code>에는 이제 만 오천줄이 넘는 종속성이 명시되어있다. 이 문제의 원인은 <a href="https://github.com/gatsbyjs/gatsby/blob/347be6f6fbaa2f9b2e252e6f329ce7fe96f6f2b2/packages/gatsby/package.json#L12-L162">gatsby의 package.json</a>에 있다.
<pre class="language-bash"><code class="language-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
</code></pre>
gatsby의 lodash 의존을 살펴보면, 모두 같은 버전의 lodash를 사용하고 있기 때문에, <code>node_modules</code> 에는 하나의 <code>lodash</code> 만 설치해도 된다는 것을 알 수 있다. 그렇지만 만약 다른 버전에 각각 의존하고 있다면 해당 버전을 모두 설치해야 되므로 사이즈가 커지게 된다.
<pre class="language-bash"><code class="language-bash">» du -sh node_modules
348M	node_modules
</code></pre>
300메가 정도면 괜찮은 편이다. 만약 <code>node_modules</code>에서 무엇이 비중을 많이 차지 하는지 살펴보고 싶다면 아래 명령어를 실행하면 된다.
<pre class="language-bash"><code class="language-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
...
</code></pre>
(저놈의 graphql...)
<code>node_modules</code>의 사이즈를 줄이고, 종속성을 평평하게 만드는 명령어는 <code>npm dedup</code>이다. 중복된 종속성을 정리하는데 도움을 준다.
<pre class="language-bash"><code class="language-bash">» npm dedup
audited 1889 packages in 3.36s

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

found 0 vulnerabilities
</code></pre>
<a href="https://docs.npmjs.com/cli/dedupe">Deduplication</a>은 종속성 사이의 공통 패키지를 찾고, 이러한 패키지가 재사용될 수 있도록 하여 종속성 트리 구조를 단순화 시키는 작업이다.
<h2 id="의존성-한눈에-보기">의존성 한눈에 보기</h2>
<a href="https://npm.anvaka.com/#/view/2d/eslint-config-yceffort">https://npm.anvaka.com/#/view/2d/eslint-config-yceffort</a>
<img src="./images/npm-anvaka.png" alt="npm-anvaka">
<a href="http://npm.broofa.com/?q=eslint-config-yceffort">http://npm.broofa.com/?q=eslint-config-yceffort</a>
<img src="./images/npm-broofa.png" alt="npm-broofa">
<a href="https://packagephobia.com/result?p=eslint-config-yceffort@0.0.5">https://packagephobia.com/result?p=eslint-config-yceffort@0.0.5</a>
<img src="./images/npm-phobia.png" alt="npm-phobia">
<h2 id="npm-install-ci">npm install, ci</h2>
<code>npm install</code>이 이따금씩 <code>package-lock.json</code>을 업데이트 하는 이유는, <code>package.json</code>에 정확하게 지정된 버전이 아닌 시멘틱 버전으로 작성되어 있기 때문이다. 예를 들어 <code>^1.1.0</code>으로 설치된 패키지가 있고, 시간이 흘러 <code>1.1.9</code>버전이 나온다면 <code>package-lock.json</code>은 기존 버전에서 <code>^1.1.9</code>로 설치하려 할것이다.
<a href="https://github.com/npm/npm/issues/18103">https://github.com/npm/npm/issues/18103</a>
이를 막기 위한 명령어가 <code>npm ci</code>다. <code>package.json</code>이 아닌 <code>package-lock.json</code>에 명시된 버전 그 자체로 <code>package-lock.json</code>의 변경이 없이 설치를 수행한다. 많은 프로젝트에서 놓치는 것 중 하나가, 빌드나 배포단계에서 <code>npm ci</code>대신 <code>npm install</code>을 쓰는 것이다. 이는 개발단계에서는 몰랐던 얘기치 않은 에러를 낳을 수 있다.
<a href="https://blog.npmjs.org/post/621733939456933888/npm-v7-series-why-keep-package-lockjson">https://blog.npmjs.org/post/621733939456933888/npm-v7-series-why-keep-package-lockjson</a>
항상 감사하십시오, javascript developers.

## Table of Contents

## 자바스크립트의 메모리 관리

Nodejs의 메모리 누수를 이해하기 위해서는, nodejs의 메모리 관리에 대해서 이해하고 있어야 한다. nodejs는 자바스크립트의 V8엔진을 사용하고 있다. 이에 대해 이해하기 위해서는, 아래 포스트를 먼저 참고할 필요가 있다.

- https://dev.to/deepu105/visualizing-memory-management-in-v8-engine-javascript-nodejs-deno-webassembly-105p
- https://yceffort.kr/2020/11/v8-memory-management

메모리는 크게 스택과 힙메모리로 구별할 수 있다.

- Stack: 메소드, 함수 프레임, 원시값, 객체의 포인터등 정적인 데이터가 저장되는 곳
- Heap: 객체 또는 다이나믹 데이터 등이 저장되는 곳. 메모리 블록중 가장 큰 영역이며, GC가 작업을 하는 곳

> V8은 가비지 콜렉션을 이용해서 힙 메모리를 관리한다. 간단히 얘기해, 스택에서 더이상 참조하지 않는 객체의 메모리를 해제하여 다른 객체가 메모리를 할당하여 쓸 수 있도록 한다. V8의 가비지 컬렉터는 더이상 사용하지 않는 메모리를 해제하여 공간을 확보하는 책임이 있다. V8 가비지 컬렉터는 객체를 생성시점으로 묶어서 각각 다른 스테이지별로 별도로 관리한다. V8 가비지 컬렉터는 2개의 다른 스테이지와 세개의 다른 알고리즘을 사용한다.

![V8 Garbage Collector](https://d33wubrfki0l68.cloudfront.net/e3979bee7b7b51e6124594ea36dfde4eb7015da5/5c860/images/blog/2020-05/mark-sweep-compact.gif)

## 메모리 누수란 무엇인가

간단히 말해 메모리 누수랑, 애플리케이션에서 더이상 사용하지 않는 메모리가 힙에서 계속 남아 있고, 그래서 이를 가비지 컬렉터가 OS로 메모리로 반환하지 못하는 상황을 의미한다. 이는 메모리에서 쓸모없는 블록으로 존재하게 된다. 이러한 블록이 계속해서 생기게 되면 애플리케이션에서는 더이상 사용할 메모리가 존재하지 않게 되고, 나아가 OS 또한 할당할 메모리가 남아나지 않아서 애플리케이션이 느려지고 크래쉬되거나, 혹은 OS 단에서 문제가 발생할 수 있다.

## 자바스크립트에서는 무엇이 메모리 누수를 발생시키는가?

V8의 가비지 콜렉터와 같은 자동 메모리 관리는 메모리 누수를 피하는데 초점이 맞춰져있다. 예를 들어 순환 참조는 가비지 콜렉터의 고려대상이 아니지만, 힙의 원치 않는 참조로 인해 문제가 발생할 수 있다. 일반적인 메모리 누수의 상황은 아래와 같다.

- 전역변수: 자바스크립트의 전역 변수는 루트 노드를 참조하기 때문에 (`window`, `global`) 애플리케이션의 생명주기 동안 절대로 가비지 콜렉팅이 되지 않아 계속해서 메모리를 점유하고 있게 된다. 따라서 글로벌 변수를 참조 하고 있는 객체 또한 가비지 콜렉팅의 대상이 되지 않는다는 것을 의미한다. 루트로부터 커다란 객체 참조 그래프를 가지고 있다는 것은 결국 메모리 누수로 이어지게 된다.
- 동시참조: 하나의 동일한 객체가 다양한 객체에서 참조될 때, 이 중 하나의 참조가 잘못된다면 전체 객체에서 메모리 누수가 발생할 수 있다.
- 클로져: 자바스크립트의 클로져는 코드를 둘러싼 콘텍스트를 기억한다는 점에서 멋진 기능이다. 클로져가 힙의 큰객체의 클로져를 참조하고 있다면, 클로져가 사용될 때 까지 그 객체는 메모리에 남아 있게 된다. 이는 메모리 누수의 원인으로 이어질 수 있다.
- 타이머 & 이벤트: `setTimeout` `setInterval` `Observer` 이벤트 리스너 등의 콜백이 적절한 조치 없이 무거운 객체의 참조를 가지고 있을 경우 메모리 누수가 발생할 수 있다.

## 메모리 누수를 피하는 방법

### 전역 변수의 사용을 줄인다.

전역 변수는 절대로 가비지 컬렉팅 되지 않으므로, 전역변수를 남용하지 않는 것이 제일 좋다.

#### 실수로 전역변수를 선언하는 것을 주의하자.

만약 undeclare한 변수를 선언하게 되면, 자동으로 자바스크립트는 이를 호이스팅해서 전역 변수로 만들어 버린다. 이는 곧 메모리 누수로 이어지게 된다.

```javascript
function hello() {
  // 전역변수로 호이스팅 된다.
  foo = 'Message'
}

function hello() {
  // 여기서 this는 global 이기 때문에 마찬가지로 호이스팅되어 전역변수가 된다.
  this.foo = 'Message'
}
```

이러한 원치 안흔ㄴ 사고를 방지 하기 위해서는, 자바스크립트 파일 상단에 `'use strict';`를 선언해 두면된다. 엄격한 모드에서는, 위의 코드는 에러를 발생시킨다. 만약 ES 모듈이나 타입스크립트 또는 바벨과 같은 프랜스파일러를 사용한다면, 굳이 하지 않아도 된다. 최근 버전의 Nodejs에서는, `--use_strict` 옵션으로 nodejs 환경 전역에 이 모드를 활성화 시킬 수 있다.

```javascript
'use strict'

// This will not be hoisted as global variable
function hello() {
  foo = 'Message' // will throw runtime error
}

// This will not become global variable as global functions
// have their own `this` in strict mode
function hello() {
  this.foo = 'Message'
}
```

화살표 함수를 사용하면, 마찬가지로 전역변수를 생성할수도 있다는 사실을 조심해야 한다. 이러한 경우에는 엄격모드로는 해결할 수가 없고, eslint의 `no-invalid-this`로 해결하면 된다.

```javascript
// 전역변수로 할당된다.
const hello = () => {
    this.foo = 'Message";
}
```

마지막으로, `bind`와 `call`을 사용하는 함수에 전역 `this`를 바인딩하지 않도록 주의한다.

#### 글로벌 스코프 사용을 줄인다.

글로벌 스코프의 사용은 가능한 줄이는 것이 좋다.

1. 가능한, 글로벌 스코프는 사용하지 않는 것이 좋다. 대신, 함수의 지역 스코프를 사용하여 카비지 콜렉터가 원할 때 메모리를 수집할 수 있게 해주자. 만약 특별한 제한 때문에 전역 스코프를 사용해야 한다면, 더이상 사용하지 않게 되는 시점에 `null`을 넣어주면 된다.
2. 전역변수는 오직 상수, 캐시 또는 재사용할 싱글턴 패턴에만 사용해야 한다.함수와 클래스간에 데이터를 공유하기 위해서는, 파라미터와 객체의 속성값으로 전달해주는 것이 좋다.
3. 큰 객체를 전역 변수에 저장하지 말자. 만약 꼭 저장해야 한다면, 더이상 사용하지 않을 때 null 처리를 해줘야 한다. 캐시 객체의 경우, 이 객체가 점점 커지는 것을 방지해야 한다.

### 스택 메모리를 잘 활용하자.

스택 접근은 힙 접근 보다 성능적으로도 우월하고, 메모리의 효율성도 높기 때문에 가능한 스택 변수를 많이 활용해야 한다. 이는 또한 실수로 일어나는 메모리 누수도 방지해준다. 물론, 실무상으로 오로지 스태틱 데이터만 쓸 수 있는 일은 없다. 실제 에플리케이션은, 다양한 객체와 다이나믹 데이터를 사용해야 한다. 하지만 몇가지 트릭을 사용하여 스택을 조금 더 효율적으로 쓸 수 있다.

1. 스택 변수로부터 힙객체 참조하는 것을 가능한 피해야 한다. 또한, 사용하지 않는 변수를 그냥 둬서는 안된다.
2. 객체나 배열 내부의 값을 넘길 때는 전체 객체를 통째로 넘기는 대신에 이를 분해해서 필요한 것만 넘기는 것이 좋다. 이는 클로져 내부에서 불필요한 객체 참조를 피할 수 있다. 객체내부의 값은 대부분 원시값이므로, 이는 스택을 사용하는데 도움이 될 것이다.

```javascript
function outer() {
    const obj = {
        foo: 1,
        bar: "hello",
    };

    const closure = () {
      // 구조분해 할당을 써서 필요한 foo만 꺼내왔다.
        const { foo } = obj;
        myFunc(foo);
    }
}

function myFunc(foo) {}
```

### 힙 메모리를 효율적으로 활용하자

실제 애플리케이션에서 힙메모리의 사용을 피할수는 없지만, 아래 팁들을 이용하면 좀더 효율적으로 사용할 수 있다.

1. 참조를 넘기는 대신에 가능하면 객체를 복사하는게 좋다. 참조를 넘기는 것은 객체가 크거나, 복사하는 작업이 비쌀때만 활용한다.
2. 객체의 변이를 가능한 피해야 한다. 그 대신 전개 연산자를 사용하거나 `Object.assign`으로 복사하는 것이 좋다.
3. 하나의 객체에 여러가지 참조를 만드는 것을 피해야 한다. 대신에 객체를 복사하는 것이 좋다.
4. 수명이 짧은 변수를 활용하자.
5. 큰 객체 트리를 만드는 것을 피해야 한다. 만약 이러한 것이 불가능하다면, 지역변수 내에서 보관하는 것이 좋다.

### 클로저, 타이버, 이벤트 핸들러를 적절히 활용하자.

앞서 언급했던 것처럼 클로져, 타이버, 그리고 이벤트 핸들러는 메모리 누수가 일어날 수 있는 영역이다. 아래 코드를 살펴보자.`longStr`은 절대 가비지 콜렉팅이 되지 않고, 또한 점점 커지기 때문에 메모리 누수의 원인이 된다.

참고: https://blog.meteor.com/an-interesting-kind-of-javascript-memory-leak-8b47d2e7f156?gi=275d4bdd446b

```javascript
var theThing = null
var replaceThing = function () {
  var originalThing = theThing
  var unused = function () {
    if (originalThing) console.log('hi')
  }
  theThing = {
    longStr: new Array(1000000).join('*'),
    someMethod: function () {
      console.log(someMessage)
    },
  }
}
setInterval(replaceThing, 1000)
```

위 코드는 여러 클로져를 만들고, 이 클로져들은 각각 객체 참조를 가지고 있게 된다. 이 경우 메모리 누수를 해결하기 위해서는 `replaceThing`함수 끝에서 `originalThing`을 `null`로 선언해주어야 한다. 이러한 경우도 객체의 복사본을 만들거나, 앞서 언급한 `null`을 하는 전략으로 메모리 누수를 피할 수 있다.

이벤트 리스너와 observer도 마찬가지다. 작업이 끝나면 이들을 클리어해주어야 한다. 이들이 영원히 참조하고 있게 해서는 안된다. 특히 부모 스코프의 객체를 참조하고 있다면 더욱 위험하다.

## 결론

자바스크립트 엔진의 진화와 언어의 성장으로 인하여, 자바스크립트의 메모리 누수는 우리가 생각하는 것 만큼 잦은 이슈는 아니다. 그러나 주의를 기울이지않으면, 성능 문제를 야기하거나 애플리케이션과 OS의 크래쉬를 야기할 수 있다. 메모리 누수가 일어나지 않기 위해 첫번째로 우리가 할일은 V8이 어떻게 메모리를 관리하는 지다. 그 다음에는 무엇이 메모리 누수를 일으키는지 알아야 한다. 이에 대해 이해하고 있고, 그리고 만약 메모리 누수 문제가 발생한다면, 우리는 무엇을 살펴보아야 하는지 알 수 있게 된다. 만약 Nodejs에서 메모리 누수 문제가 발생한다면, 아래 두 개의 링크를 확인해보자.

- https://github.com/lloyd/node-memwatch
- https://nodejs.org/en/docs/guides/debugging-getting-started/

출처

- https://blog.appsignal.com/2020/05/06/avoiding-memory-leaks-in-nodejs-best-practices-for-performance.html

참고

- https://www.ibm.com/developerworks/web/library/wa-memleak/wa-memleak-pdf.pdf
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management
- https://docs.microsoft.com/en-us/previous-versions/msdn10/ff728624(v=msdn.10)
- https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/
- https://blog.meteor.com/an-interesting-kind-of-javascript-memory-leak-8b47d2e7f156


성능은 좋을 수록 좋다 그것이 성능이니까

Nodejs 성능 최적화를 위한 방법

## V8 메모리 구조

![V8 memory](https://i.imgur.com/kSgatSL.png)

### Heap Memory

이 영역이 V8이 객체나 다이나믹 데이터를 담아두는 영역이다. 여기는 메모리 영역 중에서 가장 큰 부분을 차지하며, 가비지 컬렉션이 발생하는 곳이다. 전체 힙메모리가 가비지 컬렉팅이 되는 것은 아니며, 오직 New Space와 Old Space만 가비지 컬렉팅의 대상이 된다.

- New Space: New Space 또는 `Young generation`이라 불리는 곳이며, 새로운 객체 또는 단기간 유효한 객체들이 존재하는 곳이다. 이 영역은 상대적으로 작고, 두개의 별도 공간인 `Semi Space`가 존재한다. 이는 JVM의 `S0` `S1`과 비슷하다고 볼 수 있다. 이 공간은 `Scavenger`이른바 `Minor GC`에 의해서 관리된다. 이 사이즈의 영역은 `--mini_semi_space_size`와 `--max-_semi_space_size`로 조절할 수 있다.
- Old Space: Old Space 또는 `Old generation`이라고 불리는 곳이며, `new space`에서 minor GC 사이클로부터 살아남은 객체들이 이동하는 곳이다. 이 영역은 `Major GC(Mark-Sweep & Mark-Compact)`에 의해서 관리된다. 이 공간의 사이즈는 `--initial_old_space_size`와 `--max_old_space_size`로 설정할 수 있다. 이 영역은 두개로 나눠진다.
 - Old Pointer Space: 다른 객체를 가르키는 객체가 보관 되는 곳
 - Old Data Space: 단순히 데이터만 가지고 있는 객체 (특정 객체를 가르키지 않음). Strings, boxed numbers, unboxed doubles의 배열이 `New Space`의 두번의 minor GC Cycle로 부터 살아남는다면 이쪽으로 이동하게 된다.
- Large object Space: 다른 Space에 있기에 너무 큰 객체들이 여기에 존재하게 된다. 각 객체들은 [mmap](https://en.wikipedia.org/wiki/Mmap)을 갖게 된다. 큰 객체들은 절대 가비지 콜렉터에 의해 이동하지 않는다.
- Code space: `Just In Time(JIT)` 컴파일러가 컴파일된 코드 블록을 보관하는 곳이다. 실행가능한 메모리가 존재할 수 있는 유일한 곳이다. (코드의 양이 커져서 `Large Object Space`로 가더라도, 여전히 실행 가능하다.)
- Cell space, property cell space, map space: 이는 각각 `Cells` `PropertyCells` `Maps`를 가지고 있는다. 각각의 공간에는 모두 동일한 크기의 객체가 포함되어 있으며, 어떤 종류의 객체를 가리킬 수 있는지에 대한 제한이 있기 때문에 수집을 단순화 한다.

각각의 공간은 pages의 세트로 구성되어 있다. 여기서 페이지란, 운영체제 mmap에서 할당된 연속적인 메모리 청크를 의미한다. `Large Object Space`를 제외하고는, 각각 1MB이다.

### Stack

스택 메모리 영역으로, V8 프로세스 하나당 한개의 스택을 가지고 있다. 메서드/함수 프레임, 원시 값, 객체를 가르키는 포인터등 정적인 데이터를 보유하고 있는 곳이다. 이 스택 메모리의 크기는 `-stack_size`로 결정할 수 있다.

## V8의 메모리 사용 (Stack vs Heap)

메모리가 어떤 구조로 되어 있는지 알아봤으니, 이제는 중요한 부분 인 프로그램이 실행될 때 각 부분이 어떻게 사용되는지를 알아보자. 아래 예제 코드를 살펴보자.

```javascript
class Employee {
 constructor(name, salary, sales) {
 this.name = name
 this.salary = salary
 this.sales = sales
 }
}

const BONUS_PERCENTAGE = 10

function getBonusPercentage(salary) {
 const percentage = (salary * BONUS_PERCENTAGE) / 100
 return percentage
}

function findEmployeeBonus(salary, noOfSales) {
 const bonusPercentage = getBonusPercentage(salary)
 const bonus = bonusPercentage * noOfSales
 return bonus
}

let john = new Employee('John', 5000, 5)
john.bonus = findEmployeeBonus(john.salary, john.sales)
console.log(john.bonus)
```

<script async class="speakerdeck-embed" data-id="e89e2e48a797417eb8692897dcada584" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

- `Global Scope`는 스택의 `Global Frame`내에 존재한다.
- 모든 함수 호출은 스택 메모리에 `frame-block` 형태로 추가된다.
- 모든 지역변수, arguments, 그리고 리턴 값은 위에서 언급한 함수 `frame-block` 내에 저장된다.
- 모든 원시값은 스택에 바로 저장된다. 이는 전역변수에 있어도 마찬가지다.
- 모든 객체는 힙에 생성되며, 스택에서 스택 포인터를 활용하여 참조된다. 함수는 자바스크립트에서 단순히 객체다. 이는 전역변수에서도 마찬가지다.
- 현재 함수에서 실행된 새로운 함수는 스택의 맨 위에 쌓인다.
- 함수가 프레임을 리턴하면 이는 스택에서 제거 된다.
- 메인 프로세스가 완료되면, 힙에 있는 객체는 스택에서 더이상 가리키는 포인터가 없으므로 고립되어 버린다.
- 따로 복제를 명시적으로 만들어두지 않는 이상, 다른 객체안에 있는 모든 객체 참조는 참조 포인터를 사용해서 완료된다.

보시다시피, 스택은 자동으로 관리되며, 이는 V8이 아닌 운영체재가 수행한다. 따라서 우리는 스택에 대해서 많은 신경을 쓸필요가 없다. 반면 힙은 OS에 의해 자동으로 관리되지 않으며, 메모리 공간도 가장 크고, 동적데이터를 보유하고 있기 때문에 시간이 지남에 따라 프로그램의 메모리가 바닥날 수도 있다. 또한 시간이 지남에 따라 파편화가 되면서 애플리케이션의 속도도 느려질 수 있다. 여기가 바로 가비지 컬렉터가 들어오는 곳이다.

힙의 포인터와 데이터를 구별하는 것은 가비지 컬렉션에서 중요한 부분이며, 이를 위해 V8은 `태그된 포인터`라는 접근 방식을 사용한다. 이 방식은 각 단어의 끝에 비트를 표시해두어 포인터인지 데이터인지를 구별한다. 이 접근 방식은 컴파일러지원이 필요하지만서도, 간단하면서도 효율적인 방식이다.

## 가비지 컬렉팅

프로그램이 자유롭게 사용할 수 있는 것보다 더 많은 메모리를 힙에 할당하려고 한다면, V8은 메모리 부족 오류를 발생시킨다. 또는 잘못 관리된 힙도 메모리 누수를 이르킬 수 있다.

V8은 가비지 컬렉팅을 활용하여 힙 메모리를 관리한다. 간단히 얘기하자면, 고립된 객체, 즉 더이상 스택에서 직/간접적으로 참조되지 않은 객체들은 메모리에서 해제하며 다른 객체 생성을 위한 메모리 공간을 확보하게 해준다.

V8의 가비지 컬렉터는 V8 프로세스에서 재사용하기 위하여, 사용 중이지 않은 메모리를 화수하는 역할을 한다. V8 가비지 컬렉터는 힙에 있는 객체를 수명별로 분리하여 각각 다른 단계에서 처리한다. 여기에는 두가지 다른 단계가 있고, 3가지 다른 알고리즘을 사용하여 V8에서 가비지 컬렉팅을 한다.

### Minor GC (Scavenger)

이 GC는 young/new space를 간결하고 깨끗하게 유지하는 역할을 한다. 상대적으로 작은 객체(1~8bm)는 `New Space`에 위치하게 된다. `New Space`에 있는 비용은 매우 저렴하다. 여기에는 새로운 객체를 위한 공간을 할당하고 싶을 때마다 등가시키는 할당 포인터가 있다. 할당 포인터가 `New Space`의 끝에 도달하면, 마이너 GC가 트리거 된다. 이 과정은 Scavenger 라고도 불리우며, [체니의 알고리즘](https://en.wikipedia.org/wiki/Cheney's_algorithm)으로 구현되어 있다. 이 과정은 굉장히 빈번하게 발생되며, 병렬로 스레드를 활용해 이루어지기 때문에 굉장히 빠르다.

마이너 GC의 처리과정을 살짝 보자.

앞서 말했듯, `New Space`는 두개의 같은 사이즈인 `semi-space`로 이루어져 있다. 하나는 `to-space`고 다른 하나는 `from-space`다. 대부분의 할당은 `from-space`에서 이루어진다. (`old space`에 할당되는 실행가능한 코드들은 여기에 저장되지 않는다) `from-space`가 가득차게 되면 마이너 GC 가 가동된다.

<script async class="speakerdeck-embed" data-id="5fff2548e55c4bb0a9c837c7eb598bee" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

1. 코드 시작단계에서 `from-space`에 이미 객체가 있다고 가정해보자. (01~06)
2. 프로세스가 새로운 객체인 07을 만들어 낸다.
3. V8은 `from-space`로 부터 메모리를 요청하지만, 더이상 객체를 할당할 메모리가 존재하지 않는다. 따라서 V8은 마이너 GC를 트리거 한다.
4. 마이너 GC는 스택 포인터 (GC 루트)에서 시작하여 `from-space`에서 객체 그래프를 재귀적으로 탐색하여, 사용되거나 살아있는 객체를 찾는다. 이러한 객체는 `to-space`로 이동한다. 이러한 객체가 참조하는 모든 객체도 마찬가지로 이동하게 되며, 이들의 포인터 또한 업데이트 된다. 이는 `from-space`내의 모든 객체를 모두 스캔할 때 까지 실행된다. 이 작업이 완료되면 `to-space`는 자동으로 파편화를 줄이기 위하여 압축된다.
5. 마이너 GC는 `from-space`에 남아 있는 객체들은 모두 가비지로 판단하여 비우게 된다.
6. 마이너 GC는 `to-space`와 `from-space`를 스왑한다. 따라서 모든 객체들은 `from-space`에 존재하며, `to-space`는 비어 있게 된다.
7. 새로운 객체는 `from-space`의 메모리에 할당된다.
8. 이제 `from-space`에 시간이 흘러서 객체가 더 들어 왔다고 가정해보자.
9. 애플리케이션이 새로운 객체를 만든다.
10. V8은 `from-space`로 부터 메모리를 요청하지만, 더이상 객체를 할당할 메모리가 존재하지 않는다. 따라서 V8은 마이너 GC를 트리거한다.
11. 위 작업이 반복되며, 두번째 마이너 GC로부터 살아남은 객체들은 `old-space`로 이동하게 된다. 첫번째 생존자들은 `to-space`로 이동하게 되고, `from-space`에는 가비지만 남아있고, 이를 비우게 된다.
12. 마이너 GC는 `to-space`와 `from-space`를 스왑하며, 모든 객체들은 `from-space`로 이동하고 `to-space` 는 비어지게 된다.
13. 새로운 객체가 `from-space`에 할당된다.

마이너 GC가 어떻게 `young generation`에 공간을 요청하고 이를 간결하게 유지하는지 살펴보았다. 이러한 일련의 과정은 프로세스를 중단시키지만, 너무 빠르고 효율적이기 때문에 대부분의 경우 무시할 수 있는 수준이다. 이 프로세스는 `nes space`의 참조를 위해 `old space`의 객체를 스캔하지 않기 때문에, 이전 space에서 새로운 메모리에 이르는 모든 포인터의 레지스터를 사용한다. 이는 [write barrier](https://www.memorymanagement.org/glossary/w.html#term-write-barrier)라고 불리는 과정에 의해 버퍼에 기록된다.

### Major GC

이 GC는 `old generation` 공간을 간결하고 깨끗하게 유지해준다. V8이 `old space`에 더이상 충분한 공간이 없다고 판단했을 때 시작된다.

스캐빈저 알고리즘은 작은 데이터 사이즈에는 매우 완벽하지만, `old space`와 같이 힙사이즈가 큰 경우에는 메모리 과부하를 일으킬 수 있어서 메이저 GC에는 `Mark-Sweep-Compact` 알고리즘을 사용한다. 이 알고리즘은 3색 표시 시스템(흰색, 회색, 검은색) 을 사용한다. 따라서 메이저 GC는 3단계 과정을 거치게 된다.

![Mark-Sweep-Compact](https://i.imgur.com/rcjSZ0T.gif)

- Marking: 첫번째 단계로, 두 알고리즘에 공통으로 사용된다. 가비지 컬렉터가 사용중인 객체와 사용하지 않는 객체를 식별하는 단계다. 사용 중이거나 GC 루트 (스택 포인터)에서 도달할 수 있는 객체는 활성 상태로 표시된다.
- Sweeping: 가비지 컬렉터는 힙을 탐색하고, 활성으로 표시되지 않은 객체의 메모리 주소를 기록한다. 이제 이 공간은 사용 가능한 공간으로 표시되며, 다른 객체를 저장하는데 사용할 수 있다.
- Compact: 청 소 필요한 경우 모든 살아남은 객체가 이동하게 된다. 이렇게 하게 되면 파편화가 줄어들고, 새로운 객체에 대한 메모리 할당 성능이 증가하게 된다.

이러한 유형의 GC는 GC를 수행하는 동안 프로세스의 일시중지를 야기 하기 때문에 `stop-the-world` GC라고도 한다. 이를 피하기 위해 V8은 아래와 같은 방법을 사용한다.

![Major GC](https://v8.dev/_img/trash-talk/09.svg)

- 증분 GC: GC는 하나가 아닌 여러 증분 단계로 수행된다.
- 동시 marking: 마킹은 메인 자바스크립트 스레드에 영향을 주지 않기 위해 여러 헬퍼 스레드를 사용하여 동시에 수행된다. `Writes Barrier`는 헬퍼가 마킹을 하는 동안 자바스크립트하 생성하는 객체 간에 새로운 참조를 추적하기 위하여 사용된다.
- 동시 Sweeping, compacting: 메인 자바스크립트 스레드에 영향을 주지 않기 위해 Sweeping과 Compacting은 헬퍼 쓰레드에서 동시에 이루어진다.
- 게으른 Sweeping: 게으른 Sweeping 은 메모리가 필요로 할 때까지 페이지에서 가비지 삭제를 지연 시키는 것을 포함한다.

Major GC의 프로세스를 살펴보자.

1. 많은 마이너 GC 사이클이 지나고 `old space`는 거의 가득차서 V8이 메이서 GC를 트리거 했다고 가정해보자.
2. 메이저 GC는 스택포인터에서 시작하여 객체 그래프를 재귀적으로 순회하며, `old space`에 있는 사용중인 객체와 가비지를 별개로 표시해둔다. 이 작업은 여러개의 동시 헬퍼 스레드를 사용하여 수행되며, 각 헬퍼는 포인터를 따른다. 이는 주 메인 쓰레드에 영향을 미치지 않는다.
3. 동시 marking이 끝나거나, 메모리가 제한에 도달하면 GC는 메인스레드를 사용하여 Marking 단계를 마무리한다. 이는 작은 일시정지 시간을 만든다.
4. 이제 메이저 GC는 동시 스윕 스레드를 사용하여, 모든 가비지 객체의 메모리를 사용가능한 것으로 표시해둔다. 또한 병렬 압축 작업이 트리거 되어, 파편화를 방지하기 위하여 관련 메모리 블록을 모두 동일한 페이지로 이동시킨다. 이 단계에서 포인터가 업데이트 된다.

출처: https://deepu.tech/memory-management-in-v8/

V8에서의 메모리 관리

<h2 id="v8-메모리-구조">V8 메모리 구조</h2>
<img src="https://i.imgur.com/kSgatSL.png" alt="V8 memory">
<h3 id="heap-memory">Heap Memory</h3>
이 영역이 V8이 객체나 다이나믹 데이터를 담아두는 영역이다. 여기는 메모리 영역 중에서 가장 큰 부분을 차지하며, 가비지 컬렉션이 발생하는 곳이다. 전체 힙메모리가 가비지 컬렉팅이 되는 것은 아니며, 오직 New Space와 Old Space만 가비지 컬렉팅의 대상이 된다.
<ul>
<li>New Space: New Space 또는 <code>Young generation</code>이라 불리는 곳이며, 새로운 객체 또는 단기간 유효한 객체들이 존재하는 곳이다. 이 영역은 상대적으로 작고, 두개의 별도 공간인 <code>Semi Space</code>가 존재한다. 이는 JVM의 <code>S0</code> <code>S1</code>과 비슷하다고 볼 수 있다. 이 공간은 <code>Scavenger</code>이른바 <code>Minor GC</code>에 의해서 관리된다. 이 사이즈의 영역은 <code>--mini_semi_space_size</code>와 <code>--max-_semi_space_size</code>로 조절할 수 있다.</li>
<li>Old Space: Old Space 또는 <code>Old generation</code>이라고 불리는 곳이며, <code>new space</code>에서 minor GC 사이클로부터 살아남은 객체들이 이동하는 곳이다. 이 영역은 <code>Major GC(Mark-Sweep &#x26; Mark-Compact)</code>에 의해서 관리된다. 이 공간의 사이즈는 <code>--initial_old_space_size</code>와 <code>--max_old_space_size</code>로 설정할 수 있다. 이 영역은 두개로 나눠진다.
<ul>
<li>Old Pointer Space: 다른 객체를 가르키는 객체가 보관 되는 곳</li>
<li>Old Data Space: 단순히 데이터만 가지고 있는 객체 (특정 객체를 가르키지 않음). Strings, boxed numbers, unboxed doubles의 배열이 <code>New Space</code>의 두번의 minor GC Cycle로 부터 살아남는다면 이쪽으로 이동하게 된다.</li>
</ul>
</li>
<li>Large object Space: 다른 Space에 있기에 너무 큰 객체들이 여기에 존재하게 된다. 각 객체들은 <a href="https://en.wikipedia.org/wiki/Mmap">mmap</a>을 갖게 된다. 큰 객체들은 절대 가비지 콜렉터에 의해 이동하지 않는다.</li>
<li>Code space: <code>Just In Time(JIT)</code> 컴파일러가 컴파일된 코드 블록을 보관하는 곳이다. 실행가능한 메모리가 존재할 수 있는 유일한 곳이다. (코드의 양이 커져서 <code>Large Object Space</code>로 가더라도, 여전히 실행 가능하다.)</li>
<li>Cell space, property cell space, map space: 이는 각각 <code>Cells</code> <code>PropertyCells</code> <code>Maps</code>를 가지고 있는다. 각각의 공간에는 모두 동일한 크기의 객체가 포함되어 있으며, 어떤 종류의 객체를 가리킬 수 있는지에 대한 제한이 있기 때문에 수집을 단순화 한다.</li>
</ul>
각각의 공간은 pages의 세트로 구성되어 있다. 여기서 페이지란, 운영체제 mmap에서 할당된 연속적인 메모리 청크를 의미한다. <code>Large Object Space</code>를 제외하고는, 각각 1MB이다.
<h3 id="stack">Stack</h3>
스택 메모리 영역으로, V8 프로세스 하나당 한개의 스택을 가지고 있다. 메서드/함수 프레임, 원시 값, 객체를 가르키는 포인터등 정적인 데이터를 보유하고 있는 곳이다. 이 스택 메모리의 크기는 <code>-stack_size</code>로 결정할 수 있다.
<h2 id="v8의-메모리-사용-stack-vs-heap">V8의 메모리 사용 (Stack vs Heap)</h2>
메모리가 어떤 구조로 되어 있는지 알아봤으니, 이제는 중요한 부분 인 프로그램이 실행될 때 각 부분이 어떻게 사용되는지를 알아보자. 아래 예제 코드를 살펴보자.
<pre class="language-javascript"><code class="language-javascript">class Employee {
 constructor(name, salary, sales) {
 this.name = name
 this.salary = salary
 this.sales = sales
 }
}

const BONUS_PERCENTAGE = 10

function getBonusPercentage(salary) {
 const percentage = (salary * BONUS_PERCENTAGE) / 100
 return percentage
}

function findEmployeeBonus(salary, noOfSales) {
 const bonusPercentage = getBonusPercentage(salary)
 const bonus = bonusPercentage * noOfSales
 return bonus
}

let john = new Employee('John', 5000, 5)
john.bonus = findEmployeeBonus(john.salary, john.sales)
console.log(john.bonus)
</code></pre>
<script async class="speakerdeck-embed" data-id="e89e2e48a797417eb8692897dcada584" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<ul>
<li><code>Global Scope</code>는 스택의 <code>Global Frame</code>내에 존재한다.</li>
<li>모든 함수 호출은 스택 메모리에 <code>frame-block</code> 형태로 추가된다.</li>
<li>모든 지역변수, arguments, 그리고 리턴 값은 위에서 언급한 함수 <code>frame-block</code> 내에 저장된다.</li>
<li>모든 원시값은 스택에 바로 저장된다. 이는 전역변수에 있어도 마찬가지다.</li>
<li>모든 객체는 힙에 생성되며, 스택에서 스택 포인터를 활용하여 참조된다. 함수는 자바스크립트에서 단순히 객체다. 이는 전역변수에서도 마찬가지다.</li>
<li>현재 함수에서 실행된 새로운 함수는 스택의 맨 위에 쌓인다.</li>
<li>함수가 프레임을 리턴하면 이는 스택에서 제거 된다.</li>
<li>메인 프로세스가 완료되면, 힙에 있는 객체는 스택에서 더이상 가리키는 포인터가 없으므로 고립되어 버린다.</li>
<li>따로 복제를 명시적으로 만들어두지 않는 이상, 다른 객체안에 있는 모든 객체 참조는 참조 포인터를 사용해서 완료된다.</li>
</ul>
보시다시피, 스택은 자동으로 관리되며, 이는 V8이 아닌 운영체재가 수행한다. 따라서 우리는 스택에 대해서 많은 신경을 쓸필요가 없다. 반면 힙은 OS에 의해 자동으로 관리되지 않으며, 메모리 공간도 가장 크고, 동적데이터를 보유하고 있기 때문에 시간이 지남에 따라 프로그램의 메모리가 바닥날 수도 있다. 또한 시간이 지남에 따라 파편화가 되면서 애플리케이션의 속도도 느려질 수 있다. 여기가 바로 가비지 컬렉터가 들어오는 곳이다.
힙의 포인터와 데이터를 구별하는 것은 가비지 컬렉션에서 중요한 부분이며, 이를 위해 V8은 <code>태그된 포인터</code>라는 접근 방식을 사용한다. 이 방식은 각 단어의 끝에 비트를 표시해두어 포인터인지 데이터인지를 구별한다. 이 접근 방식은 컴파일러지원이 필요하지만서도, 간단하면서도 효율적인 방식이다.
<h2 id="가비지-컬렉팅">가비지 컬렉팅</h2>
프로그램이 자유롭게 사용할 수 있는 것보다 더 많은 메모리를 힙에 할당하려고 한다면, V8은 메모리 부족 오류를 발생시킨다. 또는 잘못 관리된 힙도 메모리 누수를 이르킬 수 있다.
V8은 가비지 컬렉팅을 활용하여 힙 메모리를 관리한다. 간단히 얘기하자면, 고립된 객체, 즉 더이상 스택에서 직/간접적으로 참조되지 않은 객체들은 메모리에서 해제하며 다른 객체 생성을 위한 메모리 공간을 확보하게 해준다.
V8의 가비지 컬렉터는 V8 프로세스에서 재사용하기 위하여, 사용 중이지 않은 메모리를 화수하는 역할을 한다. V8 가비지 컬렉터는 힙에 있는 객체를 수명별로 분리하여 각각 다른 단계에서 처리한다. 여기에는 두가지 다른 단계가 있고, 3가지 다른 알고리즘을 사용하여 V8에서 가비지 컬렉팅을 한다.
<h3 id="minor-gc-scavenger">Minor GC (Scavenger)</h3>
이 GC는 young/new space를 간결하고 깨끗하게 유지하는 역할을 한다. 상대적으로 작은 객체(1~8bm)는 <code>New Space</code>에 위치하게 된다. <code>New Space</code>에 있는 비용은 매우 저렴하다. 여기에는 새로운 객체를 위한 공간을 할당하고 싶을 때마다 등가시키는 할당 포인터가 있다. 할당 포인터가 <code>New Space</code>의 끝에 도달하면, 마이너 GC가 트리거 된다. 이 과정은 Scavenger 라고도 불리우며, <a href="https://en.wikipedia.org/wiki/Cheney&#x27;s_algorithm">체니의 알고리즘</a>으로 구현되어 있다. 이 과정은 굉장히 빈번하게 발생되며, 병렬로 스레드를 활용해 이루어지기 때문에 굉장히 빠르다.
마이너 GC의 처리과정을 살짝 보자.
앞서 말했듯, <code>New Space</code>는 두개의 같은 사이즈인 <code>semi-space</code>로 이루어져 있다. 하나는 <code>to-space</code>고 다른 하나는 <code>from-space</code>다. 대부분의 할당은 <code>from-space</code>에서 이루어진다. (<code>old space</code>에 할당되는 실행가능한 코드들은 여기에 저장되지 않는다) <code>from-space</code>가 가득차게 되면 마이너 GC 가 가동된다.
<script async class="speakerdeck-embed" data-id="5fff2548e55c4bb0a9c837c7eb598bee" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
<ol>
<li>코드 시작단계에서 <code>from-space</code>에 이미 객체가 있다고 가정해보자. (01~06)</li>
<li>프로세스가 새로운 객체인 07을 만들어 낸다.</li>
<li>V8은 <code>from-space</code>로 부터 메모리를 요청하지만, 더이상 객체를 할당할 메모리가 존재하지 않는다. 따라서 V8은 마이너 GC를 트리거 한다.</li>
<li>마이너 GC는 스택 포인터 (GC 루트)에서 시작하여 <code>from-space</code>에서 객체 그래프를 재귀적으로 탐색하여, 사용되거나 살아있는 객체를 찾는다. 이러한 객체는 <code>to-space</code>로 이동한다. 이러한 객체가 참조하는 모든 객체도 마찬가지로 이동하게 되며, 이들의 포인터 또한 업데이트 된다. 이는 <code>from-space</code>내의 모든 객체를 모두 스캔할 때 까지 실행된다. 이 작업이 완료되면 <code>to-space</code>는 자동으로 파편화를 줄이기 위하여 압축된다.</li>
<li>마이너 GC는 <code>from-space</code>에 남아 있는 객체들은 모두 가비지로 판단하여 비우게 된다.</li>
<li>마이너 GC는 <code>to-space</code>와 <code>from-space</code>를 스왑한다. 따라서 모든 객체들은 <code>from-space</code>에 존재하며, <code>to-space</code>는 비어 있게 된다.</li>
<li>새로운 객체는 <code>from-space</code>의 메모리에 할당된다.</li>
<li>이제 <code>from-space</code>에 시간이 흘러서 객체가 더 들어 왔다고 가정해보자.</li>
<li>애플리케이션이 새로운 객체를 만든다.</li>
<li>V8은 <code>from-space</code>로 부터 메모리를 요청하지만, 더이상 객체를 할당할 메모리가 존재하지 않는다. 따라서 V8은 마이너 GC를 트리거한다.</li>
<li>위 작업이 반복되며, 두번째 마이너 GC로부터 살아남은 객체들은 <code>old-space</code>로 이동하게 된다. 첫번째 생존자들은 <code>to-space</code>로 이동하게 되고, <code>from-space</code>에는 가비지만 남아있고, 이를 비우게 된다.</li>
<li>마이너 GC는 <code>to-space</code>와 <code>from-space</code>를 스왑하며, 모든 객체들은 <code>from-space</code>로 이동하고 <code>to-space</code> 는 비어지게 된다.</li>
<li>새로운 객체가 <code>from-space</code>에 할당된다.</li>
</ol>
마이너 GC가 어떻게 <code>young generation</code>에 공간을 요청하고 이를 간결하게 유지하는지 살펴보았다. 이러한 일련의 과정은 프로세스를 중단시키지만, 너무 빠르고 효율적이기 때문에 대부분의 경우 무시할 수 있는 수준이다. 이 프로세스는 <code>nes space</code>의 참조를 위해 <code>old space</code>의 객체를 스캔하지 않기 때문에, 이전 space에서 새로운 메모리에 이르는 모든 포인터의 레지스터를 사용한다. 이는 <a href="https://www.memorymanagement.org/glossary/w.html#term-write-barrier">write barrier</a>라고 불리는 과정에 의해 버퍼에 기록된다.
<h3 id="major-gc">Major GC</h3>
이 GC는 <code>old generation</code> 공간을 간결하고 깨끗하게 유지해준다. V8이 <code>old space</code>에 더이상 충분한 공간이 없다고 판단했을 때 시작된다.
스캐빈저 알고리즘은 작은 데이터 사이즈에는 매우 완벽하지만, <code>old space</code>와 같이 힙사이즈가 큰 경우에는 메모리 과부하를 일으킬 수 있어서 메이저 GC에는 <code>Mark-Sweep-Compact</code> 알고리즘을 사용한다. 이 알고리즘은 3색 표시 시스템(흰색, 회색, 검은색) 을 사용한다. 따라서 메이저 GC는 3단계 과정을 거치게 된다.
<img src="https://i.imgur.com/rcjSZ0T.gif" alt="Mark-Sweep-Compact">
<ul>
<li>Marking: 첫번째 단계로, 두 알고리즘에 공통으로 사용된다. 가비지 컬렉터가 사용중인 객체와 사용하지 않는 객체를 식별하는 단계다. 사용 중이거나 GC 루트 (스택 포인터)에서 도달할 수 있는 객체는 활성 상태로 표시된다.</li>
<li>Sweeping: 가비지 컬렉터는 힙을 탐색하고, 활성으로 표시되지 않은 객체의 메모리 주소를 기록한다. 이제 이 공간은 사용 가능한 공간으로 표시되며, 다른 객체를 저장하는데 사용할 수 있다.</li>
<li>Compact: 청 소 필요한 경우 모든 살아남은 객체가 이동하게 된다. 이렇게 하게 되면 파편화가 줄어들고, 새로운 객체에 대한 메모리 할당 성능이 증가하게 된다.</li>
</ul>
이러한 유형의 GC는 GC를 수행하는 동안 프로세스의 일시중지를 야기 하기 때문에 <code>stop-the-world</code> GC라고도 한다. 이를 피하기 위해 V8은 아래와 같은 방법을 사용한다.
<img src="https://v8.dev/_img/trash-talk/09.svg" alt="Major GC">
<ul>
<li>증분 GC: GC는 하나가 아닌 여러 증분 단계로 수행된다.</li>
<li>동시 marking: 마킹은 메인 자바스크립트 스레드에 영향을 주지 않기 위해 여러 헬퍼 스레드를 사용하여 동시에 수행된다. <code>Writes Barrier</code>는 헬퍼가 마킹을 하는 동안 자바스크립트하 생성하는 객체 간에 새로운 참조를 추적하기 위하여 사용된다.</li>
<li>동시 Sweeping, compacting: 메인 자바스크립트 스레드에 영향을 주지 않기 위해 Sweeping과 Compacting은 헬퍼 쓰레드에서 동시에 이루어진다.</li>
<li>게으른 Sweeping: 게으른 Sweeping 은 메모리가 필요로 할 때까지 페이지에서 가비지 삭제를 지연 시키는 것을 포함한다.</li>
</ul>
Major GC의 프로세스를 살펴보자.
<ol>
<li>많은 마이너 GC 사이클이 지나고 <code>old space</code>는 거의 가득차서 V8이 메이서 GC를 트리거 했다고 가정해보자.</li>
<li>메이저 GC는 스택포인터에서 시작하여 객체 그래프를 재귀적으로 순회하며, <code>old space</code>에 있는 사용중인 객체와 가비지를 별개로 표시해둔다. 이 작업은 여러개의 동시 헬퍼 스레드를 사용하여 수행되며, 각 헬퍼는 포인터를 따른다. 이는 주 메인 쓰레드에 영향을 미치지 않는다.</li>
<li>동시 marking이 끝나거나, 메모리가 제한에 도달하면 GC는 메인스레드를 사용하여 Marking 단계를 마무리한다. 이는 작은 일시정지 시간을 만든다.</li>
<li>이제 메이저 GC는 동시 스윕 스레드를 사용하여, 모든 가비지 객체의 메모리를 사용가능한 것으로 표시해둔다. 또한 병렬 압축 작업이 트리거 되어, 파편화를 방지하기 위하여 관련 메모리 블록을 모두 동일한 페이지로 이동시킨다. 이 단계에서 포인터가 업데이트 된다.</li>
</ol>
출처: <a href="https://deepu.tech/memory-management-in-v8/">https://deepu.tech/memory-management-in-v8/</a>

## Server Side Events

일반적이고 전통적인 웹페이지의 경우, 새로운 데이터를 받기 위해서는 서버에 데이터 요청을 해야만 한다. 이른바 폴링이라는 기술로, 웹페이지가 서버에 요청을 해야만, 서버가 그 요청에 따른 데이터를 적절하게 리턴해주는 방식이라고 볼 수 있다. 하지만 Server Side Events, 이하 (SSE)를 활용하면, 웹페이지가 별도로 요청하지 않아도 서버가 데이터를 보내는 것이 가능하다. 즉, 서버에서 클라이언트로 업데이트 되는 내용을 스트리밍을 하는 것이 가능해진다. SSE를 활용하면, 서버와 클라이언트 사이에 단방향 채널을 여는 것과 같은 이점을 얻르 수 있다.

## vs Web Socket?

그렇다면 우리가 일반적으로 알고 있는 web socket 과의 차이는 무엇일까? 웹 소켓은 양반향 통신을 위한 프로토콜은 제공하지만 (채팅과 같은), 일부 시나리오에서는 그러한 양방향 통신이 필요하지 않을 때가 있다. 클라이언트에서 굳이 데이터를 전송하지 않고, 서버의 데이터만 클라이언트에 보내서 업데이트를 해야하는 경우가 있다. (긴 시간이 걸리는 요청에 대해서 요청을 일부분씩 나눠서 보내는 등) 이러한 경우에는 Web Socket보다는 SSE가 훨씬 더 좋은 대안이 될 수 있다. 또한 웹 소켓과는 다르게, 전통적인 HTTP로도 전송이 가능하다. 즉, 특별한 프로토콜이나 서버구현이 필요하지 않다.

## How to use

### Support

대다수의 모던 브라우저가 지원하는 반면, 아쉽게도 역시나 우리의 IE는 SSE를 지원하지 않는다.

https://caniuse.com/eventsource

폴리필을 사용하면 될 것 같다. (써보진 않았지만) https://github.com/Yaffle/EventSource

### Javascript API

이벤트 스트림을 구독하기 위해서는, EventSource를 만들고 URL을 넘겨야 한다.

```javascript
if (!!window.EventSource) {
 var source = new EventSource('stream.php')
} else {
 // SSE를 사용할 수 없는 환경
}
```

만약 URL이 절대 주소로 되어 있다면, 호출 페이지와 scheme, domain, port 등이 일치해야 한다.

이제 소스에 이벤트 핸들러를 달아서 실제로 구독을 해보자.

```javascript
source.addEventListener(
 'message',
 function (e) {
 console.log(e.data)
 },
 false,
)

source.addEventListener(
 'open',
 function (e) {
 // 연결성공
 },
 false,
)

source.addEventListener(
 'error',
 function (e) {
 if (source.readyState == EventSource.CLOSED) {
 // 연결이 닫히는 경우
 }
 },
 false,
)
```

서버에서 데이터를 푸쉬하면, `message`가 실행되고, `e.data`에서 데이터를 가져올 수 있다.

소스의 이벤트 스트림은 SSE 형식인 `Content-type` `text/event-stream`을 사용하여 텍스트 응답을 작성해야 한다. 기본적인 응답형식은 아래와 같다.

```bash
data: response \n\n
```

`data:`행 다음에 메시지가 오고, 스트림 맨 마지막에는 `\n` 문자가 두개 있다면 스트림이 끝난 것으로 간주한다.

메시지가 길어서 여러줄을 보내야 한다면, `data:`행을 사용하여 메시지를 분할하면 된다.

```bash
data: first response\n
data: second response\n\n
```

`\n`으로 하나만 줄바꿈이 되어 있다면, `message`이벤트는 하나만 발생한다.

JSON 데이터를 보내야 한다면 어떻게 할까?

```bash
data: {\n
data: "msg": "hello world",\n
data: "id": 12345\n
data: }\n\n
```

```javascript
source.addEventListener(
 'message',
 function (e) {
 var data = JSON.parse(e.data)
 console.log(data.id, data.msg)
 },
 false,
)
```

물론 json 데이터를 압축해서 한줄로 보내도 가능할 것이다.

이벤트에 ID를 달아서 고유한 ID도 함께 보낼 수 있다.

```bash
id: 123\n
data: hello\n
data: world\n
```

ID를 설정하게 되면, 브라우저는 마지막에 발생한 이벤트를 추적할 수 있게 된다. 이는 만약 연결이 끊겼을 때, `Last-Event-ID`라고 불리는 특별한 HTTP 헤더가 새 요청으로 설정된다. 이는 브라우저가 어떤 이벤트를 발생하기에 적합한지 판단할 수 있게 해준다. 이 메시지 이벤트네는 `e.lastEventId` 속성이 포함되어 있다.

브라우저는 각 연결이 종료 된 후에 3초후에 다시 연결을 시도하려고 한다. 여기에 `retry:`를 시간과 함께 설정하여, 이 시간제한을 변경할 수 있다.

```bash
retry: 10000\n
data: hello world\n\n
```

이렇게 하게 되면 10초 후에 다시 연결을 시도하게 된다.

하나의 이벤트 소스에 이벤트 이름을 넣어두면, 여러가지 이벤트를 생성할 수 있다. `event:`로 시작하는 행에 이벤트 명을 명시하는 경우, 그 이벤트를 해당 이름에 바인딩 시킬 수 있다. 클라이언트에서는 이벤트 리스너를 설정하여 해당 이벤트를 구독할 수 있다.

```bash
data: {"msg": "First message"}\n\n
event: userlogon\n
data: {"username": "John123"}\n\n
event: update\n
data: {"username": "John123", "emotion": "happy"}\n\n
```

```javascript
source.addEventListener(
 'message',
 function (e) {
 var data = JSON.parse(e.data)
 console.log(data.msg)
 },
 false,
)

source.addEventListener(
 'userlogon',
 function (e) {
 var data = JSON.parse(e.data)
 console.log('User login:' + data.username)
 },
 false,
)

source.addEventListener(
 'update',
 function (e) {
 var data = JSON.parse(e.data)
 console.log(data.username + ' is now ' + data.emotion)
 },
 false,
)
```

## 예제

```javascript
const koa = require('koa')
const Router = require('koa-router')

const router = new Router()

router.get('/event', async (ctx) => {
 ctx.res.writeHead(200, {
 'Content-Type': 'text/event-stream',
 'Cache-Control': 'no-store',
 'Access-Control-Allow-Origin': '*',
 })

 const lastEventId =
 Number(ctx.request.headers['last-event-id']) || Number(ctx.query.id) || 100
 let timeoutId = 0
 let i = lastEventId
 let c = i + 100

 let f = function () {
 if (++i < c) {
 ctx.res.write(`id: ${i} \n`)
 ctx.res.write(`data: ${i} \n\n`)
 timeoutId = setTimeout(f, 1000)
 } else {
 ctx.res.end()
 }
 }

 f()

 ctx.res.on('close', function () {
 clearTimeout(timeoutId)
 })
})

router.get('/', async (ctx) => {
 ctx.res.write(`<!DOCTYPE html>
 <html>
 <head>
 <meta charset="utf-8" />
 <title>EventSource example</title>
 <meta http-equiv="X-UA-Compatible" content="IE=edge">
 <script>
 var es = new EventSource("/event?id=50"); 
 
 es.addEventListener('message', function(e) {
 var div = document.createElement("div"); 
 div.appendChild(document.createTextNode('>>' + e.data));
 document.body.appendChild(div);
 }, false);
 
 es.addEventListener('open', function(e) { 
 var div = document.createElement("div"); 
 div.appendChild(document.createTextNode("SSE connected!"));
 document.body.appendChild(div);
 }, false);
 
 es.addEventListener('error', function(e) {
 console.log('failed')
 }, false);
 </script>
 </head>
 <body>
 </body>
 </html>`)
})

async function main() {
 const app = new koa()

 app.use(router.routes()).use(router.allowedMethods())

 app.listen(3001)
}

try {
 main()
} catch (err) {
 console.error(err)
}
```

결과

```bash
SSE connected!
>>51
SSE connected!
>>52
SSE connected!
>>53
SSE connected!
>>54
SSE connected!
>>55
SSE connected!
>>56
SSE connected!
>>57
SSE connected!
>>58
SSE connected!
>>59
SSE connected!
>>60
SSE connected!
>>61
SSE connected!
>>62
SSE connected!
>>63
SSE connected!
>>64
SSE connected!
>>65
SSE connected!
>>66
SSE connected!
>>67
SSE connected!
>>68
SSE connected!
...
```

이거 꼭 한번 해보고 싶었는데 😭

서버 사이드 이벤트 (Server Side Events, SSE)

`Redux`, `MobX`등은 이제 리액트 프로젝트를 만든다면 필수로 같이 쓰게 되는 상태 관리 라이브러리 들 중 하나가 된 것 같다. 상태 관리 라이브러리의 필요성은 알지만 서도, 무분별하게 상태 관리 라이브러리를 설치해서 무조건 쓰는 것에 대해 나 또한 그다지 긍정적이지는 않다.

- https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367
- https://dev.to/g_abud/why-i-quit-redux-1knl
- https://hackernoon.com/goodbye-redux-26e6a27b3a0b

개인적으로는 리액트에서 제공하는 `useState` `useContext` 등으로 충분하다고 생각하지만서도, 이미 대세가 되어버린 상태관리 라이브러리의 시대에 나 또한 흐름을 따라 갈 수 밖에 없다.

이 와중에 React에서 만든 `Recoil`이라고 하는 상태 관리 라이브러리가 나왔다. 과연 이 라이브러리가 다른 상태관리 라이브러리랑은 무엇이 다른지, 또 정말 쓸 만한지 고민해보자.

앞서서 리액트의 `Context`만으로 충분할 것 같다고 말한 것과는 다르게, 리액트에서는 `Context`의 한계에 대해서 명백히 인식하고 있는 것 같다.

> My personal summary is that new context is ready to be used for low frequency unlikely updates (like locale/theme). It's also good to use it in the same way as old context was used. I.e. for static values and then propagate updates through subscriptions. It's not ready to be used as a replacement for all Flux-like state propagation.

https://github.com/facebook/react/issues/14110#issuecomment-448074060

그리고 실제로 React의 Context API를 쓰던 Redux가 성능상의 문제로 인해 이를 철회한 사건도 있었다.

> In v6, we switched from individual components subscribing to the store, to having <Provider> subscribe and components read the store state from React's Context API. This worked, but unfortunately the Context API isn't as optimized for frequent updates as we'd hoped, and our usage patterns led to some folks reporting performance issues in some scenarios.

https://github.com/reduxjs/react-redux/releases/tag/v7.0.1

또한 Provider의 값이 배열이나 객체 인 경우, 여기에서 구조가 조금이라도 바뀌게 된다면 `Context`를 구독하고 있는 하위 모든 컴포넌트가 다시 렌더링되는 참사가 발생된다.

React Context API는 분명 나쁜 API는 아니지만, 그 한계가 어느정도 있다는 것을 알 수 있다. 그렇기 때문에 Facebook 팀에서도 그 한계를 인지하고 Recoil 을 만든게 아닐 까 싶다.

> For reasons of compatibility and simplicity, it's best to use React's built-in state management capabilities rather than external global state. But React has certain limitations:

> - Component state can only be shared by pushing it up to the common ancestor, but this might include a huge tree that then needs to re-render.
> - Context can only store a single value, not an indefinite set of values each with its own consumers.
> - Both of these make it difficult to code-split the top of the tree (where the state has to live) from the leaves of the tree (where the state is used).

## Recoil

### RecoilRoot

`recoil` 의 state를 사용하기 위해서는 부모 트리에 `RecoilRoot`를 선언해야 한다. 가장 좋은 위치는 바로 Root다.

```javascript
import React from 'react'
import { RecoilRoot, atom } from 'recoil'

function App() {
 return (
 <RecoilRoot>
 <Component />
 </RecoilRoot>
 )
}
```

### Atom

`atom`은 state의 조각을 의미한다. `atom`은 어떤 컴포넌트에서든 읽기/쓰기가 가능하다. 컴포넌트는 이 `atom`의 값을 구독하여 읽을 수 있으며, `atom`의 업데이트는 곳 이를 구독하고 있는 모든 컴포넌트의 업데이트를 야기한다.

```javascript
const textState = atom({
 key: 'textState', // unique ID
 default: '', // 기본값
})
```

### useRecoilState

이름에서 느껴지듯이, `useState`와 비슷하게 값과 이를 조작할 수 있는 `setter` 함수를 리턴한다.

```javascript
const [text, setText] = useRecoilState(textState)
```

### useRecoilValue

`useRecoilState`와는 다르게, 오로지 `atom`의 값만 가져올 수 있다.

```javascript
const text = useRecoilValue(textState)
```

### useSetRecoilState

`atom`의 `setter` 만 가져올 수 있다.

```javascript
const setText = useSetRecoilState(textState)
```

### selector

`atom`과 함께 중요한 개념 중 하나다. `Selector`는 상태에서 파생된 데이터다. `get`을 활용하여 `atom`으로 부터 파생된 데이터를 가져올 수 있으며, `set`을 활용하여 하나이상의 atom을 업데이트 할 수 있다.

```typescript
function selector<T>({
 key: string,

 get: ({
 get: GetRecoilValue
 }) => T | Promise<T> | RecoilValue<T>,

 set?: (
 {
 get: GetRecoilValue,
 set: SetRecoilState,
 reset: ResetRecoilState,
 },
 newValue: T | DefaultValue,
 ) => void,

 dangerouslyAllowMutability?: boolean,
})
```

- `key`: 유니크 아이디로, 애플리케이션 전체에서 다른 `selector`나 `atom`과 중복되서는 안된다.
- `get`: 상태로 부터 연산할 수 있는 값이다. 단순히 값이나 `Promise`로 부터 야기되는 비동기 값을 가져올 수 있으며, 또한 같은 타입을 갖는 `atom`이나 `selector` 를 리턴할 수도 있다.
 - get: 다른 `atom` `selector`에서 값을 가져오기 위해 제공되는 함수다. 이 `get`을 거치는 모든 `atom`과 `selector`는 의존성을 가진 것으로 간주된다. 따라서 이 `get`에서 쓰이는 값이 변하게 되면, 이 selector 또한 변하게 된다.
- `set?`: 만약 이 `set`이 설정되면, `selector` 는 쓰기 가능한 `state`를 리턴하게 된다.
 - `get`: 위와 마찬가지로 다른 `atom` `selector`에서 값을 가져오기 위해 제공되는 함수다.
 - `set`: `recoil`의 state 값을 쓰기 위해 제공 되는 함수다. 첫번째 파라미트로는 `Recoil`의 state를, 두번째 파라미터로는 새로운 값을 넘겨주면 된다.
- `dangerouslyAllowMutability`: `selector`는 파생된 상태로 부터의 순수함수 이기 때문에, 의존성의 같은 input이 제공되면 항상 같은 값을 리턴해야 한다. 이 옵션을 오버라이드 하고 싶을 때 쓴다.

예제를 살펴보자.

```javascript
import { atom, selector, useRecoilState, DefaultValue } from 'recoil'

// 화씨 온도를 저장해 두는 atom
const tempFahrenheit = atom({
 key: 'tempFahrenheit',
 default: 32,
})

// 섭씨 온도는 화씨로 부터 파생된다.
const tempCelsius = selector({
 key: 'tempCelsius',
 // 현재 화씨 값을 기준으로 연산하여 화씨 값을 가져온다.
 get: ({ get }) => ((get(tempFahrenheit) - 32) * 5) / 9,
 // 섭씨 값을 설정하면, 화씨 값을 set 한다.
 set: ({ set }, newValue) =>
 set(
 tempFahrenheit,
 newValue instanceof DefaultValue ? newValue : (newValue * 9) / 5 + 32,
 ),
})

function TempCelsius() {
 // selector와 atom 모두 useRecoilState를 활용하여 값을 설정하고 가져오는 것을 알 수 있다.
 const [tempF, setTempF] = useRecoilState(tempFahrenheit)
 const [tempC, setTempC] = useRecoilState(tempCelsius)
 const resetTemp = useResetRecoilState(tempCelsius)

 const addTenCelsius = () => setTempC(tempC + 10)
 const addTenFahrenheit = () => setTempF(tempF + 10)
 const reset = () => resetTemp()

 return (
 <div>
 Temp (Celsius): {tempC}
 
 Temp (Fahrenheit): {tempF}
 
 <button onClick={addTenCelsius}>Add 10 Celsius</button>
 
 <button onClick={addTenFahrenheit}>Add 10 Fahrenheit</button>
 
 <button onClick={reset}>>Reset</button>
 </div>
 )
}
```

## 느낌

- 일단 API가 굉장히 단순하고, hook을 사용하고 있기 때문에 리액트의 hook 생태계에 익숙한 사람들에게 낮은 러닝 커브로 다가올 것 같은 생각이 든다. 또 현재 `state`로 되어 있는 리액트 프로젝트를 굉장히 빠르게 마이그레이션 할 수 있을 것 같다. `<RecoilRoot/>`로 루트 프로젝트를 감싸고, `useState`를 `useRecoilState`로 바꾸면 일단은 된다.
- 컴포넌트가 사용하는 데이터만 별개로 사용할 수 있어서 좋았다.
- `selector` 라는 이름이 주는 혼란함이 있었다. `selector` 인데 `set`이 왜 됨???
- [리액트 동시성 모드가 사용가능해지면 이를 지원할 수도 있다는 언급이 있었다.](https://recoiljs.org/docs/introduction/motivation/) 왜냐하면 [Recoil은 내부적으로 React의 상태를 사용하고 있으며](https://github.com/facebookexperimental/Recoil/blob/55059f54ad1d09bfac8d086316bb18bed9cc2879/src/hooks/Recoil_Hooks.js#L20) 이는 곧 [React에서 내놓을 동시성 모드](https://ko.reactjs.org/docs/concurrent-mode-intro.html)를 지원할 수도 있다는 가능성이 존재한다고 볼 수 있기 때문이다. (실제로 motivation에서 그렇게 이야기 하기도 했고) 사용이 간편하다, Facebook이 만들었다는 것 외에 다른 상태 관리 라이브러리와 다른 가장 큰 차별점 & 그리고 도입을 해야하는 이유가 있다면 바로 이것 때문이 아닐 까 싶다. (물론 아직은 멀었지만)
 > We have the possibility of compatibility with Concurrent Mode and other new React features as they become available.

## 더 알아보기

- https://www.youtube.com/watch?v=_ISAA_Jt9kI&ab_channel=ReactEurope
- https://ui.toast.com/weekly-pick/ko_20200616

yceffort

자바스크립트 의존성 지옥

Nodejs 성능 최적화를 위한 방법

V8에서의 메모리 관리

서버 사이드 이벤트 (Server Side Events, SSE)

React를 위한 상태관리 라이브러리, Recoil