## Table of Contents

## 시작하며

자바스크립트 커뮤니티에서 요즘 가장 중요하게 생각하는 것중 하나는 번들 사이즈 인것 같다. 얼마나 많은 의존성을 가지고 있는가? 번들 사이즈를 더 작게 만들수는 없나? 레이지 로드를 잘 활용하고 있나? 사람들이 번들 사이즈에 대해 집착하는 이유 중 하나는 아무래도 눈에 잘 띈다는 점 때문일 거다. 물론, 번들 사이즈가 중요하지 않다는 것은 아니다. 하지만 번들 사이즈 외에도 중요한 것은 많이 있다.

- 파싱/컴파일에 걸리는 시간
- 실행 시간
- 파워 사용량
- 메모리 사용량
- 디스크 사용량

자바스크립트의 의존성은 위 모든 지표에 영향을 미친다. 위 지표는 그러나 번들 사이즈에 비해서는 덜 논의되는 편이다. 아무래도 번들사이즈에 비해 측정하기가 어렵기 때문일 것이다.

## 번들 사이즈

자바스크립트 코드의 크기를 논의 할 때, 우리는 명확히 할 필요가 있다. minified는 한 크기인가? gzip도? 트리쉐이킹은 했나? gzip 세팅은 제일 크게 했는가? 혹시 [브로틀리](https://yceffort.kr/2021/01/brotli-better-html-compression)를 사용했는가?

사소한걸 피곤하게 따지는 것 같지만, 사실 크기를 논의 할 때, 특히 압축과 비압축사이에서는 굉장히 중요하다. 압축된 크기는 사용자 브라우저에 얼마나 빠르게 전달되는지에 영향을 미칠 것이고, 비압축된 사이즈는 사용자의 브라우저에서 얼마나 빠르게 파싱되고, 컴파일되고, 실행되는지에 영향을 미칠 것이다. 

### Bundlephobia

자바스크립트 라이브러리 크기를 분석하는데 있어서 유용한 툴은 바로 [Bundlephobia](https://bundlephobia.com/)다. 라이브러리의 의존성을 볼 수도 있고, minified된 사이즈와 압축된 사이즈까지 볼수도 있고 다운로드에 걸리는 시간도 볼 수 있다.

![bundlephobia](./images/bundlephobia.png)

그러나 bundlephobia를 보는데 있어서 주의를 해야할 것이 있다.

- 여기에는 트리쉐이킹이 반영되있지 않다는 것이다. 라이브러리에서 특정 모듈만을 사용한다면, 다른 모듈들은 트리쉐이킹되어 줄어들 것이다. 
- 또한 서브 디렉토리의 의존성에 대해서는 알수가 없다. 예를 들어 `preact`를 가져오는데 한 비용은 알수가 있다. 그러나 `preact/compat`에 대해서는 알 방법이 없다. `compat.js`가 정말 큰 파일이라도 그것을 알 방법이 없다.
- 만약 폴리필이 포함되는 경우 (`Object.assign()`나 `Buffer API`등 번들러가 주입하는 경우) 여기서 반드시 표시되지 않는다. 

위의 요소들을 점검하기 위해서는, 번들러를 실행해서 결과물을 확인해보면 된다. 번들러는 서로 다 다르며, 설정과 여러가지 요소에 따라서 크기가 달라질 수 있다. 

### Webpack Bundle Analyzer

[Webpack Bundle Analyzer](https://github.com/webpack-contrib/webpack-bundle-analyzer)는 웹팩 결과물로 나온 모든 청크들을 잘 보여주고, 어떤 모듈이 청크들을 구성하는지 확인할 수 있다.

![Webpack Bundle Analyzer](https://cloud.githubusercontent.com/assets/302213/20628702/93f72404-b338-11e6-92d4-9a365550a701.gif)

여기서 중요한 것은 `Parsed`와 `Gzipped`다. Bundlephobia와는 다르게 실제로 번들러를 거쳤을 때 의 크기를 볼 수가 있다.

### Rollup Plugin Analyzer

[Rollup Plugin Analyzer](https://github.com/doesdev/rollup-plugin-analyzer)는 번들의 크기를 빌드하는 과정에서 콘솔로도 볼 수 있다. 그러나, minified나 gzipped한 크기는 볼수가 없다. 

그 외에도 아래와 같은 도구가 있다.

- [bundlesize](https://github.com/siddharthkp/bundlesize)
- [Bundle Buddy](https://www.npmjs.com/package/bundle-buddy)
- [Sourcemap Explorer](https://github.com/danvk/source-map-explorer)
- [Webpack Analyse](https://github.com/webpack/analyse)

## 번들 크기 말고 다른 것

앞에서도 언급했듯이, 번들사이즈가 전부는 아니다. 이 외에도 살펴볼 만한 다양한 것들이 많다.

### Runtime CPU Cost

첫번째 이자 가장 중요한 것중 하나는 런타임 시의 비용이다. 이는 여러가지 요소로 나눠서 생각해 볼 수 있다.

- Parsing
- Compilation
- Execution

이 세가지 요소는 기본적으로 엔드 투 엔드 비용으로, `require('something')` 이나 `import 'something'`를 호출 할 때 발생한다. 번들사이즈와도 연관이 있지만, 반드시 일치하는 것은 아니다. 

```javascript
const start = Date.now()
while (Date.now() - start < 5000) {}
```

위의 이상한 코드를 살펴보자. Bunldephobia에서는 위 코드가 높은 점수를 받겠지만 (코드의 크기가 작기 때문에) 메인스레드를 무려 5초나 잡아먹는다. 위의 예제 처럼, 작은 라이브러리가 메인스레드에 악영향을 미치는 경우가 더러있다. DOM의 모든 요소를 순회하거나, 로컬 스토리지에 큰 배열을 포문을 돌거나 하는 등. 직접 모든 의존성을 하나하나 살펴 보지 않는 한, 내부에서 무엇을 하는지 알 수 없다.

Parsing과 Compilation은 모두 측정하기 어려운 항목이다. 브라우저는 바이트 코드 캐싱에 대한 최적화 기능을 가지고 있기 때문에 이 것들을 알기가 쉽지 않다. 예를 들어, 브라우저가 두세번째 페이지 로딩 부터는 파싱과 컴파일 단계를 거치지 않는다. 또는 자바스크립트가 서비스워커에서 캐싱을 했을 수도 있다. 따라서 실제로 브라우저가 미리 모듈을 캐시한다면, 모듈을 파싱하고 컴파일하는데 비용이 적게 든다고 생각할 수 있다. 

따라서 100% 제대로 확인할 수 있는 방법은, 브라우저 캐시를 완전히 지우고 첫 페이지를 로딩하는 것이다. 일반적으로 이러한 작업은 private 모드나 주로 사용하지 않는 브라우저에서 이 작업을 수행한다. 또한 브라우저 확장 기능을 꺼둬야 한다. 

또한 크롬의 기능을 활용하여 CPU 쓰로틀링을 4x 또는 6x를 설정해두는 것도 좋은 방법이다. 이는 하이엔드 개발자의 컴퓨터 보다 훨씬 더 실제 사용자를 더 잘 대표할 수 있다.

네트워크 속도의 경우, 네트워크 속도 조절 기능을 사용할 수 있다. (3G)

이를 모두 요약하자면, 다음과 같은 단계를 거친다.

1. 사생활 보호 모드로 브라우저를 킨다
2. `about:blank` 로 진입한다. (브라우저 홈 화면의 `unload` 이벤트를 측정하지 않기 위해)
3. 크롬의 DevTool을 연다
4. Performance Tab을 연다
5. Cpu와 네트워크 쓰로틀링을 켠다.
6. Record 버튼을 누른다
7. URL을 입력하고 엔터를 친다.
8. 페이지 로딩이 끝나면 레코딩을 중지한다.

![performance](./images/performance.png)

이제 최초 페이지 로딩시에 자바스크립트 코드가 parse, compile, execution에 걸리는 시간을 측정할 수 있다. 

이에 덧붙여 [User Timing API](https://developer.mozilla.org/en-US/docs/Web/API/User_Timing_API)를 활용해서 웹 애플리케이션의 일부를 사용자에게 의미 있는 이름으로 표시한다. 루트 애플리케이션의 초기렌더링, 블로킹 XHR 호출 등 비용이 많이 들 것으로 우려되는 부분에 초점을 맞춘다. 만약 이러한 측정 작업으로 인한 오버헤드가 우려되는 경우, 프로덕션에서 이러한 기능을 제거하는 방법도 있다. [쿼리 파라미터를 사용해서](https://github.com/nolanlawson/pinafore/blob/ba3b76f769455908eca9f6f59584d18e2bd19f0e/src/routes/_utils/marks.js) 측정 기능을 끌 수도 있고, [terser의 pure_funcs](https://terser.org/docs/api-reference.html#compress-options)를 활용해서 제거할 수도 있다.

```javascript
const enabled = process.browser && performance.mark && (
 process.env.NODE_ENV !== 'production' ||
 (typeof location !== 'undefined' && location.search.includes('marks=true'))
)

const perf = process.browser && performance

export function mark (name) {
 if (enabled) {
 perf.mark(`start ${name}`)
 }
}

export function stop (name) {
 if (enabled) {
 perf.mark(`end ${name}`)
 perf.measure(name, `start ${name}`, `end ${name}`)
 }
}
```

또 다른 유용한 도구는 [mark loader](https://github.com/statianzo/mark-loader)다. 이 플러그인은 디펜던시 런타임 비용을 볼수 있오록 모듈을 측정 api로 감싸는 웹팩 플러그인이다. 

런타임 성능을 측정 할 때 한 가지 주의해야 할 점은, 축소된 코드와 그렇지 않은 코드 사이에 다를 수 있다는 것이다. 사용되지 않는 함수들이 제거 될 수 있고, 코드가 더 작아지고 최적화 될 수 있으며, `env.NODE_ENV === 'development'`로 인해 프로덕션 모드에서 코드가 정제될 수도 있다. 이러한 상황을 잘 해결할 수 있는 방법은, `performance.mark`와 `performance.measure`를 활용하는 것이다. 

### Poser Usage

굳이 환경보호론자가 아니더라도 전력 사용을 최소화하는 것이 중요하다는 것은 누구나 알 것이다. 사람들은 점점 전원 콘센트가 꽂히지 않은 모바일 기기에서 웹을 많이 검색하고 있다. 그리고 고객들은 잘못된 웹사이트 때문에 전력이 바닥나는 것을 원치 않을 것이다. 

전력 사용량은 CPU 사용량의 부분집합으로 취급되곤 한다. 몇 가지 예외를 제외하면, 대부분의 경우 웹사이트가 과도한 전력을 사용하는 이유는 메인스레드에서 과도하게 CPU를 사용하기 때문이다.

따라서 앞에서 설명한 자바스크립트의 parse/compile/execute 시간을 개선한다면, 전력 소비량도 줄일 수도 있다. 특히 수명이 긴 웹 애플리케이션의 의 경우, 대부분의 전력 소모가 첫 페이지 로드 이후에 발생한다. 그렇게 되면 사용자가 유휴 웹 페이지만 보고 있어도, 노트북 팬이 돌아가거나, 휴대폰이 뜨거워지는 것을 알아차릴 수 있다.

이러한 상황에서 선택할 수 있는 도구는 앞서 말한 Chrome DevTools의 Performance 탭이다. 일반적으로, 타이머 또는 애니메이션으로 인해 CPU 사용량이 증가한다. 예를 들어 잘못 코딩된 커스텀 스크롤바, Intersection Observer Polyfill 또는 애니메이션 로딩 스피너는, 매 requestAnimationFrame 이나 setInterval 루프에서 반복되고 있을 수 있다.

이러한 종류의 전원 누수는 또한 최적화되지 않은 CSS 애니메이션으로 인해 발생할 수 있다. 즉, 자바스크립트의 문제가 아닐 수도 있다. (이 경우 Chrome UI에서 보라색으로 표시된다.) CSS 애니메이션을 오래 실행하는 경우, GPU 가속 CSS 속성을 사용해야 한다.

Chrome Performance Monitor Tab은 Performance Tab과 다르다. 수동으로 추적을 시작/중지할 필요 없이 웹사이트가 작동하는 방식을 보여주는 일종의 하트비트 모니터다. 비활성 웹 페이지에서 CPU 사용량이 일정하지 않으면 전원 사용에 문제가 있을 수 있다.

![performance monitor](./images/performance-monitor.png)

> [performance monitor](https://developers.google.com/web/updates/2017/11/devtools-release-notes#perf-monitor)

### Memory Cost

메모리 사용량 분석은 어려웠지만, 최근에는 많은 도구들이 나오면서 개서되었다.

한가지 중요한 것은, 메모리 사용량과 메모리 누수는 별개의 문제라는 것이다. 별도의 메모리 누수가 없다 하더라도, 메모리 사용량이 높을 수도 있다. 반면 작은 규모의 웹사이트가, 유출로 인하여 메모리 사용량이 커질 수도 있다.

메모리 사용량을 분석하는 api는 [performance.measureUserAgentSpecificMemory](https://www.chromestatus.com/feature/5685965186138112)가 있다. 이 API는 다음과 같은 이점이 있다.

1. 가비지 콜렉팅 된 이후에 resolve 되는 Promise를 반환한다.
2. 자바스크립트 VM 크기 뿐만 아니라, 웹 워커와 iframe 등을 포함하는 DOM 메모리도 포함한다.
3. site isolation로 인해 프로세스가 분리된 cross-origin iframe도 세분화한다. 따라서 embedded나 광고가 메모리를 얼마나 먹는지 판단할 수 있다.

```javascript
{
 bytes: 60_000_000,
 breakdown: [
 {
 bytes: 40_000_000,
 attribution: [
 {
 url: "https://foo.com",
 scope: "Window",
 },
 ]
 types: ["JS"]
 },
 {
 bytes: 0,
 attribution: [],
 types: []
 },
 {
 bytes: 20_000_000,
 attribution: [
 {
 url: "https://foo.com/iframe",
 container: {
 id: "iframe-id-attribute",
 src: "redirect.html?target=iframe.html",
 },
 },
 ],
 types: ["JS"]
 },
 ]
}
```

위에 있는 `bytes`는 사용중인 메모리 양을 나타내는 지표다. 

이 API를 사용하는 것은 그럼에도 여전히 까다로울 수 있다. 일단 Chrome 89+에서만 사용할 수 있다. (오래된 버전의 경우 실험용 기능을 체크하고 쓸 수 있다) 그러나 더 문제가 되는 것은, 이를 남용할 가능성 때문에 이 API의 호출은 cross-origin 의 격리된 컨텍스트로 제한되었다는 것이다. 따라서 일부 특수 헤더를 설정해야 하며, cross-origin 리소스 (외부 CSS, 자바스크립트, 이미지 등)에 의존하는 경우 일부 특수 헤더도 설정해야 한다.

이 API를 자동화된 테스트에만 사용할 계획이라면, `--disable-web-security`플래그를 사용하여 크롬을 실행할 수 있다. (물론 어느 정도 위험성을 감수해야 한다.) 그리고 또한가지 참고해야 할 것은, 메모리 측정은 헤드리스 모드에서는 작동하지 않는다는 것이다. 

물론, 이 API 는 세분화해서 데이터를 제공하지 않는다. 예를 들어 리액트와 lodash가 각각 몇 바이트를 차지 하는지는 정확히 알 수 없다는 뜻이다. 이를 위한 가장 확실한 방법은 A/B 테스트다. 이는 메모리 측정을 위해 기존에 사용햇던 방법보다 훨씬더 나은 방법이다.

### Disk Usage

디스크 사용량은 장치에 따라 사용 가능한 저장 용량에 따라 브라우저 할당량 제한에 걸릴수도 있으므로 웹 애플리케이션 사용에 있어서 중요하게 고려해야 한다. 과도한 스토리지 사용은 서비스워커 캐시에 너무 많은 대용량 이미지를 채우는 등 여러가지 형태로 나타날 수 있으며, 자바스크립트 또한 마찬가지다.

자바스크립트 모듈의 디스크 사용량이 번들 크기와 직접적인 상관관계가 있다고 생각할 수 있지만, 꼭 그런것 만은 아니다. 예를 들어 [emoji-picker-element](https://github.com/nolanlawson/emoji-picker-element)의 경우, 이모지 데이터를 indexeddb에서 꽤나 무겁게 사용하고 있기 때문에, 데이터베이스가 디스크 사용을 어떻게 사용하고 있는지 인식해야 한다.

![application-storage](./images/application-storage.png)

크롬 DevTools에 있는 Application Tab에서 현재 웹사이트가 사용하고 있는 전체 용량을 알 수가 있다. 처음 보기엔 괜찮아 보이지만, IndexedDB 의 경우 브라우저 마다 구현 방식이 다르기 때문에 브라우저 마다 차지하는 용량이 다르게 나타날 수 있다. 이를 해결할 수 있는 방법 중하나는 Puppeteer와 비슷한 [Playwright](https://github.com/microsoft/playwright)에서 아래 코드를 실행하는 것이다.

```javascript
function getIdbFolder (browserType, userDataDir) {
 switch (browserType) {
 case 'chromium':
 return path.join(userDataDir, `Default/IndexedDB/http_localhost_${port}.indexeddb.leveldb`)
 case 'firefox':
 return path.join(userDataDir, `storage/default/http+++localhost+${port}/idb`)
 case 'webkit':
 return path.join(userDataDir, `databases/indexeddb/v1/http_localhost_${port}`)
 }
}
```

초기화된 빈 브라우저를 시작할 수 있으므로, 브라우저를 먼저 시작하고 `/temp`에 스토리지를 기록한다음, 인덱싱된 스토리지를 측정하는 것이 가능하다.

## 결론

성능이란 것은 다방면적인 측면을 고려 해야 한다. 번들 사이즈만 줄여서 해결된다면 좋겠지만, 여러가지 측면을 고려해야 한다. 이 때문에 이것이 굉장히 부담스럽게 느껴질 수도 있다. 그래서 [core web vital](https://web.dev/vitals/)이나 번들 사이즈에 집중해서 문제를 해결하는 것이 꼭 나쁜 것 만은 아니다. 웹 애플리케이션 성능 측정에 여러가지를 고민해야 한다고 말하면, 사람들은 이에 압도되서 아무것도 안 할수도 있다. 그렇지만, 이런 것도 있다는 것을 알아둔다면 최적화에 도움이 되지 않을까.


> 참고: https://nolanlawson.com/2021/02/23/javascript-performance-beyond-bundle-size/

자바스크립트 성능에 중요한 건 번들크기 만은 아니다. 근데 개발 하느라 이것도 잘 못챙기고 있는듯.

자바스크립트 성능과 번들 사이즈

** 주의: 제가 하고 있는 프로젝트의 방향성과는 다를 수 있습니다

로깅은 서버사이드에서 중요한 처리 중 하나다. 서버에서 어떤 일들이 일어나고 있는지 알 수 있고, 의도치 않은 동작이나 버그가 발생했을 경우 재빠르게 원인을 찾을 수 있다. 본문에서는 nodejs에서 로깅을 남기는 몇가지 좋은 사례를 알아본다.

## Table of Contents

## 0. 시작하기전에

한가지 알아둬야 할 것은, 모든 정보를 로깅으로 남겨서는 안된다는 것이다. 로깅이 성능과 데이터 용량에 영향을 미치는 것도 있지만, 그것보다도 더 중요한 것은 주민등록번호, 카드번호, 암호와 같은 민감한 정보는 절대로 남겨서는 안된다. 

## 1. console.log로 시작하기

자바스크립트를 배운 순간부터 지금까지 (...) 가장 많이 사용하 있는 `console.log`다. 개인적으로도 급한 프로젝트를 휙휙 처리하다보면 로깅을 `console.log`로 남기곤 했다 (죄송합니다). 조금 더 나아가서 `console.error` `console.group` 등을 사용하는 경우도 있다. `console.log`는 코드 자체가 없어보이는 것은 둘째치고 [자바스크립트의 성능에 안좋은 영향을 미친다.](https://stackoverflow.com/a/11426318) 따라서 본격적으로 로깅을 원한다면, 진짜 로깅에 사용되는 라이브러리를 사용하는 것이 좋다.

## 2. 로그 라이브러리 사용하기

node 진영에서 가장 많이 사용되는 로깅 라이브러리는 크게 다음과 같다.

- [winston](https://github.com/winstonjs/winston): 로그를 별도의 데이터베이스 등에 저장하고 싶을 때. 내가 거친 프로젝트가 대부분 이걸 썼던 것 같다.
- [bunyan](https://github.com/trentm/node-bunyan): CLI가 기가막히다
- [log4js](https://github.com/log4js-node/log4js-node): 로그 스트림, aggregator 등 지원

```javascript
const winston = require('winston');
const config = require('./config');

const enumerateErrorFormat = winston.format((info) => {
 if (info instanceof Error) {
 Object.assign(info, { message: info.stack });
 }
 return info;
});

const logger = winston.createLogger({
 level: config.env === 'development' ? 'debug' : 'info',
 format: winston.format.combine(
 enumerateErrorFormat(),
 config.env === 'development' ? winston.format.colorize() : winston.format.uncolorize(),
 winston.format.splat(),
 winston.format.printf(({ level, message }) => `${level}: ${message}`)
 ),
 transports: [
 new winston.transports.Console({
 stderrLevels: ['error'],
 }),
 ],
});

module.exports = logger;
```

로깅 라이브러리는 일반적인 `console.log`을 사용하는 것보다 여러 측면에서 좋다. 성능에도 더 좋고, 기능도 다양하고, 쉽게 알록달록하게 만들수도 있다.(?)

## 3. Morgan으로 node내 http 요청 로깅하기

또 다른 좋은 습관 중 하나는 nodejs 애플리케이션 내 http 요청을 로깅하는 것이다. 이를 위한 좋은 라이브러리가 바로 [morgan](https://github.com/expressjs/morgan) 이다. 이 도구는 서버 로그를 가져와서 체계화 시켜 읽기 쉽게 만들어 준다.

```javascript
const morgan = require('morgan');
app.use(morgan('dev'));
```

이미 정의된 문자열 포맷을 사용하려면

```javascript
morgan('tiny')
```

를 쓰면 된다.

### winston + morgan

```javascript
const morgan = require('morgan');
const config = require('./config');
const logger = require('./logger');

morgan.token('message', (req, res) => res.locals.errorMessage || '');

const getIpFormat = () => (config.env === 'production' ? ':remote-addr - ' : '');
const successResponseFormat = `${getIpFormat()}:method :url :status - :response-time ms`;
const errorResponseFormat = `${getIpFormat()}:method :url :status - :response-time ms - message: :message`;

const successHandler = morgan(successResponseFormat, {
 skip: (req, res) => res.statusCode >= 400,
 stream: { write: (message) => logger.info(message.trim()) },
});

const errorHandler = morgan(errorResponseFormat, {
 skip: (req, res) => res.statusCode < 400,
 stream: { write: (message) => logger.error(message.trim()) },
});

module.exports = {
 successHandler,
 errorHandler,
};
```

위 예제에서 보이는 것처럼, 두 라이브러리를 함께 쓰기 위해서는 단순히 winston에 morgan에서 나온 결과물을 넘겨주면 된다.

## 4. 로그레벨 정의하기

로그의 이벤트를 구분하기 위해서 로그 수준을 체계적으로 정리하는 것이 중요하다. 이를 잘 정리해두면, 필요한 정보만 빼다가 쉽게 알아낼 수 있다. 로그 수준에는 여러개가 있지만, 다음과 같이 나누는 것이 일반적이다.

- error
- warning
- info
- debug

## 5. 로그 관리 시스템 사용하기

애플리케이션의 크기에 따라서 별도로 로그를 관리하는 시스템을 가져다 쓰는 것이 좋을 수도 있다. (물론 그냥 cat grep 할 수도 있겠지만) 로그 관리 시스템을 사용하면, 실시간으로 로그를 추적하고 분석할 수 있으므로 코드를 개선하는데 용이하다. 주로 사용하는 프로그램은 다음과 같다.

- [Sentry](https://sentry.io/welcome/) 사실 이거밖에 안써봄
- [Loggly](https://www.loggly.com/)
- [McAfee Enterprise Log Search](https://www.mcafee.com/enterprise/ko-kr/products/enterprise-log-search.html)
- [Graylog](https://www.graylog.org/)
- [Splunk](https://www.splunk.com/)
- [Logmatic](https://logmatic.com/)
- [Logstash](https://www.elastic.co/kr/logstash) 생각해보니 엘라스틱 서치 쓰느라 이것도 써본듯


## 6. 상태 모니터링 도구

상태 모니터링 도구는 서버 성능을 추적하고, 애플리케이션 충돌 또는 다운타임의 원인을 식별해 낼 수 있는 좋은 방법이다. 대부분의 도구는 오류 스택 추적과, 성능 모니터링 기능을 제공한다. Nodejs에서 유명한 도구는 다음과 같다.

- [PM2](https://pm2.keymetrics.io/): 가장 유명한 도구 
- [Sematext](https://sematext.com/)
- [Appmetrics](https://www.app-metrics.io/)
- [ClinicJS](https://clinicjs.org/)
- [AppSignal](https://appsignal.com/)
- [Express Status Monitor](https://github.com/RafalWilinski/express-status-monitor)

## 7. 결론

로그도 확인 할 필요 없이 24/365로 잘돌아가는 서비스가 있다면 좋겠지만, 사실 그런 인프라는 존재 하지 않는다. 운영환경을 모니터링하고, 오류를 줄이기 위해서 로깅은 개발자들에게 필수다.

어쩌다 보니 nodejs도 하고 있🤣

Nodejs에서 로깅하기

아래 코드는 일반적으로 `useEffect`를 활용해서 데이터를 가져오는 방식이다.

```javascript
import React, { useEffect } from 'react';

export default function App() {
 const [todo, setTodo] = useState(null);
 useEffect(() => {
 const fetchData = async () => {
 const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
 const newData = await response.json();
 setTodo(newData);
 };
 fetchData();
 }, []);
 if (data) {
 return <div>{data.title}</div>;
 } else {
 return null;
 }
}
```

dependency에 아무것도 넣지 않음으로써, 딱 한번만 실행되게 끔하고 싶었지만, 이는 여전히 레이스 컨디션과 메모리 누수에 취약하다. 만약 서버에서 응답이 오는 시간이 길어졌고, 그 사이에 컴포넌트가 unmount 되었다고 생각해보자. 컴포넌트는 사라졌지만, 여전히 요청은 대기 중이다. 그리고 요청이 온다면, `setTodo`에 값을 넣을 것이며, 리액트는 이제 아래와 같은 경고문을 내뱉을 것이다.

> Can’t perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.

마찬가지로, `id`를 의존성 목록에 넣어서 처리하는 경우도 있을 수 있다.

```javascript
import React, { useEffect } from 'react';
export default function App( {id} ) {
 const [todo, setTodo] = useState(null);
 useEffect(() => {
 const fetchData = async () => {
 const response = await fetch(`https://jsonplaceholder.typicode.com/todos/${id}`);
 const newData = await response.json();
 setTodo(newData);
 };
 fetchData();
 }, [id]);
 if (data) {
 return <div>{data.title}</div>;
 } else {
 return null;
 }
}
```

이 경우에도 마찬가지로, ID가 변경되었지만 요청은 여전히 오지 않는 경우 위와 같은 문제가 있을 수 있다.

## 해결책

```javascript
useEffect(() => {
 let isComponentMounted = true;
 const fetchData = async () => {
 const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
 const newData = await response.json();
 if(isComponentMounted) {
 setTodo(newData);
 }
 };
 fetchData();
 return () => {
 isComponentMounted = false;
 }
}, []);
```

unmount가 될 시에 요청이 늦게 와도 `setTodo`를 방지함으로써 문제를 해결할 수 있다. 그러나 물론 백그라운드에서는 여러개의 요청이 날라가고 있기 때문에 레이스 컨디션 문제가 발생할 수는 있다. 그래도 어쨌든, 마지막 요청의 결과만 UI에 표시된다.

더욱 확실한 방법은, [http fetch를 취소하는 `AbortController`를 사용하는 것이다.](https://developer.mozilla.org/ko/docs/Web/API/AbortController)

```javascript
useEffect(() => {
 let abortController = new AbortController();
 const fetchData = async () => {
 try {
 const response = await fetch('https://jsonplaceholder.typicode.com/todos/1', {
 signal: abortController.signal,
 });
 const newData = await response.json();
 setTodo(newData);
 }
 catch(error) {
 if (error.name === 'AbortError') {
 // requset를 abort하는 과정에서 에러 발생
 }
 }
 };
 fetchData();
 return () => {
 abortController.abort();
 }
}, []);
```

unmount가 되면 cleanup을 통해서 요청을 중단시켰다. 물론, `AbortController`를 사용하기 위해서는 polyfill도 필요할 것이다.

https://overreacted.io/a-complete-guide-to-useeffect/ 도 시간나면 읽어보세용

useEffect와 메모리 누수

아래 코드는 일반적으로 <code>useEffect</code>를 활용해서 데이터를 가져오는 방식이다.
<pre class="language-javascript"><code class="language-javascript">import React, { useEffect } from 'react';

export default function App() {
 const [todo, setTodo] = useState(null);
 useEffect(() => {
 const fetchData = async () => {
 const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
 const newData = await response.json();
 setTodo(newData);
 };
 fetchData();
 }, []);
 if (data) {
 return &#x3C;div>{data.title}&#x3C;/div>;
 } else {
 return null;
 }
}
</code></pre>
dependency에 아무것도 넣지 않음으로써, 딱 한번만 실행되게 끔하고 싶었지만, 이는 여전히 레이스 컨디션과 메모리 누수에 취약하다. 만약 서버에서 응답이 오는 시간이 길어졌고, 그 사이에 컴포넌트가 unmount 되었다고 생각해보자. 컴포넌트는 사라졌지만, 여전히 요청은 대기 중이다. 그리고 요청이 온다면, <code>setTodo</code>에 값을 넣을 것이며, 리액트는 이제 아래와 같은 경고문을 내뱉을 것이다.
<blockquote>
Can’t perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in a useEffect cleanup function.
</blockquote>
마찬가지로, <code>id</code>를 의존성 목록에 넣어서 처리하는 경우도 있을 수 있다.
<pre class="language-javascript"><code class="language-javascript">import React, { useEffect } from 'react';
export default function App( {id} ) {
 const [todo, setTodo] = useState(null);
 useEffect(() => {
 const fetchData = async () => {
 const response = await fetch(`https://jsonplaceholder.typicode.com/todos/${id}`);
 const newData = await response.json();
 setTodo(newData);
 };
 fetchData();
 }, [id]);
 if (data) {
 return &#x3C;div>{data.title}&#x3C;/div>;
 } else {
 return null;
 }
}
</code></pre>
이 경우에도 마찬가지로, ID가 변경되었지만 요청은 여전히 오지 않는 경우 위와 같은 문제가 있을 수 있다.
<h2 id="해결책">해결책</h2>
<pre class="language-javascript"><code class="language-javascript">useEffect(() => {
 let isComponentMounted = true;
 const fetchData = async () => {
 const response = await fetch('https://jsonplaceholder.typicode.com/todos/1');
 const newData = await response.json();
 if(isComponentMounted) {
 setTodo(newData);
 }
 };
 fetchData();
 return () => {
 isComponentMounted = false;
 }
}, []);
</code></pre>
unmount가 될 시에 요청이 늦게 와도 <code>setTodo</code>를 방지함으로써 문제를 해결할 수 있다. 그러나 물론 백그라운드에서는 여러개의 요청이 날라가고 있기 때문에 레이스 컨디션 문제가 발생할 수는 있다. 그래도 어쨌든, 마지막 요청의 결과만 UI에 표시된다.
더욱 확실한 방법은, <a href="https://developer.mozilla.org/ko/docs/Web/API/AbortController">http fetch를 취소하는 <code>AbortController</code>를 사용하는 것이다.</a>
<pre class="language-javascript"><code class="language-javascript">useEffect(() => {
 let abortController = new AbortController();
 const fetchData = async () => {
 try {
 const response = await fetch('https://jsonplaceholder.typicode.com/todos/1', {
 signal: abortController.signal,
 });
 const newData = await response.json();
 setTodo(newData);
 }
 catch(error) {
 if (error.name === 'AbortError') {
 // requset를 abort하는 과정에서 에러 발생
 }
 }
 };
 fetchData();
 return () => {
 abortController.abort();
 }
}, []);
</code></pre>
unmount가 되면 cleanup을 통해서 요청을 중단시켰다. 물론, <code>AbortController</code>를 사용하기 위해서는 polyfill도 필요할 것이다.

자바스크립트는 6가지 원시 타입이 있으며, 그 외에는 모두 객체 타입이다. 따라서 배열도 객체 중 하나라고 볼 수 있다. 그렇다면 아래의 객체도 배열이라고 볼 수 있을까?

```javascript
const a = {
  0: 0,
  1: 1,
  2: 2,
  length: 3
}

a[0] // 0
a[1] // 1
a[2] // 2
a.length //3
```

그렇다면 정확히 배열이라는 것은 무엇일까?

## 배열

### 기본 정보

배열은 아래 4가지 방법으로 생성할 수 있다.

- 배열 리터럴 (`[]`)
- Array 생성자 함수
- [Array.of](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/of)
- [Array.from](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/from)

```javascript
const a = {
  0: 0,
  1: 1,
  2: 2,
  length: 3
}

const b = [1, 2, 3]

typeof a // object
typeof b // object

Object.getPrototypeOf(a) === Object.prototype
Object.getPrototypeOf(b) === Array.prototype  // true
```

객체와 배열은 기본적으로 다음과 같은 서로다른 특징이 있다.

|                 	| Object       	| Array           	|   	|
|-----------------	|--------------	|-----------------	|---	|
| structure       	| key & value  	| index & element 	|   	|
| reference       	| property key 	| index           	|   	|
| order           	| X            	| O               	|   	|
| length property 	| X            	| O               	|   	|

가장 큰 차이로는, 순서와 `length` property 유무다.

### 희소배열

자바스크립트의 배열은, 일반적인 밀집 배열이 아니다. 

여기서 밀집 배열이란, 데이터 타입이 통일되어 있으며 서로 메모리 상에서 연속적으로 인접해 있는 배열을 의미한다. 밀집배열은 따라서 데이터에 접근하는게 효율적이고, 빠르다.

그러나 자바스크립트는 희소배열 형태로 되어 있다. 희소배열은, 밀집 배열과 반대로 배열의 요소를 위한 데이터 공간과 크기가 다르고, 연속적으로 밀집되어 있지도 않은 배열을 의미한다. 이경우 당연히 접근하는데 속도는 조금 느리지만, 요소를 삽입하거나 삭제하는 경우에는 더 빠르다.

## 이터레이션 프로토콜

이터테이련 프로토콜이란, 앞서 언급한 배열 처럼, 순회 가능한 자료 구조를 만들기 위하여 ECMAScript 에서 정의한 규악이다.

ES6 이전에는 배열, 문자열, DOM 콜렉션 등이 각자 방법으로 데이터를 순회할 수 있도록 구성되어 있었지만, ES6에 들어서면서 이러한 순회 가능한 데이터 들이 이터레이션 프로토콜을 준수하여 동일하게 동작하게 끔 설계했다. 이러한 이터레이션 프로토콜에는 두가지가 있다.

### 이터러블 프로토콜

어떠한 값들이 루프되는 것과 같은 이터레이션 동작을 정의하거나, 사용자 정의하는 것을 의미한다. 다시 말해, `Symbol.iterator`를 호출하면 이터레이터를 반환하는 것을 이터러블 프로토콜 이라고 한다.

즉, 해당 객체에 프로토타입을 통해서든, 직접 구현을 했든, `Symbol.iterator`를 호출할 수있고 그것이 이터레이터를 반환한다면, 이터러블이다.

```javascript
const a = {
  0: 0,
  1: 1,
  2: 2,
  length: 3
}

const b = [1, 2, 3]

a[Symbol.iterator] // undefined
b[Symbol.iterator] === Array.prototype[Symbol.iterator] // true
```

### 이터레이터 프로토콜

값들의 순서를 만드는 표준 방법을 의미한다. 객체가 `next()`를 가지고 있고, 그 객체가 `value`와 `done` (`true`, `false`)를 리턴한다면 이터레이터 프로토콜을 준수한 이터레이터다.

## 나만의 이터러블 만들어보기

피보나치 배열을 리턴하는 이터러블을 만들어보자.

```javascript
const fibonacci = function (max) {
  let prev = 0
  let curr = 1

  return {
    [Symbol.iterator]() {
      return {
        next() {
          last = prev + curr
          prev = curr
          curr = last

          return {
            value: curr,
            done: curr >= max
          }
        }
      }
    }
  }
}

const fibonacci100 = fibonacci(100)

for (const i of fibonacci100) {
  console.log(i) // 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
}

const result = [...fibonacci100] // [1, 2, 3, 5, 8, 13, 21, 34, 55, 89]

const iterator = fibonacci(100)[Symbol.iterator]()

console.log(iterator.next()) // { value: 1, done: false }
console.log(iterator.next()) // { value: 2, done: false }
console.log(iterator.next()) // { value: 3, done: false }
console.log(iterator.next()) // { value: 5, done: false }
```

위와 같은 동작은 배열과 유사하다.

```javascript
const a = [1, 2, 3, 5]
const iterator = a[Symbol.iterator]()

console.log(iterator.next()) // { value: 1, done: false }
console.log(iterator.next()) // { value: 2, done: false }
console.log(iterator.next()) // { value: 3, done: false }
console.log(iterator.next()) // { value: 5, done: false }
console.log(iterator.next()) // { value: undefined, done: true}
```

## 이터러블 이면서, 이터레이터인 객체를 리턴

```javascript
const fibonacciFunc = function (max) {
    let prev = 0
    let curr = 1
    
    return {
        [Symbol.iterator]() {
            // 메소드 함수의 this는 메서드를 호출한 객체에 바인딩 된다. 
            // 즉
            /*
            {
              next: [Function: next],
              [Symbol(Symbol.iterator)]: [Function: [Symbol.iterator]]
            }
            */
            return this
        },
        next() {
            last = prev + curr
            prev = curr
            curr = last
            
            return {
                value: curr,
                done: curr >= max
            }
        }
    }
}

const fibonacci100 = fibonacciFunc(100)

for (const i of fibonacci100) {
  console.log(i) // 1, 2, 3, 5, 8, 13, 21, 34, 55, 89
}

const result = [...fibonacci100] // [1, 2, 3, 5, 8, 13, 21, 34, 55, 89]

const iterator = fibonacciFunc(100)

console.log(iterator.next()) // { value: 1, done: false }
console.log(iterator.next()) // { value: 2, done: false }
console.log(iterator.next()) // { value: 3, done: false }
console.log(iterator.next()) // { value: 5, done: false }
```

이터러블과 이터레이터 이름이 헷갈림

자바스크립트의 배열, 그리고 이터러블과 이터레이터 (ES6)

자바스크립트는 새로운 feature 가 제안 되어도, 항상 이전 버전과의 하위호환이 깨지지 않는 선에서 지원이 가능해야 한다. 따라서, 모든 새로운 기능들은 polyfill로 지원이 가능하다. 그러나 이걸 가져다 써보기만 해봤지, 직접 만들어 본적은 없는 것 같다. 그래서 한번 직접 만들어 보려고 한다.

tc39문서를 보다가 새롭게 보게 된 feature 중 하나가 바로 이것이다.

## `Array.prototype.at`

- https://tc39.es/proposal-relative-indexing-method/
- https://github.com/tc39/proposal-relative-indexing-method

`array[0]` 과 비슷 해보이지만, 이것은 파이썬의 그것과 비슷하게 음수까지 지원해 준다. 예컨데, `[-1]`로 인덱싱을 하면 가장 마지막 것을 불러오는 것이다. 이 기능을 한번 polyfill로 구현해보자.

```javascript
function at(n) {
 n = parseInt(n, 10) || 0

 // 음수 일 경우 길이 만큼 더한다. 이렇게 하면 음수 인덱싱을 대응할 수 있다.
 if (n < 0) {
 n += this.length
 }

 // 인덱싱에 대응할 수 없을 경우 undefined를 리턴한다.
 if (n < 0 || n >= this.length) {
 return undefined
 }

 return this[n]
}

for (let T of [Array, String]) {
 Object.definedProperty(T.prototype, "at", { 
 value: at,
 writable: true,
 enumerable: false,
 configurable: true})
}
```

여기서 배울 수 있는 것은 다음과 같다.

### this

정적으로 결정되는 스코프와 다르게, `this`는 어떻게 호출되었는지에 따라서 달라진다. 메서드 this는, 메서드를 호출한 객체, 즉 `.` 연산자 앞에서 호출한 객체가 바인딩 된다. 

```javascript
let arr = [1,2,3]
arr.at(1)
```

우리는 위와 같은 방식으로 `.at()`을 호출하기 때문에, `at` 함수 내부의 `this`는 `at()`을 호출한 객체인 리스트가 될 것이다.

### prototype

`prototype` 프로퍼티는 함수 객체만이 지닌 프로퍼티다. (그리고 `Array`, `String`은 함수다. 사실 당연 한 거아님?) 이는 생성자 함수가 생성할 인스턴스의 프로토타입을 가리킨다. 생성자 함수가 자신이 생성할 객체의 프로토타입을 할당해주기 위해 사용하는 것으로, 여기에 있는 메소드들은 향후 새롭게 생성되는 객체들의 `__proto__` 또는 `Object.getPrototypeOf`로 접근할 수 있다. 

> 모든 Array 인스턴스는 Array.prototype을 상속합니다. 다른 생성자와 마찬가지로, Array() 생성자의 프로토타입을 수정하면 모든 Array 인스턴스도 수정의 영향을 받습니다. 예를 들면, 새로운 메서드와 속성을 추가해 모든 Array를 확장할 수 있으므로, 폴리필에 쓰입니다.

![array-prototype](./images/array-prototype.png)

```javascript
Array.prototype === Object.getPrototypeOf([1, 2, 3]) // true
```

## `definedProperty`

`definedProperty`를 알기 위해서는, property attribute를 알아야 한다. 이는 프로퍼티의 상태를 의미하며, 데이터 프로퍼티와 접근자 프로퍼티가 있다.

- 데이터 프로퍼티: 일반적인 프로퍼티로, 키와 값으로 구성되어 있다.
- 접근자 프로퍼티: 자체적으로 값을 가지고 있지는 않지만, 다른 데이터 프로퍼티의 값을 읽거나 지정할 때 호출되는 접근자 함수로 구성된 프로퍼티

여기에서 우리가 사용해야할 것은 데이터 프로퍼티로, `value` `writable` `enumerable` `configurable`을 값을 가진다. 그리고 `definedProperty`를 통해서, 새로운 프로퍼티를 정의할 수 있다. 나는 `Array` 와 `String`에 각각 지정했다.

## 공식 polyfill과 다른점

### 1. Math.trunc vs parseInt

숫자를 처리하는데 있어 나는 `parseInt`를 썼지만, 저 친구는 `Math.trunc`를 사용했다. 이는 그냥 소수점 이하 단위를 버리는 함수다. 굳이 굳이 비교하면 뭔차이가 있을까 하고 찾아봤는데

https://www.samanthaming.com/tidbits/55-how-to-truncate-number/ 

> parseInt is mainly used for a string argument. So if you're dealing with numbers, it's way better to use Math.trunc().

뭔가 성능에 있어서 차이가 있나보다. 아쉽게도 `jsPerf`가 뻗어있어서 (2021.02.15 기준) 알수가 없었지만, 아무튼 그런가 보다. 시간나면 해보자.

### 2. 형식화 배열

자바스크립트의 `Indexed Collections`에는 다음과 같은 것들이 있다.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects#indexed_collections

- Array
- Int8Array
- Uint8Array
- Uint8ClampedArray
- Int16Array
- Uint16Array
- Int32Array
- Uint32Array
- Float32Array
- Float64Array
- BigInt64Array
- BigUint64Array

https://developer.mozilla.org/ko/docs/Web/JavaScript/Typed_arrays

> JavaScript 형식화 배열(typed array)은 배열같은 객체이고 원시(raw) 이진 데이터에 액세스하기 위한 메커니즘을 제공합니다. 이미 아시다시피, Array 객체는 동적으로 늘었다 줄고 어떤 JavaScript 값이든 가질 수 있습니다. JavaScript 엔진은 이러한 배열이 빨라지도록 최적화를 수행합니다. 그러나, audio 및 video 조작과 같은 기능 추가, WebSocket을 사용한 원시 데이터에 액세스 등 웹 어플리케이션이 점점 더 강력해짐에 따라, 빠르고 쉽게 형식화 배열의 원시 이진 데이터를 조작할 수 있게 하는 것이 JavaScript 코드에 도움이 될 때가 있음이 분명해 졌습니다.

사실 자바스크립트의 배열은 엄밀히 말하면 자료구저의 배열이 아니다. 자료구조의 배열은, 동일한 크기의 메모리 공간이 빈틈없이 연속적으로 나열되어 있어야 한다. (밀집 배열) 그러나 자바스크립트 배열은 희소배열이다. 자바스크립트는 동일한 크기를 연속적으로 확보하는 것이 불가능하므로 (무슨타입이 올줄 알고?) 배열의 동작을 흉내내서 만들었다. 그러나 위에 언급된 `Array`를 제외한 나머지 배열들을 `.from()`으로 만들경우, 진짜 `dense array`, 밀집 배열을 만들 수 있다.

> When Array.from() gets an array-like which isn't an iterator, it respects holes. TypedArray.from() will ensure the result is dense.

물론 Array로도 밀집 배열을 만들 수 있다. https://2ality.com/2012/06/dense-arrays.html

아무튼 지간에 결론은, 자바스크립트에는 저런 배열들도 있으므로, 저런 배열의 prototype에도 마찬가지로 추가를 해줬어야 했다.

yceffort

자바스크립트 성능과 번들 사이즈

Nodejs에서 로깅하기

useEffect와 메모리 누수

자바스크립트의 배열, 그리고 이터러블과 이터레이터 (ES6)

나만의 자바스크립트 polyfill 만들고 공부하기