## Cookies

웹 애플리케이션을 설계 할 때, 어떻게 사용자를 로그인시키고, 해당 요청 사이에 사용자 정보를 유지시킬 지에 대한 고민을 해본 경험이 있을 것이다. 이를 위해 사용하는 핵심 메커니즘은 쿠키다. 쿠키는 서버가 클라이언트에 보내는 작은 문자열이다. 클라이언트가 이 문자열을 수신한 뒤에, 이후 요청에서 이 문자열을 반복한다. 예를 들어 쿠키에 `user_id`를 저장할 수 있으며, 향후 요청시에 클라이언트의 `user_id`를 반복적으로 알아 낼 수 있다.

```
Cookie: USER_ID=123
```

하지만 이는 보안에 취약하다. 이 정보는 브라우저에서 볼 수 있으며, 사용자가 `user_id`를 변경해서 다른 유저인 척 할 수도 있다.

## Sessions

이 문제를 해결하는 방법으로는 session이 있다. 종종 세션과 쿠키는 서로 다른 것으로 묘사되지만, 그렇지 않다. 세션이 작동하기 위해서는 쿠키가 필요하다.

```
Cookie: MY_SESSION_ID=WW91IGdvdCBtZS4gRE0gbWUgb24gdHdpdHRlciBmb3IgYSBmcmVlIGNvb2tpZQ
```

`user_id`를 예측할 수 있게 하는 대신에, 클라이언트에 완전히 랜덤으로 생성된 session id를 전송하여 이게 무엇인지 알 수 없게 한다. ID는 그 외에 어떠한 의미도 가족 있지 않으며, 무엇으로도 decode 될 수 없다. 이를 `opaque token`이라고도 한다.

클라이언트가 서버로 반복해서 이 session id를 보내면, 서버는 이 id를 참고하여 데이터베이스에서 유저를 식별하여 연결 시킨다. 사용자가 로그아웃을 하게 되면, 이 session id는 데이터베이스에서 사라지게 되며, 더이상 이 쿠키로는 해당 사용자를 식별 할 수 없게 된다.

### 세션 데이터는 어디에 저장되어야 하는가?

PHP와 같은 경우에는 기본적으로 로컬 파일시스템에 데이터를 저장할 수 있다. node.js에는, 메모리에 데이터를 저장하며 서버가 재시작 되면 해당 데이터는 사라지게 된다.

이러한 접근 방식은 개발자 컴퓨터나, 배포가 거의 없는 호스팅 사이트에서는 정상적으로 작동할 수도 있지만, 요즘 배포는 완전히 새로운 시스템을 구성해서 구축하므로, 이 정보를 서버보다 오래 사는 곳에 저장해야 한다. 가장 쉽게 선택할 수 있는 옵션은 데이터 베이스다. Redis, memcached를 사용하는 것이 일반적이다. 이 시스템은 사이트의 규모에 상관 없이 잘 작동한다.

## 암호화된 토큰

몇년 전 부터 [JWT](https://jwt.io/)가 등장했다. `JWT`는 JSON객체를 암호화/서명하는 표준이며, 인증을 처리하는데 사용된다. 쿠키에 앞서 설명한 `opaque token`을 사용하는 대신에, 실제 `user_id`를 심어둘 수 있는데, 여기에 서명이 추가된다. 이 서명은 서버에서만 생성될 수 있으며, 이는 `secret` 값을 활용하여 계산되고 쿠키에 데이터 형태로 저장된다.

이 말인 즉슨, 데이터가 변형될 경우 (`user_id`가 변경될 경우) 더이상 이 서명은 의미가 없게 된다는 뜻이다.

이 방법의 가장 큰 장점은, 시스템에서 Redis나 다른 DB를 사용할 필요 없이 세션 데이터를 저장할 수 있다는 것이다. 모든 정보는 JWT에 있으며, 인프라가 더욱 가벼워 질 수 있다. 별도로 사용자 정보를 요청할 필요가 없으므로 데이터 요청이 조금더 가벼워 질 수 있다.

## 단점

그러나 이러한 JWT에는 몇가지 단점이 존재한다.

첫번째로, JWT는 매우 복잡한 표준이어서 사용자가(개발자) 잘못 이해할 가능성이 있다. 설정이 잘못되는 경우 최악에 모든 사용자가 유효한 JWT를 생성해서 다른 사용자인척 할 수 있다. 이는 초보개발자들 사이에서 나오는 실수가 아니고, 실제로 [Auth0에서 이러한 버그를 만들어낸 적이 있다.](https://insomniasec.com/blog/auth0-jwt-validation-bypass) 이는 [많은 보안 전문가들이 JWT를 싫어하게 되는 이유 중 하나](https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid)가 되었다. JWT는 수많은 기능을 제공하고 있기 때문에, 개발자들이 잠재적으로 실수 할 수 있는 범위가 넓다.

두번째로, 로그아웃에 문제가 있다. 전통적인 세션을 활용하는 방법의 경우, 단순히 세션 스토리지에서 해당 세션 값을 날리면 되었고 이것으로 충분했다. 그러나 JWT와 다른 무상태 (stateless) 토큰으로는 이것이 불가능하다. 우리는 이 토큰을 지울 수 없다. 왜냐하면 이는 스스로 정보를 담고 있는 토큰이며, 토큰의 상태를 관리하는 중앙 인증 관리 시스템이 없기 때문이다. 이는 아래 세가지 방법으로 해결할 수 있다.

1.  토큰의 생명 주기를 굉장히 짧게 하는 방법 (5분 이내). 해당 시간이 지나면, 새롭게 토큰을 만든다.
2.  시스템에서 최근에 만료된 토큰을 저장해 두는 것
3.  서버 로그아웃 기능 자체를 없애고, 클라이언트에 토큰 삭제를 맡기는 방법
    좋은 시스템의 경우엔 앞에 두가지 방법을 선택한다. 그러나 두 문제의 해결책에서 볼 수 있는 것처럼, 두 방법은 모두 중앙에서 인증을 관리해야 하는 시스템이 필요하며 이는 더이상 JWT의 장점을 유효하지 않게 만든다.

마지막으로, JWT의 크키는 상대적으로 크기 때문에, 쿠키에 JWT를 담을 경우 오버헤드가 발생한다는 것이다.

## 그런데 왜 유명해졌을까?

기술 블로그를 읽을 때 놀라운 것 중 하나는, JWT에 대해 논하는 사람이 많다는 것이다. 그렇다고 JWT가 세션 토큰 보다 인기 있다는 것은 아니다. 마찬가지로 GraphQL이 REST 보다, No SQL이 관례형 데이터베이스보다 인기 있다는 것은 아니다. 10년 이상 시도되고 테스트된 기술에 대해 이야기하는 것은, 그다지 흥미롭지 않기 때문이다. 신기술은 이전 기술보다 더 많은 화제를 불러일으키고, 사람들이 이 신기술에 대해 계속 이야기 한다면, 단순히 차선책임에도 불구하고 실제 채택으로 이루어질 수도 있다.

이것은 마치 요즘 새로운 개발자들이 서버에서 렌더링되는 HTML을 배우기전에, 리액트로 SPA를 배우는 것과 비슷하다. 경험 많은 개발자들은 서버 사이들 렌더링 HTML이 기본이 되어야 한다고 느낄 것이다. 그리고 필요할 때 SPA를 사용해야 하지만, 새로운 개발자들은 일반적으로 그렇게 배우고 있지 않다.

JWT를 선호하는 이유 중 가장 큰 것은 '확장성' 이다. 그러나 사람들은 '어떤 규모의 확장성' 에서 문제를 겪게 될지를 인지하고 있지는 못하는 것 같다. 대부분의 사람들이 생각하는 문제가 발생할 수 있는지점은, 일반적으로 가정하고 있는 지점 보다 훨씬 더 높은 곳에 있을 것이다.

예를 들어, 우리가 운영하는 사이트는 페이스북 규모가 아니다. 페이스북 규모 정도, 몇백만개의 유효한 세션이 존재할 수 있는 상황에서야 비로소 key-value 세션의 문제가 나타날 수 있다.

그러나 통계적으로, 우리가 만드는 라즈베리파이에서도 쉽게 돌아갈 수 있는 애플리케이션이다.

## 결론

JWT를 사용하면, 속성을 추가할 수 있고 경우에 따라 서비스가 stateless 해질 수도 있으며, 이는 일부 아키텍쳐에서 바람직한 모습이 될 수도 있다. 그러나 여기에는 단점이 존재한다. 단순히 세션 저장소와 `opaque token`을 추가하는 것보다 훨씬 더 복잡한 인프라를 구축해야 한다. 단순히 JWT를 쓰지말라는 것은 아니라, 선택을 함에 있어서 매우 신중해야 한다는 것이다. 보안 및 기능의 트레이드 오프에 유의해야 한다. bolierplate의 템플릿에 넣지말고, 기본 값으로 JWT를 채택해서는 안된다.

https://evertpot.com/jwt-is-a-bad-default/


JWT의 단점과 주의사항

HTTP1 vs HTTP2

요즘 자바스크립트 프로젝트를 하다보면, `devDependencies`에 정말 많은 의존성이 있음을 알 수 있다. 자바스크립트 트랜스파일링, 코드 최소화, CSS pre-processor, eslint, prettier 등등등. 이러한 기능들은 실제 프로덕션 코드로 올라가는 것은 아니지만, 개발 과정에서 중요한 것들을 담당한다. 그리고 이러한 툴들은 AST processing 을 기반으로 작동한다.

## AST 란 무엇인가?

> 컴퓨터 과학에서 추상 구문 트리(abstract syntax tree, AST), 또는 간단히 구문 트리(syntax tree)는 프로그래밍 언어로 작성된 소스 코드의 추상 구문 구조의 트리이다. 이 트리의 각 노드는 소스 코드에서 발생되는 구조를 나타낸다. 구문이 추상적이라는 의미는 실제 구문에서 나타나는 모든 세세한 정보를 나타내지는 않는다는 것을 의미한다. 예를 들어, 그룹핑을 위한 괄호는 암시적으로 트리 구조를 가지며, 분리된 노드로 표현되지는 않는다. 마찬가지로, if-condition-then 표현식과 같은 구문 구조는 3개의 가지에 1개의 노드가 달린 구조로 표기된다.

https://ko.wikipedia.org/wiki/%EC%B6%94%EC%83%81_%EA%B5%AC%EB%AC%B8_%ED%8A%B8%EB%A6%AC

(뭔 소리 인지 모르겠으니) 예제를 살펴보자.

> 모든 예제는 https://astexplorer.net/ 여기에서 가져왔다

```javascript
function square(n) {
  return n * n
}
```

를 AST로 변환하면

```json
{
  "type": "Program",
  "start": 0,
  "end": 36,
  "loc": {
    "start": {
      "line": 1,
      "column": 0
    },
    "end": {
      "line": 3,
      "column": 1
    }
  },
  "range": [0, 36],
  "errors": [],
  "comments": [],
  "sourceType": "module",
  "body": [
    {
      "type": "FunctionDeclaration",
      "start": 0,
      "end": 36,
      "loc": {
        "start": {
          "line": 1,
          "column": 0
        },
        "end": {
          "line": 3,
          "column": 1
        }
      },
      "range": [0, 36],
      "id": {
        "type": "Identifier",
        "start": 9,
        "end": 15,
        "loc": {
          "start": {
            "line": 1,
            "column": 9
          },
          "end": {
            "line": 1,
            "column": 15
          },
          "identifierName": "square"
        },
        "range": [9, 15],
        "name": "square",
        "_babelType": "Identifier"
      },
      "generator": false,
      "async": false,
      "expression": false,
      "params": [
        {
          "type": "Identifier",
          "start": 16,
          "end": 17,
          "loc": {
            "start": {
              "line": 1,
              "column": 16
            },
            "end": {
              "line": 1,
              "column": 17
            },
            "identifierName": "n"
          },
          "range": [16, 17],
          "name": "n",
          "_babelType": "Identifier"
        }
      ],
      "body": {
        "type": "BlockStatement",
        "start": 18,
        "end": 36,
        "loc": {
          "start": {
            "line": 1,
            "column": 18
          },
          "end": {
            "line": 3,
            "column": 1
          }
        },
        "range": [18, 36],
        "body": [
          {
            "type": "ReturnStatement",
            "start": 22,
            "end": 34,
            "loc": {
              "start": {
                "line": 2,
                "column": 2
              },
              "end": {
                "line": 2,
                "column": 14
              }
            },
            "range": [22, 34],
            "argument": {
              "type": "BinaryExpression",
              "start": 29,
              "end": 34,
              "loc": {
                "start": {
                  "line": 2,
                  "column": 9
                },
                "end": {
                  "line": 2,
                  "column": 14
                }
              },
              "range": [29, 34],
              "left": {
                "type": "Identifier",
                "start": 29,
                "end": 30,
                "loc": {
                  "start": {
                    "line": 2,
                    "column": 9
                  },
                  "end": {
                    "line": 2,
                    "column": 10
                  },
                  "identifierName": "n"
                },
                "range": [29, 30],
                "name": "n",
                "_babelType": "Identifier"
              },
              "operator": "*",
              "right": {
                "type": "Identifier",
                "start": 33,
                "end": 34,
                "loc": {
                  "start": {
                    "line": 2,
                    "column": 13
                  },
                  "end": {
                    "line": 2,
                    "column": 14
                  },
                  "identifierName": "n"
                },
                "range": [33, 34],
                "name": "n",
                "_babelType": "Identifier"
              },
              "_babelType": "BinaryExpression"
            },
            "_babelType": "ReturnStatement"
          }
        ],
        "_babelType": "BlockStatement"
      },
      "_babelType": "FunctionDeclaration"
    }
  ]
}
```

이렇게 나온다. (`babel-eslint9`)

코드 텍스트에서, 트리 구조의 데이터 스트럭쳐를 만들어 낸다. 코드에 있는 아이템이 각 트리에 있는 노드와 매치된다.

그런데 어떻게 코드에서 AST를 가져오는 것일까? 이러한 작업은 컴파일러가 하는데, 일반적인 컴파일러가 어떻게 처리하는지 알아봐야 한다. 그전에, 여기에서는 고수즌의 언어코드를 컴퓨터가 이해하는 바이트 코드로 까지 변환하는 모든 단계를 다루지는 않으려고 한다. 우리는 렉시컬, 그리고 신택스 분석에만 관심이 있다. 그리고 이 두 단계는 코드에서 AST를 생성하는데 중요한 역할을 한다.

첫번째 단계, 렉시컬 분석 (Lexical analyzer aka scanner)는 코드의 문자들을 읽어서 정해진 룰에 따라서 이들을 토큰으로 만들어 합친다. 또한 여기에서 공백, 주석 등을 지우고 마지막으로는 이 전체 코드를 토큰들로 나눈다. 이 렉시컬 분석기가 소스 코드를 읽을 때, 코드를 글자단위로 읽는다. 그 과정에서 공백, operator symbol, special symbol 를 만나면 해당 단어가 끝난 것으로 간주한다.

두번째 단계, 신택스 분석 (Syntax analyzer aka parser) 에서는 위에서 결과로 나온 토큰 목록을 트리 구조로 만들며, 구조적 혹은 언어적으로 문제가 있을 경우 에러를 내뱉는다. 트리를 만드는 과정에서, 일부 파서들은 불필요한 토큰 (중복된 괄호라든지)를 생략한다. 그리고 그 결과로 `Abstract Syntax Tree`를 만든다. 이는 코드와 100% 일치하지는 않지만, 코드를 다루기에는 충분하다.

다음은 AST를 배우고 싶을 때 참고 할만한 레포 목록이다.

- 컴파일러에 대해서 배우고 싶다면, [The-super-tiny-compiler](https://github.com/jamiebuilds/the-super-tiny-compiler)를 보는 것을 추천한다. 자바스크립트 로 쓰여진 가장 간단한 컴파일러 예제를 구현해두었다.
- [LangSandbox](https://github.com/ftomassetti/LangSandbox) 또한 재밌는 프로젝트다. 여기에서는 어떻게 프로그래밍 언어를 만들어야 하는지 보여준다.,
- [AST Explorer](https://astexplorer.net/)
- [@babel/parser](https://github.com/babel/babel/tree/master/packages/babel-parser) 구 babylon

이제 AST가 코드에서 어떻게 만들어졌는지 알아보았으니, 실제 유즈케이스를 확인해보자.

가장 첫번째로 이야기할 사용사례는 당연히, 트랜스파일링이다.

https://babeljs.io/ 바벨은 다들 아시다시피, 자바스크립트 컴파일러다. 바벨은 크게 3단계로 이루어진다. (parsing, transforming, generation) 바벨에 자바스크립트 코드를 넘기면, AST를 활용해서 코드를 새롭게 변환해서 만든다.

```javascript
import * as parser from '@babel/parser'
import generate from '@babel/generator'
// string code
const pureCode = `
  const welcome = 'hello world'
`

// ast
const ast = parser.parse(pureCode)

// generate
const finalCode = generate(ast)
```

```json
{
  "type": "File",
  "start": 0,
  "end": 33,
  "loc": {
    "start": {
      "line": 1,
      "column": 0
    },
    "end": {
      "line": 3,
      "column": 0
    }
  },
  "errors": [],
  "program": {
    "type": "Program",
    "start": 0,
    "end": 33,
    "loc": {
      "start": {
        "line": 1,
        "column": 0
      },
      "end": {
        "line": 3,
        "column": 0
      }
    },
    "sourceType": "script",
    "interpreter": null,
    "body": [
      {
        "type": "VariableDeclaration",
        "start": 3,
        "end": 32,
        "loc": {
          "start": {
            "line": 2,
            "column": 2
          },
          "end": {
            "line": 2,
            "column": 31
          }
        },
        "declarations": [
          {
            "type": "VariableDeclarator",
            "start": 9,
            "end": 32,
            "loc": {
              "start": {
                "line": 2,
                "column": 8
              },
              "end": {
                "line": 2,
                "column": 31
              }
            },
            "id": {
              "type": "Identifier",
              "start": 9,
              "end": 16,
              "loc": {
                "start": {
                  "line": 2,
                  "column": 8
                },
                "end": {
                  "line": 2,
                  "column": 15
                },
                "identifierName": "welcome"
              },
              "name": "welcome"
            },
            "init": {
              "type": "StringLiteral",
              "start": 19,
              "end": 32,
              "loc": {
                "start": {
                  "line": 2,
                  "column": 18
                },
                "end": {
                  "line": 2,
                  "column": 31
                }
              },
              "extra": {
                "rawValue": "hello world",
                "raw": "'hello world'"
              },
              "value": "hello world"
            }
          }
        ],
        "kind": "const"
      }
    ],
    "directives": []
  },
  "comments": []
}
```

babel과 관련된 자세한 내용은 https://github.com/jamiebuilds/babel-handbook 에서 공부해볼 수 있다.

다음으로 알아볼 유즈 케이스는, 코드를 자동으로 리팩토링 해주는 [JSCodeShift](https://github.com/facebook/jscodeshift)다. 예를 들어, 아래와 같은 코드 리팩토링이 있다고 가정해보자.

```javascript
load().then(function (response) {
  return response.data
})
```

```javascript
load().then((response) => response.data)
```

단순한 찾아 바꾸기가 아니기 때문에, 일반적인 코드 에디터에서는 이러한 리팩토링이 불가능할 것이다. 그리고 이것을 가능하게 하는 것이 `jscodeshift`다.

`jscodeshift`에 대해서 들어봤다면, `codemods`에 대해서도 들어봤을 것이다. `Jscodeshift`는 `codemods`를 실행시키는 툴킷이다. `codemods`에서 실제 AST 를 활용한 변환이 일어난다. 따라서, 기본적인 아이디어는 babel과 하위 플러그인과 유사하다.

- https://github.com/reactjs/react-codemod
- https://github.com/facebook/jscodeshift

다음으로 알아보는 유즈케이스는 `Prettier`다. prettier는 자동으로 줄바꿈도 해주고, 공백도 제거해주며, 괄호도 다듬어 주는 도구다. 따라서 prettier는 기존의 코드를 받아서, 이를 다듬은 코드로 리턴한다는 것을 알 수 있다. 이러한 과정 또한 마찬가지로, AST를 거친다.

아이디어는 기본적으로 똑같다. 코드를 받아서 AST를 만든다. 그리고, 여기에서 prettier가 활약한다. AST는 `intermediate representation`나 `Doc` 형태로 변환된다. AST 노드는 여기에서 포맷팅의 관점에서 어떻게 서로 연관되어 있는지 정보도 추가되어서 변환된다. 만약, 리스트가 길고 한줄에 맞지 않으면 각 파라미터를 별도의 줄로 분할한다. 그다음, `printer`라고 하는 알고리즘이 IR을 거쳐서 전체 그림을 바탕으로 코드를 포맷팅할 방법을 결정하게 된다.

> prettier에 대해 더 자세히 알고 싶다면 https://homepages.inf.ed.ac.uk/wadler/papers/prettier/prettier.pdf 이 논문을 참고하면 좋다.

마지막으로 알아볼 유즈케이스느 [js2flowchart](https://github.com/Bogdan-Lyashenko/js-code-to-svg-flowchart) 다. 이 라이브러리는 코드를 기준으로 플로우차트를 그려주는 라이브러리다. 플로우차트로 코드를 설명/문서화 할 수 있으며, 시각적인 이해를 바탕으로 다른 코드를 학습할 수 있고, 나아가 유효한 JS 문법을 기준으로 플로우차트를 간단하게 만들어 볼 수도 있다.

```javascript
/**
 * Binary search
 * @param {Array} list
 * @param {Number} element
 * @returns {number}
 */
function indexSearch(list, element) {
  let currentIndex,
    currentElement,
    minIndex = 0,
    maxIndex = list.length - 1

  while (minIndex <= maxIndex) {
    currentIndex = Math.floor((maxIndex + maxIndex) / 2)
    currentElement = list[currentIndex]

    if (currentElement === element) {
      return currentIndex
    }

    if (currentElement < element) {
      minIndex = currentIndex + 1
    }

    if (currentElement > element) {
      maxIndex = currentIndex - 1
    }
  }

  return -1
}
```

![flowchart](./images/flowchart.svg)

https://bogdan-lyashenko.github.io/js-code-to-svg-flowchart/docs/live-editor/index.html

이 라이브러리는 어떻게 동작할까? 먼저 코드를 AST로 변환한다음, AST를 순회하며 Flowtree라고 하는 또다른 트리를 만든다. 여기에서는 중요하지 않은 토큰들을 생략하는 등의 과정을 거친다. 그 다음에, Flowtree를 순회하며 ShapesTree라는 것을 만든다. 여기에 각각 노드들은 각 노드의 타입, 위치, 트리사이의 관계등을 나타내고 있다. 마지막으로, 이를 기준으로 SVG 파일을 만들어 낸다.


자바스크립트 개발자를 위한 AST 이해하기

블로그에서 추가되는 이미지를 자동으로 최적화하기 위해 https://imgbot.net/ 을 사용하고 있다. imgbot을 사용하면, 새롭게 추가되는 이미지들에 대해서 최적화를 해주는 PR을 만들어 준다. https://github.com/yceffort/yceffort-blog-v2/pull/298 (빌드가 실패한 것에 대해선 정말 긴 히스토리가 있다, imgbot 때문이 아니다)

그러나 기존에 추가되었던 이미지들에 대해서는 최적화가 안되기 때문에, 이를 위해서 방법을 찾아보다가 아래와 같은 라이브러리를 사용했다.

## PNG

```bash
brew install optipng
apt-get install optipng
```

```bash
find . -iname "*.png" -exec optipng -o7 {} \;
```

http://optipng.sourceforge.net/

PNG의 경우에는 굉장히 오래걸렸다.

## JPG, JPEG

```bash
brew install jpegoptim
sudo apt-get install jpegoptim
```

```bash
find . -iname "*.jpg" -exec jpegoptim -m80 -o -p {} \;
```

## GIF

```bash
brew install gifsicle
sudo apt-get install gifsicle
```

```bash
find . -iname "*.gif" -exec gifsicle --batch -V -O2 {} \;
```

## GUI application

일괄적으로 모든 파일을 수정하기 위해서는 위 명령어를 사용했지만, GUI application도 있어서 필요할 때 사용하면 좋을 것 같다.

https://imageoptim.com/mac


디렉토리에 있는 모든 이미지 최적화 하기

nodejs 10.5.0 버전 이후에서 부터는 `worker_threads`가 가능해졌고, 12 LTS 부터 stable로 자리잡았다. 이 `worker_threads`는 무엇이고 어떤 역할을 하는 것일까?

## 싱글스레드 세상

자바스크립트는 브라우저에서 실행되는 단일 스레드 프로그래밍 언어로 설계되었다. 단일 스레드 라는 것은, 하나의 프로세스 (브라우저 또는 모던 브라우저의 경우 하나의 탭)에서 하나의 명령어 집합만 실행된다는 것을 의미한다.

이러한 설계는 개발자들이 언어를 사용하는데 있어서 더 쉽게 할 수 있는 요소가 되었다. 자바스크립트는 처음에 웹 페이지, 폼 유효성 검사 등의 상호작용을 추가하는데만 사용되었었는데, 이 정도 작업으로는 멀티스레딩의 복잡함이 전혀 필요하지 않았다.

그러나 nodejs의 창시자(Ryan Dahl)는 이러한 한계를 기회로 보았다. 그는 비동기 IO 를 기반으로 서버측 플랫폼을 구현하고 싶어했다. 즉, 쓰레드가 필요하지 않았다. 동시성은 매우 풀기 어려운 문제가 될 수 있다. 동일한 메모리에 접근하려고 하는 스레드가 많아지면 재현 및 수정이 매우 어려운 race condition 문제가 발생할 수 있다.

## nodejs는 싱글스레드 인가?

그래서, nodejs 애플리케이션은 단일 스레드일까? 어느정도는 그렇다.

사실 우리는 병렬로 실행할 수 있지만, 우리는 쓰레드를 만들지도 않고 이를 동기화 하지도 않는다. 가상머신과 운영체재가 IO를 병렬로 실행하며, 자바스크립트 코드로 데이터를 다시 전송해야 할 때, 자바스크립트 부분은 단일 쓰레드로 실행된다.

즉, 자바스크립트 코드를 제외한 모든 것이 병결로 실행된다. 자바스크립트 코드의 동시식 블록은 항상 한번에 하나씩 실행된다.

```javascript
let flag = false
function doSomething() {
  flag = true
  // flag를 수정하지 않는 더 많은 코드...

  // 우리는 flag가 true라는 것은 확신할 수 있다.
  // 이 코드 블록이 동기로 실행되는 이상,
  // 이 코드블록이 flag 값을 바꿀일이 없다.
}
```

우리가 처리하는 것이 모두 비동기 IO로 이루어져있다면 이러한 방식은 매우 훌륭하다고 볼 수 있다. 코드는 빠르게 실행되고, 데이터를 파일과 스트림에 전달하는 동기 블록은 작은 부분으로 구성된다. 자바스크립트 코드는 너무 빨라서, 다른 자바스크립트의 실행을 막지 못한다. 자바스크립트 코드가 실행될 때 보다, IO 이벤트가 발생할 때 까지 기다리는 시간이 훨씬 더 많다. 아래 예를 살펴보자.

```javascript
// 2
db.findOne('SELECT ... LIMIT 1', function (err, result) {
  if (err) return console.error(err)
  console.log(result)
})

// 1
console.log('Running query')

// 3
setTimeout(function () {
  console.log('Hey there')
}, 1000)
```

데이터베이스로 실행한 이 쿼리는 몇 분 정도 걸릴 수 있지만, `Running query` 메시지는 쿼리를 호출한 후 즉시 표시된다. 그리고 잠시 후 쿼리가 여전히 실행중인지 아닌지를 확인 한후, 잠시후에 `Hey there` 메시지를 볼 수 있다.

nodejs 애플리케이션은 함수를 호출할 뿐, 다른 코드의 실행을 차단하지 않는다. 조회사 완료되면 콜백을 통해 알림을 받고, 결과를 받는다.

## CPU 집약적인 작업

만일 큰 데이터를 가지고 메모리에서 복잡한 계산을 수행하는 것 과 같이, 동기 집약적인 작업을 수행해야하는 경우엔 어떻게 될까? 그렇게 되면 많은 시간이 걸리게되고, 나머지 코드를 차단하는 동기 코드블록이 생길 수도 있다.

동기 코드 실행에 10초가 걸린다고 상상해보자. 웹서버를 실행중이면, 이 작업 때문에 다른 요청이 최소 10초동안 차단된다. 100ms이상 걸리는 작업은 문제를 유발할 수 있다.

자바스크립트와 nodejs는 CPU 바인딩 작업에 사용할 수 없었다. 자바스크립트는 단일 스레드이기 때문에, 브라우저의 UI는 멈추게되고, Nodejs의 IO 이벤트를 넣게 된다.

```javascript
db.findAll('SELECT ...', function (err, results) {
  if (err) return console.error(err)

  // 겁나 오래 걸리는 작업
  for (const encrypted of results) {
    const plainText = decrypt(encrypted)
    console.log(plainText)
  }
})
```

조회가 완료되면 콜백이 실행된다. 콜백이 실행 끝날 때 까지 자바스크립트 코드가 실행되지 않는다.

일반적으로, 앞서 이야기 한 것 처럼 코드는 일반적으로 매우 작고 빠르다. 그러나 위의 예제 코드에서는, 많은 결과가 나오고, 이에 따른 많은 계산이 필요하다. 이는 몇 초 정도 걸릴 수 있으며, 이 기간 동안은 다른 자바스크립트 실행이 대기 중이 기 때문에, 동일한 애플리케이션에서 서버를 실행하는 경우 해당 시간 동안 모든 사용자가 블로킹 될 수 있다.

## 자바스크립트에서 쓰레드가 없는 이유

그래서, 많은 사람들이 nodejs 코어에 새 모듈을 추가하여 스레드를 만들고 동기화 할 수 있어야 한다고 생각한다.

만약, nodejs에서 쓰레드가 추가된다면, 이는 언어의 본질을 바꿔버리는 것이다. 단순히 클래스 또는 함수 추가 만으로 쓰레드를 만들 수는 없다. 언어를 바꿀 필요가 있다. 멀티스레딩을 지원하는 언어에는 스레드간 협력이 가능하도록 `synchronized`와 같은 키워드가 있다.

예를 들어, 자바에서는 일부 숫자 유형의 경우 원자형이 아니다. 액세스를 동기화 하지 않는다면, 두개의 스레드가 변수의 값을 변경할 수 있다. 결과적으로 두개의 스레드가 변수에 액세스하고, 하나의 스레드에 의해 몇 바이트가 변경되고, 다른 스레드에 의해 몇 바이트가 변경되므로 유효한 값을 얻지 못할 것이다.

## 일단 간단한 해결책

nodejs는 이벤트 큐의 다음 코드블록을, 이전 코드블록의 실행이 완료될 때까지 평가하지 않는다. 그래서 할 수 있는 간단한 방법 중 하나는, 코드를 작은 동기식 코드로 나누고, nodejs에 이 작업이 끝났다고 전달한 이후에 큐에서 보류 중인 것들을 계속해서 실행할 수 있도록 하는 것이다.

```javascript
const arr = [
  /*겁나 큰 배열*/
]
for (const item of arr) {
  // 무거운 작업
}
// 저 포문이 끝날 때 까지 여기는 오지 못함
```

이를 작은 청크로 나눠서 실행해보자.

```javascript
const crypto = require('crypto')

const arr = new Array(200).fill('something')
function processChunk() {
  if (arr.length === 0) {
    // code that runs after the whole array is executed
    // 모든 배열이 실행이 끝난 뒤에 실행됨
  } else {
    console.log('processing chunk')
    /// 10개만 추출
    const subarr = arr.splice(0, 10)
    for (const item of subarr) {
      // 오래 걸리는 작업
      doHeavyStuff(item)
    }
    // 다음 큐로 작업을 밀어넣음
    setImmediate(processChunk)
  }
}

processChunk()

function doHeavyStuff(item) {
  crypto
    .createHmac('sha256', 'secret')
    .update(new Array(10000).fill(item).join('.'))
    .digest('hex')
}

// 다른 작업도 가능한지 확인하기 위한 함수
let interval = setInterval(() => {
  console.log('tick!')
  if (arr.length === 0) clearInterval(interval)
}, 0)
```

이제 `setImmediate(callback)`가 실행될 때마다 10개씩 작업을 처리하게 되며, 이외에 무언가 작업할게 생기게 되면 이 작업 사이에 처리하게 된다.

그러나 보다시피 코드가 더 복잡해졌다. 또한 알고리즘은 이보다 더 복잡하기 때문에 어디서 적절히 `setImmediate()`를 배치해야 할지 알 수 없다. 게다가 이제 코드는 비동기 식이며, 다른 외부 라이브러리에 의존하게 되면 실행을 더 작은 청크로 분할해서 실행하기 어려워 질 수도 있다.

## 백그라운드 프로세스

`setImmediate()`는 간단한 시나리오에서는 쓸만했지만, 아주 적당한 해결책이라 보기 어렵다.

쓰레드 없이 프로세스를 병렬로 처리하는 것이 가능할까? 그렇다. 우리에게 필요한 것은 충분한 CPU와 시간을 활용해서 결과를 애플리케이션으로 되돌 릴 수 있는 일종의 백그라운드 처리이다.

```javascript
// `script.js`를 별도의 환경에서 실행하여 메모리를 공유하지 않는다.
const service = createService('script.js')
// 여기에 데이터를 넘기고 결과를 받는다.
service.compute(data, function (err, result) {
  // 결과
})
```

사실 우리는 이미 nodejs에서 백그라운드 처리를 할 수 있다. 프로세스를 fork 하여 메시지를 전달하는 방식으로 구현이 가능하다. 메인 프로세스에서 하위 프로세스로 이벤트를 주고 받는 방식으로 통신이 가능하다.

메모리 공유는 없다. 서로 교환되는 데이터는 모두 복제된 데이터이며, 한쪽 데이터를 변경한다고 다른 쪽에 변경이 일어나지는 않는다.

그러나 이는 해결책이긴 하지만, 이상적인 해결책은 아니다. 프로세스를 만드는 것은 리소스 측면에서 많은 비용이 든다. 그리고 느리다. 프로세스가 메모리를 공유하지 않기 때문에, 많은 메모리를 사용하여 새 가상 시스템을 처음부터 실행해야 한다.

물론 동일한 포크 프로세스를 재사용할 수 있다. 그러나 포킹된 프로세스 내에서 동시에 실행되는 서로 다른 과중한 워크로드를 전송하면 두가지 문제가 발생한다.

먼저, 메인 애플리케이션은 차단하지 않을 수 도 있지만, 포크된 프로세스는 한번에 하나의 작업만 처리할 수 있다. 10초가 걸리는 작업과 1초가 걸리는 작업이 순서대로 대기하는 경우, 두번쨰 작업을 실행하기 위해 10초를 기다리는 것은 이상적이지 않다.

또 다른 문제로, 한작업이 프로세스가 중단되면 동일하나 프로세스에 전송되는 모든 작업이 완료되지 않은 채로 남아있게 된다. 이러한 문제를 해결하기 위해서는 포크가 한 개가 아니고 여러개가 있어야 한다. 그러나 각 프로세스마다 모든 가상 시스템 코드가 메모리에 중복되므로, 프로세스당 몇 MBs의 처리시간과 부팅시간을 계산해서 포크되는 프로세스의 개수를 제한해야 한다.

따라서 데이터베이스 연결과 마찬가지로, 사용할 수 있는 일종의 프로세스 풀이 필요하고, 각 프로세스마다 한번에 작업을 실행하고, 작업이 완료된 후 프로세스를 다시 사용해야 한다. 구현이 매우 복잡해보인다. [worker-farm](https://github.com/rvagg/node-worker-farm)이라는 것을 사용해보자.

```javascript
// main app
const workerFarm = require('worker-farm')
const service = workerFarm(require.resolve('./script'))

service('hello', function (err, output) {
  console.log(output)
})

// script.js
// 여기는 포크 프로세스에서 실행됨
module.exports = (input, callback) => {
  callback(null, input + ' ' + world)
}
```

## 문제 해결?

뭐, 문제는 해결되었지만 멀티스레드 솔루션보다 훨씬 더 많은 메모리를 쓰고 있다. 스레드들은 포크 프로세스에 비해 리소스 측면에서 매우 가볍다. 이러한 이유 때문에 Worker Thread가 탄생하게 되었다.

Worker Thread에는 분리된 컨텍스트가 있다. 메시지 패싱을 활용하여 메인 프로세스와 정보를 교환하기 때문에 레이스 컨디션 문제를 해결할 수 있다. 또한 이들은 같은 프로세스에 존재하기 때문에 더 적은 메모리를 쓴다.

Worker Thread와 메모리도 공유할 수 있다. 이러한 용도로 많이 사용되는 객체 `SharedArrayBuffer`를 활용하여 객체를 전달할 수 있다. 많은 양의 데이터를 활용하여 CPU 집약적인 작업을 수행할 때만 이 기능을 사용해야 한다.

## Worker Thread 예제

노드 10버전 이상을 사용하고 있다면 `worker_threads`를 쓸 수 있다. 그러나 11.7버전 이하에서는 `--experimental-worker`를 추가해야 사용이 가능하다.

한가지 명심해야할 것은, 아무리 프로세스 포킹보다 저렴하다 하더라도 너무 많이 워커를 생성하면 리소스를 많이 사용할 수도 있다는 것이다. 이 경우에는, 워커 풀응ㄹ 만들기를 권장한다. 이 워커 풀도 마찬가지로 직접 구현하는대신, 워커 풀을 구현한 다른 패키지를 npm에서 찾을 수 있다.

간단한 예제에서 시작해보자. 먼저 Worker thread를 만드는 메인 파일을 구현하고, 데이터를 넘긴다. API는 이벤트 드리븐이지만 Promise로 감싸서 워커로부터 첫번째 메시지를 받는다면 `resolve`하도록 한다.

```javascript
// index.js
const { Worker } = require('worker_threads')

function runService(workerData) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./service.js', { workerData })
    worker.on('message', resolve)
    worker.on('error', reject)
    worker.on('exit', (code) => {
      if (code !== 0) reject(new Error(`Worker stopped with exit code ${code}`))
    })
  })
}

async function run() {
  const result = await runService('world')
  console.log(result)
}

run().catch((err) => console.error(err))
```

보시다시피, 파일 이름과 데이터를 argument로 넘기는 것 만으로도 쉽게 구현이 가능하다. 이 데이터는 복제되었다. 그런 다음 메시지 이벤트를 리슨하여 Worker Thread가 메시지를 보낼 때 까지 기다린다.

```javascript
const { workerData, parentPort } = require('worker_threads')

// 여기에서 무거운 작업을 동기로 메인 스레드를 방해하지 않으면서 처리할 수 있다.
parentPort.postMessage({ hello: workerData })
```

여기서는 메인 애플리케이션이 보낸 `workerData`와 메인 애플리케이션으로 정보를 돌려보내는 방법 이 두가지가 필요하다. 작업이 끝나면 `parentPort.postMessage`를 통해서 결과를 보낼 수 있다.

이게 접누다. 이는 간단한 예제지만, 우리는 더 복잡한 것들을 할 수 있다. 예를 들어 피드백을 보내야 하는 경우, Worker thread에서 실행 상태를 나타내는 메시지를 여러개 보낼 수도 있다. 아니면 일부 결과만 보낼 수 있다. 수천개의 이미지를 처리한다고 가정해보자. 처리된 이미지별로 보낼 수 있지만, 이 모든작업이 처리될 때 까지 기다리는 것은 좋지 않다.

https://nodejs.org/docs/latest-v10.x/api/worker_threads.html

## 웹 워커?

아마도 Web Worker API에 대해 들어본 적이 있을 것이다.

- https://developer.mozilla.org/ko/docs/Web/API/Web_Workers_API
- https://caniuse.com/webworkers

이는 웹에서 지원하는 api고, 모던 브라우저에서 잘 지원되고 있다. (심지어 IE11에서도?!) API는 요구사항과 기술조건들이 제각각이지만, 브라우저 런타임에서 유사한 문제를 충분히 해결할 수 있다. 웹 애플리케이션에서 암호화, 압축/압축해제, 이미지조작, 컴퓨터 비전(얼굴인식) 등을 수행하는 하는 경우 유용하다.

## 결론

Web Worker는 Nodejs 애플리케이션에서 CPU 집약적인 작업을 할 때 유용하다. 이는 마치 공유메모리가 없는 쓰레드로, 레이스 컨디션과 같은 문제를 피할 수 있다. `worker_threads`는 nodejs 12 LTS에서 부터 정식 지원하므로, 한번 사용해봄직하다.


Page 4

JWT의 단점과 주의사항

HTTP1 vs HTTP2

자바스크립트 개발자를 위한 AST 이해하기

디렉토리에 있는 모든 이미지 최적화 하기

nodejs의 멀티쓰레딩과 worker threads