## Node.js의 모듈

아주 간단히 이야기 하자면, Node.js의 모듈이란 필요로하는 자바스크립트 파일을 의미한다. Node.js 런타임은 현재 두가지 유형의 모듈을 지원한다. 첫번째는 `CommonJS` 모듈이며, 이는 Node.js가 가장 오랫동안 지원해온 모듈 시스템이다. 이는 `*.js`나 `*.cjs`로 끝난다. 두 번째로는 요즘 자주 사용되는, ECMAScript 방식이다. 이 파일 확장자는 `*.js`나 `*.mjs`로 끝난다.

`CommonJS` 모듈은 일반적으로 웹 브라우저에서 로드되는 자바스크립트 파일과는 약간 다르다. CommonJS 자바스크립트 파일에는 다른 공통 파일을 참조하기 위해 사용할 수 있는 `require()`가 존재하고, 다른 공통파일에서 참조할 수 있도록 하는 `exports`가 존재한다. Webpack이나 Browserify와 같은 도구들은 브라우저 환경에서 CommonJS 파일을 사용할 수 있게 해준다.

CommonJS 모듈이 Nodejs 내부에서 참조되면, 파일의 내용을 즉시실행함수로 감싸 버린다. 이 방법을 통해 `exports`와 `require` 기능을 사용할 수 있게 된다. 이 래퍼는 대략 아래와 같은 모양을 띈다.

```javascript
;(function (exports, require, module, __filename, __dirname) {
  // original content here
})
```

https://www.freecodecamp.org/news/node-module-exports-explained-with-javascript-export-function-examples/

`require('module')` 함수가 알아서 필요한 모듈을 찾으려면 몇가지 단계를 통과해야 한다. 이러한 프로세스를 module resolution algorithm 이라고 한다. 이는 대략 아래와 같은 과정을 거친다.

- `module`이 `http`와 같은 nodejs 내장 모듈이라면 그것을 로드한다.
- `module`이 `/` `./` `../`로 시작하면 파일이나 디렉토리를 로드한다.
- 디렉토리라면, `package.json` 파일의 `main`필드를 보고, 그것을 로드한다.
- 디렉토리인데, `package.json`이 없다면 `index.js`를 로드한다.
- 파일인데, 확장자까지 정확이 있다면 그 파일을 로드하고, 확장자가 없다면, `.js` `.json` `.node`를 로드한다.
- `./node_modules`를 살펴본다.
- `./node_modules`디렉토리를 찾기 위해 각 상위 디렉토리를 살펴본다.

위를 간단히 표로 요약해보자.

| require                   | Module Path                                                      |
| ------------------------- | ---------------------------------------------------------------- |
| `require('path')`         | built-in _path_ module                                           |
| `require('./my-mode.js')` | `/srv/my-mod.js`                                                 |
| `require('redis')`        | `/srv/node_modules/redis/`, `/node_modules/redis/`               |
| `require('foo.js')`       | `/srv/node_modules/foo.js/`, `/node_modules/foo.js`              |
| `require('./foo')`        | `/srv/foo.js` `/srv/foo.json` `/srv/foo.nde` `/srv/foo/index.js` |

한가지 팁을 주자면, 명시적으로 파일이 필요한 경우라면 확장자까지 제공하는 것이 좋다. 확장자를 생략하면, `require`가 모호해지고, 만약 같은 파일명의 `.json` 이나 `.js`가 추가된다면 코드가 깨져버릴 수도 있다.

파일이 로드되면 `require` cache에 추가된다. key/value 쌍으로 저장되는데, 여기서 키는 확인된 모듈 파일의 이름에 대한 절대경로이고, 값은 해당 모듈의 export 객체다. 따라서 단일 인스턴스를 여러번 exports 하더라도 동일한 싱글톤 객체를 참조할 수 있게 된다.

## SemVer: 시멘틱 버저닝

`SemVer`란 packages를 릴리즈하는데 있어 일종의 규칙이라 볼 수 있다. npm을 비롯한 여러 플랫폼에서 사용되고 있다. `SemVer`의 버전 문자열은 `1.2.3`과 같이 마침표로 구분된 세개의 숫자로 이루어져 있다. 첫번째는 메이저, 두번째는 마이너, 세번째는 패치 버전이다.

각 버전은 다른 의미를 가지고 있다. 일반적으로 브레이킹 체인지가 있을 경우 (= 패키지의 작동 방식이 바뀌는 경우) 메이저 버전이 변경된다. 새로운 기능이 추가 되는 경우 마이너 버전이 증가한다. 마지막으로 버그 수정의 경우에는 패치버전이 변경된다. 숫자가 커지는 경우 오른쪽 숫자가 0으로 바뀔 수 있다. `9.0.0`이 메이저 버전업을 거치게 되면 `10.0.0`이 될 수 있는 것이다.

만약 `0.1.2` 와 같이 선행버전이 0으로 시작하는 경우, 가장 중요한 숫자는 그 다음 숫자가 된다. 즉, `0`으로 시작하는 패키지는 아직 안정적인 프로젝트는 아님을 의미한다.

![semver](https://thomashunter.name/media/2021/packages-modules/semver-ranges.png)

이 SemVer의 철학을 고수하는 것이 바로 npm 커뮤니티를 하나로 묶는 것이다. 호환성에 대한 일종의 이러한 범용적인 가정 덕분에, 애플리케이션은 특정 패키지 버전 대신 패키지의 '범위'에 자유롭게 의존활 수 있다. `package.json`에는 키와 값으로, 즉 키는 패키지 이름, 값은 패키진의 버전 범위 (또는 특정 버전)을 나타낸다.

```json
"dependencies": {
  "fastify": "^3.11.1",
  "ioredis": "~4.22.0",
  "pg": "8.5.1"
}
```

`fastify`는 `^`기호를 사용하여 버전 범위를 나타낸다. 이는 지정된 버전이 호환되는 모든 버전을 허용한다. (`3.11.1` `3.11.9` `3.19.3`은 가능하지만, `3.11.0`과 같이 이전 버전, 혹은 `4.0.1`과 같은 더 높은 메이저 버전은 허용하지 않는다.) 일반적으로 npm으로 새패키지를 설치할때 기본적으로 사용된다.

`ioredis`는 `~`를 사용한다. 이는 버그 수정 (패치 버전 업데이트)만 가능하고, 마이너버전 업데이트도 허용하지 않는다는 것을 의미한다. 이는 패키지와의 강력한 연결이 요구될 때 사용할 수 있다.

`pg`는 어떠한 기호도 사용하고 있지 않는다. 이 특정 패키지만 사용할 수 있는데 이를 패키지 버전 고정이라고도 한다.

## npm package와 `node_modules` 디렉토리

npm 패키지는 node.js 모듈및 json 파일, `README.md` 등을 포함하는 아카이브다. 공용 패키지는 `npmjs.com` 레지스트리 등에 업데이트 할 수 있으며, private 패키지는 private registry 또는 회사 소유의 레지스트리에 업로드 할 수 있다. Node.js 자체는 npm 패키지가 무엇인지 인식하지 않고, `node_modules` 디렉토리에 있는 디렉토리와 파일만 인식한다. 이러한 패키지를 추출하여 올바른 위치에 콘텐츠를 배치하는 것이 npm CLI의 몫이다.

Node.js 자체는 다른 플랫폼에서 제공하는 많은 기능이 없기 때문에, npm 패키지는 node.js 애플리케이션에 매우 중요하다고 볼 수 있다. 이는 npm 패키지 생태계가 성장할 수 있도록 장려된 의도적인 설계 철학이다.

따라서 거의 모든 node.js 애플리케이션에 dependencies, 종속성이 있다. dependencies란 애플리케이션이 의존하고 있는 npm 패키지다. 이러한 dependency는 직접적인 의존성일 수도 있고, dependency가 의존하는 또다른 하위 dependency일 수도 있다. 이는 dependency의 계층 구조를 만들어 낸다.

아래 구조를 예를 들어보자.

```bash
node_modules/
  foo/ (1.0.0)
  bar/ (2.0.0)
    node_modules/
      foo/ (1.0.0)
```

여기서 한가지 발견할 수 있는 문제는 순환 의존성이다. `foo` 패키지가 만약에 `bar`에 의존하게 되면 무한히 순환하게 되는 중첩된 폴더구조가 생겨버린다. 또, 그렇지 않더라도, `foo` 모듈이 두번 설치되어 공간을 낭비하게 된다. npm은 이를 위해 패키지를 설치 할 때 패키지를 트리 위에 올려 중복을 제거한다.

```bash
node_modules/
  foo/ (1.0.0)
  bar/ (2.0.0)
```

`bar` 패키지는 이제 `foo` 패키지를 자신의 `node_modules` 대신, 상위 폴더로 접근하여 자신과 동등한 위치에 있는 `foo`를 사용할 것이다.

더 복잡한 예를 살펴보자. 예를 들어, 서로다른 패키지는 각각 서로다른 버전의 패키지에 의존하고 있을 수 있다. npm은 각각의 패키지를 만족하는 최적의 패키지 버전을 찾아내서, 호이스팅 시켜 디스크 사용량을 줄이게 된다.

그러나 호이스팅이 불가능한 경우도 있다. 아래와 같이 다른 버전을 사용하는 경우, 각각 다른 버전의 패키지가 설치되어 버릴 수도 있다.

```bash
node_modules/
  foo/ (1.0.0)
  bar/ (2.0.0)
    node_modules/
      foo/ (2.0.0)
```

`package-lock.json` (구 `npm-shrinkwrap.json`)는, 패키지의 직접적인 의존성,그리고 일시적인 의존성도 차단하기 위해 만들어졌다. 이 파일이 없다면, 새패키지 버전이 나올때마다 디스크에 설치파는 패키지의 버전을 매번 확인해야 할 것이다.

## npm install vs npm ci

의존성을 설치하는 npm cli 명령어는 `install`과 `ci`가 있다. 한줄로 요약하자면, `package-lock.json`을 오염시키지 않기 위한 환경 (빌드, ci, 배포 등)에서는 `ci`를, 그외의 개발 과정중에서는 `install`을 사용하는 것이 좋다.

https://docs.npmjs.com/cli/v7/commands/npm-ci

`npm ci`는

- `package-lock.json` `npm-shrinkwrap.json`이 있을 경우 (패키지 버전을 다시 확인하지 않고 두 파일에 기재된 그대로 설치)
- `node_modules`가 없는 경우

에 매우 빠르게 동작한다.

따라서 ci를 사용하기 위해서는,

- `package-lock.json` `npm-shrinkwrap.json`가 반드시 존재해야 한다.(없다면 `npm install`)
- `package-lock.json`의 종속성이 `package.json`과 일치하지 않는다면, 업데이트 되는 것이 아니고 에러가 난다. (이를 해결하려면 `npm install`)
- `npm ci`는 전체 종속성을 설치할 때만 사용 `npm ci react`는 불가능
- `node_modules`가 존재한다면 `npm ci`는 해당 폴더를 삭제
- 절대로 `package.json`이나 `package-lock.json`을 수정하지 않는다.


Nodejs 모듈 (CommonJS, ECMAScript) 과 패키지, 그리고 Semver

## Table of Contents

Nodejs와 SQL을 사용하는 백엔드 환경을 구성하게 되면, ORM의 사용을 고려하게 된다. 그런데 왜 이 ORM의 사용을 자제해야할까?

글을 들어가기에 앞서 ORM 으로 만들어진 오픈소스를 디스(?)하기 위한 목적이 아닌 글을 밝힌다. 각 오픈소스는 열심히 만들어지고 있고, 많은 프로덕션 애플리케이션이 이를 기반으로 돌아가고 있으며, 나도 ORM으로 만들어진 백엔드 애플리케이션을 운영하고 있다.

## ORM

ORM (Object-relational mapping)은 객체와 데이터베이스 시스템을 연결(맵핑)해주는 라이브러리다. 세상엔 다양한 데이터 베이스 시스템이 있고 이를 다양한 방식으로 연결해야 하는데, ORM은 이렇게 둘 사이 (소스와 애플리케이션)의 연결을 도와주는 가교 역할을 한다. 따라서 많은 개발자들이 ORM과 데이터베이스의 마이그레이션을 편리하게 하기 위해 사용한다.

왜 쓰지 말아야 하는지에 대해 논의하기전에, 먼저 ORM의 장점을 살펴보자.

- 중복 코드 방지
- 다른 데이터베이스로 쉽게 교체 가능
- 여러 테이블에 쉽게 쿼리를 날릴 수 있음
- 인터페이스를 작성하는 시간을 아껴 비즈니스 로직에 집중할 수 있음

## ORM과 Nodejs: 추상화 계층 살펴보기

ORM에 깊게 들어가기에 앞서 추상화 계층 (abstraction layer)을 살펴보자. 컴퓨터의 다른 모든 것과 마찬가지로, 추상화 계층이 추가되는 것이 꼭 좋은 것 만은 아니다. 추가될 때 마다 성능이 저하되고, 이 성능을 발판삼아 개발자의 생산성을 향상시키게 된다 (물론 꼭 그런건 아니다)

### 저수준: 데이터베이스 드라이버

기본적으로 TCP 패킷을 수동으로 생성하여 데이터베이스를 전달하는 최소한의 과정을 제외한 가장 낮은 수준이다. 데이터베이스 드라이버 데이터베이스에 대한 연결 (풀링)을 처리한다. 이 레벨에서는 raw sql 쿼리를 작성하여 데이터베이스에 넘기고, 데이터베이스로 부터 응답을 받게된다. node.js의 생태계에서는 이러한 역할을 하는 많은 라이브러리가 있다.

- https://github.com/mysqljs/mysql
- https://github.com/brianc/node-postgres
- https://github.com/mapbox/node-sqlite3

각 라이브러리는 기본적으로 동일한 방식으로 동작한다. 데이터베이스 인증정보를 가져오고, 새 데이터베이스 인스턴스를 만들고, 연결하고, 문자열 형식으로 쿼리를 전송하고, 결과를 비동기적으로 처리한다.

```javascript
#!/usr/bin/env node

// $ npm install pg

const { Client } = require('pg')
const connection = require('./connection.json')
const client = new Client(connection)

client.connect()

const query = `SELECT
  ingredient.*, item.name AS item_name, item.type AS item_type
FROM
  ingredient
LEFT JOIN
  item ON item.id = ingredient.item_id
WHERE
  ingredient.dish_id = $1`

client.query(query, [1]).then((res) => {
  console.log('Ingredients:')
  for (let row of res.rows) {
    console.log(`${row.item_name}: ${row.quantity} ${row.unit}`)
  }

  client.end()
})
```

### 중간수준: 쿼리 빌더

이는 데이터베이스 드라이버 모듈을 사용하는 것과 완전한 ORM을 사용하는 것 사이의 중간 정도 수준이다. 이 정도 수준을 구현한 라이브러리는 [Knext](https://knexjs.org/)다. 이 라이브러리는 여러가지 다른 SQL 구문을 만들어낼 수 있다. Knex는 함께 사용해야 하는 다른 라이브러리를 같이 설치해줘야 한다.

Knex 인스턴스 생성시 사용하는 SQL과 함께 연결관련 정보를 넘겨서 사용할 수 있다. 작성하는 쿼리는 기본적으로 SQL 쿼리와 유사하다. 한가지 좋은 점은 문자열을 연결해서 SQL 쿼리를 만드는 것 보다는 더 편리한 방식으로 동적 쿼리를 프로그래밍 방식으로 생성할 수 있다는 것이다. (가끔 보안 취약점이 발생할 수도 있음)

```javascript
#!/usr/bin/env node

// $ npm install pg knex

const knex = require('knex')
const connection = require('./connection.json')
const client = knex({
  client: 'pg',
  connection,
})

client
  .select([
    '*',
    client.ref('item.name').as('item_name'),
    client.ref('item.type').as('item_type'),
  ])
  .from('ingredient')
  .leftJoin('item', 'item.id', 'ingredient.item_id')
  .where('dish_id', '=', 1)
  .debug()
  .then((rows) => {
    console.log('Ingredients:')
    for (let row of rows) {
      console.log(`${row.item_name}: ${row.quantity} ${row.unit}`)
    }

    client.destroy()
  })
```

### 고수준: ORM

이제 우리가 고려할 가장 높은 수준의 추상화다. 써본 사람들은 알겠지만, 일반적으로 ORM을 사용할 때는 사전에 설정을 하는데 많은 시간을 쏟아야 한다. ORM의 요점은, 이름에서 알 수 있는 것처럼 관계형 데이터 베이스의 데이터를 애플리케이션의 객체 (일반적으로 클래스 인스턴스)에 매핑하는 것이다. 따라서 애플리케이션 코드에서 이러한 객체의 구조와 관계를 정의해야 한다.

- https://github.com/sequelize/sequelize
- https://github.com/bookshelf/bookshelf
- https://github.com/balderdashy/waterline
- https://github.com/Vincit/objection.js

## Sequelize 사용해보기

가장 유명한 ORM인 `Sequelize`를 사용해보자.

```javascript
#!/usr/bin/env node

// $ npm install sequelize pg

const Sequelize = require('sequelize')
const connection = require('./connection.json')
const DISABLE_SEQUELIZE_DEFAULTS = {
  timestamps: false,
  freezeTableName: true,
}

const { DataTypes } = Sequelize
const sequelize = new Sequelize({
  database: connection.database,
  username: connection.user,
  host: connection.host,
  port: connection.port,
  password: connection.password,
  dialect: 'postgres',
  operatorsAliases: false,
})

const Dish = sequelize.define(
  'dish',
  {
    id: { type: DataTypes.INTEGER, primaryKey: true, autoIncrement: true },
    name: { type: DataTypes.STRING },
    veg: { type: DataTypes.BOOLEAN },
  },
  DISABLE_SEQUELIZE_DEFAULTS,
)

const Item = sequelize.define(
  'item',
  {
    id: { type: DataTypes.INTEGER, primaryKey: true, autoIncrement: true },
    name: { type: DataTypes.STRING },
    type: { type: DataTypes.STRING },
  },
  DISABLE_SEQUELIZE_DEFAULTS,
)

const Ingredient = sequelize.define(
  'ingredient',
  {
    dish_id: { type: DataTypes.INTEGER, primaryKey: true },
    item_id: { type: DataTypes.INTEGER, primaryKey: true },
    quantity: { type: DataTypes.FLOAT },
    unit: { type: DataTypes.STRING },
  },
  DISABLE_SEQUELIZE_DEFAULTS,
)

Item.belongsToMany(Dish, {
  through: Ingredient,
  foreignKey: 'item_id',
})

Dish.belongsToMany(Item, {
  through: Ingredient,
  foreignKey: 'dish_id',
})

Dish.findOne({ where: { id: 1 }, include: [{ model: Item }] }).then((rows) => {
  console.log('Ingredients:')
  for (let row of rows.items) {
    console.log(
      `${row.dataValues.name}: ${row.ingredient.dataValues.quantity} ` +
        row.ingredient.dataValues.unit,
    )
  }

  sequelize.close()
})
```

## 정말 ORM이 필요한가?

### 1. SQL이 아닌 ORM 자체를 배우게 된다.

많은 사람들이 SQL을 배우기 위해 ORM을 선택한다. 사람들은 SQL은 배우기 어렵고, ORM을 배우면 하나의 언어만 사용하여 애플리케이션을 작성할 수 있다는 믿음을 갖곤 한다. 언뜻 보기에 이는 맞는 것 같다. 그러나 ORM은 애플리케이션의 나머지 언어와 동일하게 작성되지만, SQL은 완전히 다른 문법을 가진 언어다.

이러한 사고방식에는 문제가 있다. ORM은 꽤 복잡한 라이브러리중 하나다. ORM을 사용하기 위해서 배워야할 것은 많으며, 이를 배우는 것은 결코 쉬운일이 아니다.

그리고 특정 ORM에 익숙해져버리면, 다른 ORM 사용을 원활하게 하지 못할 수도 있다. 이는 마치 JS/Node.js에서 C#/.NET 환경으로 오는 것과 유사한 기분이 들 수 있다.

#### Sequelize

```javascript
#!/usr/bin/env node

// $ npm install sequelize pg

const Sequelize = require('sequelize')
const { Op, DataTypes } = Sequelize
const connection = require('./connection.json')
const DISABLE_SEQUELIZE_DEFAULTS = {
  timestamps: false,
  freezeTableName: true,
}

const sequelize = new Sequelize({
  database: connection.database,
  username: connection.user,
  host: connection.host,
  port: connection.port,
  password: connection.password,
  dialect: 'postgres',
  operatorsAliases: false,
})

const Item = sequelize.define(
  'item',
  {
    id: { type: DataTypes.INTEGER, primaryKey: true, autoIncrement: true },
    name: { type: DataTypes.STRING },
    type: { type: DataTypes.STRING },
  },
  DISABLE_SEQUELIZE_DEFAULTS,
)

// SELECT "id", "name", "type" FROM "item" AS "item"
//     WHERE "item"."type" = 'veg';
Item.findAll({ where: { type: 'veg' } }).then((rows) => {
  console.log('Veggies:')
  for (let row of rows) {
    console.log(`${row.dataValues.id}t${row.dataValues.name}`)
  }
  sequelize.close()
})
```

#### Bookshelf

```javascript
#!/usr/bin/env node

// $ npm install bookshelf knex pg

const connection = require('./connection.json')
const knex = require('knex')({
  client: 'pg',
  connection,
  // debug: true
})
const bookshelf = require('bookshelf')(knex)

const Item = bookshelf.Model.extend({
  tableName: 'item',
})

// select "item".* from "item" where "type" = ?
Item.where('type', 'veg')
  .fetchAll()
  .then((result) => {
    console.log('Veggies:')
    for (let row of result.models) {
      console.log(`${row.attributes.id}t${row.attributes.name}`)
    }
    knex.destroy()
  })
```

#### Waterline

```javascript
#!/usr/bin/env node

// $ npm install sails-postgresql waterline

const pgAdapter = require('sails-postgresql')
const Waterline = require('waterline')
const waterline = new Waterline()
const connection = require('./connection.json')

const itemCollection = Waterline.Collection.extend({
  identity: 'item',
  datastore: 'default',
  primaryKey: 'id',
  attributes: {
    id: { type: 'number', autoMigrations: { autoIncrement: true } },
    name: { type: 'string', required: true },
    type: { type: 'string', required: true },
  },
})

waterline.registerModel(itemCollection)

const config = {
  adapters: {
    pg: pgAdapter,
  },

  datastores: {
    default: {
      adapter: 'pg',
      host: connection.host,
      port: connection.port,
      database: connection.database,
      user: connection.user,
      password: connection.password,
    },
  },
}

waterline.initialize(config, (err, ontology) => {
  const Item = ontology.collections.item
  // select "id", "name", "type" from "public"."item"
  //     where "type" = $1 limit 9007199254740991
  Item.find({ type: 'veg' }).then((rows) => {
    console.log('Veggies:')
    for (let row of rows) {
      console.log(`${row.id}t${row.name}`)
    }
    Waterline.stop(waterline, () => {})
  })
})
```

#### Objection

```javascript
#!/usr/bin/env node

// $ npm install knex objection pg

const connection = require('./connection.json')
const knex = require('knex')({
  client: 'pg',
  connection,
  // debug: true
})
const { Model } = require('objection')

Model.knex(knex)

class Item extends Model {
  static get tableName() {
    return 'item'
  }
}

// select "item".* from "item" where "type" = ?
Item.query()
  .where('type', '=', 'veg')
  .then((rows) => {
    for (let row of rows) {
      console.log(`${row.id}t${row.name}`)
    }
    knex.destroy()
  })
```

단순한 읽기 작업이지만, 예제 사이에 많은 차이가 존재하는 것을 볼 수있다. 이는 여러 테이블을 조인하게 되면 작업이 복잡해지면서 ORM 구문이 더 복잡하고 달라질 수 있다. Node.js에는 수많은 ORM이 있고, 또 모든 플랫폼에 대해 수백개의 ORM이 존재한다. 이를 다 배운다는 것은 악몽과도 같다.

그러나 SQL 구문을 배운다면 이런걱정을 할 필요가 없다. SQL을 사용하여 쿼리를 생성하는 방법을 배우게 되면, 이 하나의 지식을 여러 플랫폼 사이에서 공유할 수 있다.

### 2. 복잡한 ORM 호출은 비효율적일 수 있다.

ORM의 본래 목적은 데이터베이스에 저장된 기본 데이터를, 특정 애플리케이션 내에서 상호작용할 수 있는 객체에 매핑하는 것이다. 따라서 ORM을 사용하여 데이터를 가져올 때 몇가지 비효율성이 발생하게 된다.

아래 추상화 레벨별 예제를 살펴보자.

#### `pg` 드라이버 사용

이 방법에서는 쿼리를 직접 손으로 쓰면 된다. 이는 우리가 원하는 데이터를 얻을 수 있는 가장 간결한 방법이다.

```sql
SELECT
  ingredient.*, item.name AS item_name, item.type AS item_type
FROM
  ingredient
LEFT JOIN
  item ON item.id = ingredient.item_id
WHERE
ingredient.dish_id = ?;
```

이 쿼리를 `EXPLAIN`으로 살펴보면, `34.12`의 비용이 나온다.

#### `knex` 쿼리 빌더 사용시

```sql
select
  *, "item"."name" as "item_name", "item"."type" as "item_type"
from
  "ingredient"
left join
  "item" on "item"."id" = "ingredient"."item_id"
where
"dish_id" = ?;
```

앞선 예와 마찬가지로 일부 사소한 형식 `"`과 불필요한 몇가지를 제외하면 동일하다. 마찬가지의 비용인 `34.12`가 나온다.

#### Sequelize ORM

이제 ORM으로 생성한 쿼리를 살펴보자.

```sql
SELECT
  "dish"."id", "dish"."name", "dish"."veg", "items"."id" AS "items.id",
  "items"."name" AS "items.name", "items"."type" AS "items.type",
  "items->ingredient"."dish_id" AS "items.ingredient.dish_id",
  "items->ingredient"."item_id" AS "items.ingredient.item_id",
  "items->ingredient"."quantity" AS "items.ingredient.quantity",
  "items->ingredient"."unit" AS "items.ingredient.unit"
FROM
  "dish" AS "dish"
LEFT OUTER JOIN (
  "ingredient" AS "items->ingredient"
  INNER JOIN
  "item" AS "items" ON "items"."id" = "items->ingredient"."item_id"
) ON "dish"."id" = "items->ingredient"."dish_id"
WHERE
"dish"."id" = ?;
```

이 쿼리는 앞선 쿼리와는 많이 다르다. 앞서 정의한 `관계` 때문에, Sequelize는 요청한 것보다 더 많은 정보를 얻으려고 한다. 이 쿼리의 비용은 `42.32`다.

### 3. ORM이 만능은 아니다.

일부 쿼리는 ORM 작업으로 표현할 수 없다. 이러한 쿼리를 생성하는 경우에는 SQL 쿼리를 직접생성하는 작업으로 회귀해야 한다. 이는 ORM을 사용하는 와중에도 코드베이스에 여전히 하드 코딩된 쿼리가 존재할 수 있다는 것을 의미한다. 이러한 프로젝트를 개발하는 개발자는 ORM이나 SQL구문 모두를 알아야 한다.

ORM으로 표현할 수 없는 쿼리에는 쿼리에 서브쿼리가 포함된 경우다.

```sql
SELECT *
FROM item
WHERE
  id NOT IN
    (SELECT item_id FROM ingredient WHERE dish_id = 2)
  AND id IN
(SELECT item_id FROM ingredient WHERE dish_id = 1);
```

내가 아는한, 이 쿼리는 앞서 언급한 ORM을 사용하여 명확하게 나타낼 수 없다. 이러한 상황에 대처하기 위해, ORM에서는 쿼리인터페이스에 로우 쿼리 문자열을 주입하는 기능을 제공하는 것이 일반적이다.

Sequelize의 경우에는 로우 쿼리문을 실행하는 `.query()`메소드를 제공한다. Bookshelf와 Objection ORM을 사용하면, 로우 knex 객체에 엑세스할 수 있다. Knex 객채에는 로우 쿼리를 실행하는 `.raw()` 메소드도 있다. 어쨌건 간에, 여전히 특정 쿼리를 사용하기 위해서는 SQL을 이해해야한다.

## 쿼리 빌더를 사용하자.

저수준 데이터베이스 드라이버 모듈을 사용하는 것은 매력적이다. 쿼리를 손수 작성하므로, 데이터베이스에 쿼리를 생성할 때 오버헤드를 일으키지 않는다. 또한 프로젝트에 의존하는 전반적인 의존성도 최소화 할 수 있다. 그러나 동적쿼리를 생성하는 작업이 매우 귀찮을 수 있다.

사용자가 특정 기준에 따라 데이터를 가져오는 예제를 상상해보자.

```sql
SELECT * FROM things WHERE color = ?;
```

그러나 옵션이 다양해지면 아래와 같이 복잡해진다.

```sql
SELECT * FROM things; -- Neither
SELECT * FROM things WHERE color = ?; -- Color only
SELECT * FROM things WHERE is_heavy = ?; -- Is Heavy only
SELECT * FROM things WHERE color = ? AND is_heavy = ?; -- Both
```

매우 복잡해졌다. 그러나 앞선 이유로 인해 우리는 ORM을 사용하지 않을 것이다. 그렇다면?

쿼리 빌더가 매우 유용하게 쓰일 수 있다. knex에서 제공하는 인터페이스는 기본 SQL 쿼리와 매우 유사하므로, SQL 쿼리에 대해서 잘 이해해야 한다. 이는 typescript가 javascript로 변환되는 것과 유사하다.

SQL에 대해서 완전히 이해했다면, 쿼리빌더를 사용하는 것이 가장 좋은 해결책이다. 절대로 하위 계층에서 발생하는 일을 외면하기 위한 도구로 사용하지 말자. 편의상의 이유로만 사용해야 하며, 반드시 무슨일이 벌어지고 있는지 이해해야 한다. `Knex()`에 debug옵션을 추가하면 쿼리가 어떻게 생성되는지 알 수 있다.

```javascript
const knex = require('knex')({
  client: 'pg',
  connection,
  debug: true, // Enable Query Debugging
})
```

> ORM의 존재에 대한 갑론을박이 이렇게 뜨거운줄은 몰랐다. 엔터프아리즈급 백엔드를 많이 작성해본 경험이 없어서 이게 정답이다라고 뚜렷하게 이야기할 수는 없지만, 이런저런 측면에서 고민해볼만한 주제인 것 같긴 하다. 그러나 한가지 공통된 의견은, SQL을 꼭 배워야 한다는 것. 프론드엔드 개발자 또한 마찬가지로.

- https://blog.logrocket.com/why-you-should-avoid-orms-with-examples-in-node-js-e0baab73fa5/comment-page-1/#comments
- https://martinfowler.com/bliki/OrmHate.html
- https://enterprisecraftsmanship.com/posts/do-you-need-an-orm/
- https://medium.com/@mithunsasidharan/should-i-or-should-i-not-use-orm-4c3742a639ce
- https://hackernoon.com/you-dont-need-an-orm-7ef83bd1b37d


왜 Nodejs ORM을 쓰지 말아야 할까

자바스크립트 프로젝트를 개발하다보면, 배열을 하나의 객체로 묶어야될 필요성이 생길 때가 있다. 아래 예제를 들어보자.

```javascript
const items = [
  { name: 'obama', age: 10, country: 'USA' },
  { name: 'trump', age: 14, country: 'USA' },
  { name: 'moon', age: 37, country: 'KOREA' },
  { name: 'clinton', age: 64, country: 'USA' },
  { name: 'bush', age: 49, country: 'USA' },
]
```

이렇게 배열로 되어있는 것을 이름을 키로 하는 객체로 바꾼다고 한다면, 아마 다들 [reduce](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce)를 생각할 것이다.

```javascript
const result = items.reduce((prev, item) => {
  prev[item.name] = { age: item.age, country: item.country }
  return prev
}, {})

// {
//   obama: { age: 10, country: 'USA' },
//   trump: { age: 14, country: 'USA' },
//   moon: { age: 37, country: 'KOREA' },
//   clinton: { age: 64, country: 'USA' },
//   bush: { age: 49, country: 'USA' }
// }
```

혹은 for loop를 활용하여 똑같이 할 수 있다.

```javascript
const result2 = {}
for (let item of items) {
  result2[item] = { age: item.age, country: item.country }
}
```

둘 중에 뭐가 더 읽기 좋은 코드냐고 묻는다면, 당연히 후자일 것이다. 내가 아무리 `reduce`를 좋아한다고 해도 그건 반박 불가능한 사실이다. 그러나 요즘 리액트 커뮤니티의 성장으로 인해 함수형 프로그래밍 스타일로 코드를 작성하는 일이 잦아짐에 따라서 reduce를 쓰는일이 많아지고 있다.

그러나 문제는 아래의 스타일이다.

```javascript
const result3 = items.reduce(
  (prev, item) => ({
    ...prev,
    [item.name]: { age: item.age, country: item.country },
  }),
  {},
)
```

> 이제부터 이런 코드를 `reduce...spread`라고 부르겠다.

이 spread operator는 [Object.assign](https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Object/assign)과 유사하게 동작하는데, 소스 객체의 속성을 순환하면서 각 속성을 타켓의 객체에 하나씩 복사해 넣는다. 위 코드의 경우에는, 새로운 객체를 계속해서 복사하는 것이다. 위 코드의 문제는 무엇일까?

위코드의 동작을 살펴본다면, 대충 아래와 같을 것이다.

```bash
# 첫번째
result = {}

{...result, 'obama': {age: 10, country: 'USA'}}

# 두번째
result = {'obama': {age: 10, country: 'USA'}}

{...result, 'trump': {age: 14, country: 'USA'}}

# 세번째

result = {'obama': {age: 10, country: 'USA'}, 'trump': {age: 14, country: 'USA'}}

{...result, 'moon': {age: 37, country: 'KOREA'}}

##....
```

> 의사 코드이기 때문에 대충 보면 된다.

루프가 반복될때마다, 모든 루프에서 정확히 n회 실행되는 것은 아니지만, 이렇게 될 경우 $$O(n^2)$$라 볼 수 있다.

바벨이나 타입스크립트 트랜스파일러를 사용하면 해당 코드를 어떻게 변환할까?

그전에 먼저, [tc39에 나와있는 객체 전개 연산자의 스펙](https://github.com/tc39/proposal-object-rest-spread/blob/master/Spread.md)을 살펴보자.

```javascript
let aClone = { ...a }
let aClone = Object.assign({}, a)
```

위 구문도 거의 동일한 작업을 수행하므로, 전개 연산자와 비슷한 시간 복잡성을 가질 것이다. 즉, 새 객체를 생성한다음, 나머지 객체의 키를 새객체에 반복해서 복사하는 것이다.

- [babel transpile](https://babeljs.io/repl#?browsers=defaults%2C%20not%20ie%2011%2C%20not%20ie_mob%2011&build=&builtIns=false&corejs=false&spec=true&loose=true&code_lz=MYewdgzgLgBAllApgWwjAvDA2gKBjAbzAENlEAuGAchACNTiqAaGYgcwpgEYAGF0AK5goAJwCelKgFUAygEEqAXyZ5CJMpNEDkAB2asOlLgBZ-IIaInVZC5aqKlOVZCHD72nAMwB2MxfGSANIA8gBKAKK2KvgOGtTAADZwwm4sHpQAbKYwgsIB1vJKLPbqTrQCEAAW7oYwxgCcfnlW0oXKMDgAujg4oJCwIogQAglQnhjwSKgAdIMAJgLAiAAUyzqDAG4sCCgAlBgAfDDLBKrT5-uIW9g7yNOlnZQE6ZMo0x5NlpS307mWijhFLsWAQgUA&debug=false&forceAllTransforms=true&shippedProposals=false&circleciRepo=&evaluate=true&fileSize=false&timeTravel=false&sourceType=script&lineWrap=true&presets=env%2Creact&prettier=false&targets=&version=7.14.3&externalPlugins=)
- [typescript](https://www.typescriptlang.org/play?#code/MYewdgzgLgBAllApgWwjAvDA2gWAFAwwDeYAhsogFwwDkIARuaTQDQykDmVMAjAAxtQAVzBQATgE9qNAKoBlAII0Avi3yES5bjXFDkAB1bsu1HgBZBIEeKm15S1euJkK05CHBHO3AMwB2S2tJaQBpAHkAJQBRBzUCZy1pYAAbOFFPNm9qADYLGGFRYLtFFTYnTVdaeiEIAAsvExgzAE5AwttZEtUYfABdfHxQSFgxRAghZKgfDHgkVAA6UYATIWBEAAp1-VGANzYEFABKDAA+GHWiJ3nr7cQ97APkeZdEXuoiLNmUee82m2pHvMCjZlPhlIc2ERwUA)

따라서 reduce에서 전개연산자로 합성해서 리턴하는 것은 굉장히 느린 코드라고 볼 수 있다.

여담으로, 이와 관련된 키보드 배틀(?) 이 트위터에서 열린 적이 있다.

https://twitter.com/fildon_dev/status/1396252890721918979

## 문제의 코드

```javascript
const users = [
  { id: 1, name: 'Tony Stark', active: false },
  { id: 2, name: 'Bruce Banner', active: true },
  { id: 3, name: 'Natasha Romanoff', active: false },
  { id: 4, name: 'Chris Evans', active: true },
  { id: 5, name: 'Chris Hemsworth', active: false },
  { id: 6, name: 'Clark Gregg', active: false },
]

// good?
const result1 = users.reduce((acc, curr) => {
  if (curr.active) {
    return acc
  }
  return { ...acc, [curr.id]: curr.name }
})

// bad?
const result2 = users
  .filter((user) => !user.active)
  .map((user = (user) => ({ [user.id]: user.name })))
  .reduce(Object.assign, {})
```

그래서 뭐가 더 성능이 좋고 빠를까? 저 두개가 최선의 방법일까? 만약에 나라면,,,

🤔


솔직히 뭔가 멋있어서 많이 쓰긴 함

reduce에 spread 를 쓰면 안되는 이유

작년 10월 쯤에 nextjs 10을 적용해보고 릴리즈 노트를 살펴보았는데, 어느덧 nextjs 11까지 나오게 되었다. 8개월 만에 메이저 버전을 업데이트 했는데, 정말 놀랍다. 반년 남짓한 사이에 또 발전을 만들어 냈는데 대단하다는 생각이 드는 한편으로 많이 자극도 되었다. 11 버전에서는 어떤 것들이 달라졌는지 살펴보자.

https://nextjs.org/blog/next-11

## Table of Contents

## CHANGELOG

### [Conformance](http://web.dev/conformance)

Conformance (한글로는 일치,부합,적합성이라고 하는데 딱히 뭐라고 번역해야 할지 모르겠다. 그냥 Conformance라 부르겠다.) 는 최적의 로딩 및 Core web vital을 지원하기 위해 만들어진 시스템으로, 보안 및 접근성과 같은 여러 품질 측면의 다양한 리소스를 지원하기 위한 기능이 제공된다. 이를 활용하면, 최적의 성능을 내기 위한 다양한 규칙들을 개발자들이 외우고 다닐 필요가 없이, 적합한 옵션을 선택할 수 있다.

또한 이번에 [eslint-config-next](https://github.com/vercel/next.js/tree/canary/packages/eslint-config-next)도 제공하면서, 개발 중에 생기는 프레임워크 관련 문제를 더 쉽게 파악할 수 있고, 개발 시에도 베스트 프랙티스를 보장할 수 있는 여러가지 가이드라인을 제공하게 되었다.

```bash
» npx next lint
info  - Loaded env from /Users/yceffort/private/yceffort-blog-v2/.env
info  - Using webpack 5. Reason: Enabled by default https://nextjs.org/docs/messages/webpack5
✔ No ESLint warnings or errors
```

뭐 근데, 사실 살펴보니까 대단한 룰들이 있지는 않았다.

https://github.com/vercel/next.js/blob/afa86cc5bbd488d123e2c5888205a40a5a0afe42/packages/eslint-config-next/index.js#L16-L27

```json
{
  "rules": {
    "import/no-anonymous-default-export": "warn",
    "react/react-in-jsx-scope": "off",
    "react/prop-types": "off",
    "jsx-a11y/alt-text": [
      "warn",
      {
        "elements": ["img"],
        "img": ["Image"]
      }
    ]
  }
}
```

하지만 주목할 만한 것은 `eslint-config-next`보다 `eslint-plugin-next` 였다.

https://github.com/vercel/next.js/tree/canary/packages/eslint-plugin-next/lib/rules

여기에 있는 룰들을 간단히 요약해보았다.

- `google-font-display`: 구글 폰트에 `font-display` 속성이 적절히 되어 있는지 여부
- `google-font-preconnect`: 구글 폰트에 `preconnect`가 사용되고 있는지 여부 (rel 속성)
- `link-passhref`: [next/link](https://nextjs.org/docs/tag/v9.5.2/api-reference/next/link#if-the-child-is-a-custom-component-that-wraps-an-a-tag)의 하위 컴포넌트가 커스텀으로 있다면 `passhref`를 넘겨주었는지 여부
- `no-css-tags`: html link 엘리먼트가 외부 스타일 시트를 불러오는 경우 (웹 페이지의 css 성능에 악영향)
- `no-document-import-in-page`: `next/document`가 `pages/_document.*sx`외부에서 사용되는 경우
- `no-head-import-in-document`: `pages/_document.*sx` 내부에 `next/head`를 쓰는 경우
- `no-html-link-for-pages`: `pages` 디렉토리가 없는 경우
- `no-img-element`: `<img/>` 대신 `<next/image>`를 쓰세여. `next/image`가 더 좋다. https://nextjs.org/docs/api-reference/next/image
- `no-page-custom-font`: custom font는 `pages/_document.*sx`에서 불러오세여
- `no-sync-script`: 외부 스크립트를 sync로 불러오지 말것
- `no-title-in-document-head`: `next/document`에 `<Head>`에 `<title>`에 있으면 안된다.
- `no-unwanted-polyfills`: next에서 이미 기본으로 제공하는 폴리필을 중복으로 불러오지 말것

대부분이 next와 관련된 룰이었지만, 이번에 구글과 함께 Conformance를 적용하면서 Core web vital을 많이 신경을 쓰기 시작한 것 같다. vercel에도 이와 관련한 기능이 있기도 하고.

![partner drive process](https://web-dev.imgix.net/image/0SXGYLkliuPQY3aSy3zWvdv7RqG2/QFTQX7npdBsFheXIqbuc.png?auto=format&w=845)

이전까지는 구글이 개발자들에게 제발좀 Core web vital을 지키세여!!! 라고 외치는 전략이었다면, 이번에는 영리하게도 프레임워크를 만들고 있는 파트너 (리액트, 뷰, 타입스크립트, 바벨 등)을 공략하여 이러한 프레임워크를 쓰고 있는 개발자라면 자연스럽게 Core Web Vital을 챙길 수 있게 끔 하는 전략으로 바꾼 것으로 보인다.

사실 잘 돌아가고 있는 앱에 (사실 그렇게 보이는 앱을..) 성능이 중요하다, core web vital이 중요하다, 라고 백날 이야기 해봐야 이를 챙기는 프론트엔드 개발자가 몇이나 있을까? 그래서 제발 좀 이를 지켜주세요!! 라고 하는 것보다는, 프레임워크 레벨에서 아예 이를 세트로 묶어서 공략한다면 번거롭게 추가로 무언가를 한다는 거부감을 줄일 수 있을 것 같다.

그리고 전체적인 프론트엔드 애플리케이션의 품질이 좋아지면, 구글의 웹페이지 정보 수집에도 많은 발전이 있을 것으로 보인다. 구글의 이러한 전략에 대한 내용은 https://web.dev/introducing-aurora/ 에 있는데, 나중에 나도 한번 다뤄봐야겠다.

### 성능 향상

개발자들의 개발 경험을 향상 시키기 위해, 10.1, 10.2 에서는 시작시간을 최대 24% 단축했고, React fast refresh를 활용해 개발시 업데이트 반영시간을 40%까지 단축했다. 그리고 이번 11에서는 시간을 더 줄이기 위해 babel에 추가적인 최적화가 포함되었다. 개발자들에게 느껴지는 직접적인 코드의 변화는 없지만, 개발 환경에서 더 빠른 환경을 제공할 수 있게 되었다.

### 스크립트 최적화

[next/script](https://nextjs.org/docs/basic-features/script)가 탄생했다. 써드파티 스크립트를 로딩할 때 시간과 성능을 개선할 수 있도록 도와준다.

```jsx
function Home() {
  return (
    <>
      <Script src="https://www.google-analytics.com/analytics.js" />
    </>
  )
}
```

이 `<Script>`는 `strategy` 속성있고, 다음의 값을 가질 수 있다.

- `beforeInteractive`: 페이지가 활성화되기전에 (번들된 자바스크립트가 실행되기전에) 스크립트를 가져오고 실행한다. 스크립트가 SSR된 html내부에 주입된다.
- `afterInteractive`: 페이지가 활성화 된 이후 (번들된 자바스브립트가 모두 실행되고) 스크립트를 가져오고 실행한다. 스크립트를 hydration과정에서 주입하고, 이 후 즉시 실행된다.
- `lazyOnload`: `onload` 시점에 스크립트를 실행한다. `requestIdleCallback`을 활용하여 idle 상태가 되면 바로 실행한다.

```jsx
<Script
  src="https://polyfill.io/v3/polyfill.min.js?features=Array.prototype.map"
  strategy="beforeInteractive" // lazyOnload, afterInteractive
/>
```

`onLoad` 속성도 생겼다.

```jsx
<Script
  src={url} // consent mangagement
  strategy="beforeInteractive"
  onLoad={() => {
    // 로딩이 끝나면 그 이후에 실행됨. 그 이후에 스크립트를 로딩하거나 할 수 있음.
  }}
/>
```

또한 기본 script 로딩을 `async`에서 `defer`로 변경했다. `defer`가 더 좋은 이유, 이러한 변경을 하게된 계기는 아래 링크를 참조하자.

- https://yceffort.kr/2020/10/defer-than-async
- https://github.com/vercel/next.js/discussions/24938
- https://docs.google.com/document/u/0/d/1ZEi-XXhpajrnq8oqs5SiW-CXR3jMc20jWIzN5QRy1QA/mobilebasic#

### 이미지 최적화

[Cumulative Layout Shift](https://vercel.com/blog/core-web-vitals#cumulative-layout-shift)란 이미지 로딩으로 인해 사이트의 레이아웃이 갑자기 밀리거나 변하는 현상을 의미한다. `next/image`가 이 현상을 개선했다고 한다.

- 로컬이미지에 대한 사이즈 감지: `src`에 들어가 있는 로컬 이미지에 대해 너비와 높이를 자동으로 정의 한다고 한다.

```jsx
import Image from 'next/image'
import author from '../public/me.png'

export default function Home() {
  return (
    // 로컬 이미지를 불러오면, 알아서 width height를 계산한다.
    <Image src={author} alt="Picture of the author" />
  )
}
```

- 이미지 placeholder: 이미지가 완전히 로딩 되기전에 자동으로 블러된 이미지를 보여주는 placeholder를 지원한다.

지금 내 블로그의 헤더이미지, 프로필이미지, about 이미지 등에 적용되어 있다. (본문 이미지는 mdx로 되어있어서 적용되어있지 않다.)

```javascript
<Image src={author} alt="Picture of the author" placeholder="blur" />
```

또는 `blurDataURL`을 직접 넣어서 구현가능하다.

```jsx
<Image
  src="https://nextjs.org/static/images/learn.png"
  blurDataURL="data:image/jpeg;base64,/9j/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAAIAAoDASIAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAb/xAAhEAACAQMDBQAAAAAAAAAAAAABAgMABAUGIWEREiMxUf/EABUBAQEAAAAAAAAAAAAAAAAAAAMF/8QAGhEAAgIDAAAAAAAAAAAAAAAAAAECEgMRkf/aAAwDAQACEQMRAD8AltJagyeH0AthI5xdrLcNM91BF5pX2HaH9bcfaSXWGaRmknyJckliyjqTzSlT54b6bk+h0R//2Q=="
  alt="Picture of the author"
  placeholder="blur"
/>
```

### Webpack 5

nextjs에 webpack5가 이제 기본으로 지원된다. 이로 인한 이점은 [여기](https://nextjs.org/blog/next-10-2#webpack-5)에 나와 있다. 만약 webpack 5 미만 버전으로 custom 옵션을 사용하고 있다면, [여기](https://nextjs.org/docs/messages/webpack5)에서 마이그레이션을 할 수 있다.

### create-react-app migration

[@next/codemod](https://nextjs.org/docs/advanced-features/codemods)는, nextjs에서 deprecated된 기능을 자동으로 변환해주는 도구다. 여기에는 `/pages` 디렉토리를 생성하고, css를 적절한 위치로 import 하는 등의 옵션이 포함되어 있다. 여기에 cra로 생성된 앱을 점진적으로 nextjs로 바꿔주는 기능이 추가되었다.

```bash
npx @next/codemod cra-to-next
```

아직은 실험단계라고 한다.

### Next.js Live

https://nextjs.org/live 는, next를 활용한 전체 개발 프로세스를 웹 브라우저에서 할 수 있도록 도와주는 애플리케이션이다. 빌드단계를 생략하고 URL로 즉시 개발이 가능해지고, 공동작업도 가능하다고 한다. 아직 early access 단계라서 직접 사용해보지는 못했지만,

![nextjs.live](https://nextjs.org/_next/image?url=%2F_next%2Fstatic%2Fimage%2Fpublic%2Fstatic%2Flive%2Fbrowser.f5aa736f88c19b45aa423f7b1c0ca58f.png&w=3840&q=75)

모습을 보아하니, nextjs 애플리케이션을 stackblitz 처럼 웹에서 실시간으로 개발할 수 있게 해주고, 거기에 다른 디자이너나 기획자들이 협업할 수 있도록 도와주는 도구 인 것 같다.

이를 위해 서비스워커, 웹어셈플리, ESModule, [sucrase](https://github.com/alangpierce/sucrase), Tailwind JIT 등의 최신 기술을 집약했다고 한다.

### React 버전

최소 리액트 버전이 17.0.2로 업데이트 되었다고 한다.

### Upgrade guide

https://github.com/vercel/next.js/blob/canary/docs/upgrading.md

## 블로그 적용 후기

일단 새롭게 추가된 `<next/script>`, `<next/image>`의 blur를 위주로 적용했다. 개발 속도에서의 개선은 체감상 크게 못느꼈지만 (상대적으로 무겁지 않은 애플리케이션이라 더더욱), `Script` `blur` 등의 기능은 유용하게 쓸 수 있었다. 그리고 Conformance를 읽으면서 블로그의 라이트 하우스에 소홀했었다는 점을 떠올리며 점수를 끌어올렸다.

### before

![before](./images/before-blog.png)

### after

![after](./images/after-blog.png)

> 이정도면 꽤 만족스럽게 끌어올렸다. 당분간은 라이트 하우스를 쳐다보지 않아도 될 것 같다.

nextjs가 이렇게 훌륭한 프레임워크를 제공해주어서 좋을 따름이지만, 그 뒤에 숨겨져 있는, 프론트엔드 개발에 필요한 많은 요소들을 놓치거나 혹은 이것들을 상대적으로 덜 중요한 것으로 생각하는 경우도 종종 보게 된다. 어떻게든 좋은 애플리케이션을 만들면 되는 것은 회사와 블로그에서는 중요한 것일 수도 있지만, 그 뒤에 `babel`, `webpack`, `eslint` 가 어떻게 동작하고 있는지, `blur`처리는 어떻게 자동으로 되고 있는지, `Script`의 각 값별로 어떤식으로 동작하는 지 등을 이해하는 것은 개발자로서 성장하는데 있어 정말 중요한 일이다. 무지성 버전업, 이후 documentation 감상 후 적용 또한 좋은 일이지만, 이 뒤에서 무엇이 일어나고 있는지, 오픈소스 컨트리뷰터 들이 어떠한 고민을 하고 있는지도 뒤늦게나마 함께 공부해본다면 분명 유의미한 일이 될 것이다.


Nextjs 11 릴리즈 노트 살펴보고 블로그에 적용하기

ECMAScript (ES2015, ES) 모듈이란 자바스크립트에서 각 코드를 하나의 청크로 구성할 수 있게 해주는 방법을 제공한다. 먼저, 자바스크립트의 값을 외부로 노출을 시킨다.

```javascript
export const sum = (a, b) => a + b
```

그리고 이 값(함수)을 필요로 하는 곳에서 아래와 같이 사용한다.

```javascript
import { sum } from './test'

sum(1, 2)
```

대부분의 경우에는 위의 예제 처럼 상단에 필요한 모듈들을 static하게 import하는 것이 일반적이지만, 때때로 이를 필요에 따라 조건부로 불러올 수도 있다. [dynamic import](https://caniuse.com/?search=dynamic%20import)라고 불리며, 이는 ES2020(ES11)에 포함된 기능이다.

```javascript
const sum = await import('./test')
```

`await import`는 프로미스를 리턴하고 이 때부터 동적으로 모듈을 불러오기 시작한다. 그리고 모듈을 성공적으로 불러오면, promise는 모듈을 resolve하거나 실패할 경우 reject 하게 된다.

그리고 `import`내의 구문은 모듈의 위치를 가리키는 string이면 되기 때문에, 함수 외부에서 인수로 받거나 계산된 string을 받는 것들도 가능하다.

```javascript
export const sum = (a, b) => a + b
```

```javascript
async function calc(a, b) {
  const { sum } = await import('./test')
  sum(a, b)
}

calc(1, 2) // 3
```

이제 default 의 경우를 살펴보자.

```javascript
const sum = (a, b) = > a + b
export default sum
```

이 경우에는 `default` 키워드를 사용하면 된다.

```javascript
async function calc() {
  const { default: sum } = await import('./test')
  sum(1, 2)
}
```

한가지 유의 할 것은,

```javascript
const sum = await import('./test')
```

이렇게는 안된다는 것이다.

default와 그 외의 것들이 섞여있는 경우라면 아래와 같이 처리하면 된다.

```javascript
const sum = (a, b) => a + b
export const sum1 = (a, b) => a + b
export const sum2 = (a, b) => a + b

export default sum
```

```javascript
const { default: sum, sum1, sum2 } = await import('./test')
```


Javascript 12

Nodejs 모듈 (CommonJS, ECMAScript) 과 패키지, 그리고 Semver

왜 Nodejs ORM을 쓰지 말아야 할까

reduce에 spread 를 쓰면 안되는 이유

Nextjs 11 릴리즈 노트 살펴보고 블로그에 적용하기

ESModule을 동적으로 import 하기