## Table of Contents

## Web Assembly란 무엇인가?

웹 어셈블리는 최신 웹 브라우저에서 자바스크립트 코드 외에 실행할 수 있는 새로운 유형의 코드를 의미한다. 웹에서 실행될 수 있는 코드는 자바스크립트 밖에 없지만, 웹 어셈블리를 활용하면 자바스크립트 외의 다른 언어, 특히 처리가 빠른 저수준 컴파일언어 (c, c++, rust 등) 를 사용할 수 있게 도와준다. 이를 활용하면 자바스크립트와 서로 상호 보완하여 동작이 가능해지고, 나아가 자바스크립트 수준에서 처리하기 어려운 일들도 처리할 수 있게 된다.

웹은 모바일, PC 등 다양한 플랫폼에서 동작하지만, 기본적으로 다른 언어에 비해 성능이 느린 자바스크립트 밖에 사용할 수 없다는 한계를 가지고 있었다. 그러나 웹 어셈블리를 사용하면 이전까지는 웹에서 돌릴 수 없던 다양한 클라이언트 앱을 네이티브에 가까운 성능과 속도로 실행할 수 있게 된다.

### Web Assembly가 달성하고자 하는 목표

> [https://www.w3.org/community/webassembly/](https://www.w3.org/community/webassembly/)

- 빠르고, 효과적이고, 이식성이 좋을 것
- 읽기 쉽고 디버깅이 가능한 구조일 것
- 안전할 것
- 웹 환경을 망가뜨리지 않을 것

### Web Assembly의 동작 구조

웹 플랫폼은 크게 두 가지로 나눠서 생각할 수 있다.

- 자바스크립트와 같은, 앱을 구성하는 코드를 실행하는 가상머신
- 웹브라우저나 하드웨어 기능을 호출해서 애플리케이션이 무언가를 할 수 있도록 만드는 Web API (DOM, CSSOM, WebGL....)

첫 번째로 언급한 이 가상머신에서는, 오직 자바스크립트만 실행이 가능했다. 태초에 웹이 탄생했을 무렵, 자바스크립트의 비중은 거의 없었다. 그러나 기기의 성능 발전, 웹 표준화, ajax 등으로 인해 자바스크립트가 웹 애플리케이션에서 차지하는 비중은 점차 늘기 시작했다. 그리고 사람들은 점차 더 많은 것들을 웹에서 구현하길 원했다. 3D 게임, 가상현실, 영상처리, 이미지 편집 등 네이티브 성능을 필요로 하는 작업은 자바스크립트라는 한계에 부딪혔다. 오늘날의 웹 애플리케이션은 사이즈에 따라 다르지만, 아주 큰 자바스크립트를 받고 컴파일하고 파싱하는데에만 감당하기 어려운 비용을 처리하는 경우도 있다. 특히 모바일과 같은 경우에는 이러한 성능 병목 현상이 두드러진다.

WebAssembly는 자바스크립트와 다른 언어지만, 자바스크립트를 대체하기 위해 만들어진 것은 아니다. Web Assembly와 자바스크립트는 서로 부족한 점을 보완하여, 웹 개발자가 다양한 작업을 처리할 수 있게 끔 도와준다.

- 자바스크립트는 웹 애플리케이션을 작성하기에 좋은 고수준의 언어다. 동적타입 언어로서 컴파일 과정이 필요없고, 다양한 프레임워크, 라이브러리, 도구를 제공하는 아주 거대한 생태계를 가지고 있다.
- WebAssembly는 어셈블리와 같이 컴팩트한 바이너리 포맷을 가지고 있는 저수준 언어로, 네이티브에 가까운 성능을 제공하고, C++, Rust와 같은 저수준 메모리 모델을 가진 언어로 작성된 프로그램을 웹에서 실행할 수 있게 해준다.

필요하다면 다른 형식의 이 두 코드가 서로를 호출할 수 있다.

### Web Assembly의 핵심 컨셉

- 모듈: 실행가능한 컴퓨터 코드로, 브라우저에서 컴파일된 바이너리를 의미한다. 모듈은 stateless 이고, 윈도우와 워커 간에 `postMessage()`를 통해 공유가 가능하다.
- 메모리: Web Assembly의 저수준 메모리 접근 명령어에 의해 읽고 쓰여지는 바이트를 의미하며, 사이즈 조절이 가능한 Array Buffer다.
- 테이블: raw 바이트로 메모리에 저장될 수 없는 레퍼런스를 의미한다.
- 인스턴스: 모듈, 그리고 그 모듈이 사용하는 모든 상태를 의미한다. 여기서 말하는 상태란 메모리, 테이블, import 된 값의 집합 등이 있다.

### 사용 가능한 언어

- C/C++
- Rust
- [AssemblyScript](https://assemblyscript.org/introduction.html) (타입스크립트와 비슷)
- C#
- F#
- Go
- Kotlin
- Swift
- D
- Pascal
- Zig
- Grain

> [https://webassembly.org/getting-started/developers-guide/](https://webassembly.org/getting-started/developers-guide/)

## 왜 러스트인가?

### .wasm 사이즈가 작다

`.wasm`은 네트워크를 통해 받아야하는 바이너리 파일로, 이 코드 크기는 성능에 있어 매우 중요하다. 러스트는 가비지 컬렉터와 같은 추가적인 bloat이 포함되어 있지 않아 작은 크기의 `.wasm`을 사용할 수 있다. 즉, 실제로 사용하는 함수와 기능에 대해서만 값을 치루면 된다.

예를 들어 Go와 같이 상대적으로 작은 런타임 언어도, hello world 수준의 프로그램을 컴파일 하면 2MB가 넘는 바이너리 트리를 갖는다. 반면 rust는 1.46kb에 불과하다. 또한 `.wasm`으로 컴파일 시에 네이티브에 애플리케이션에 비례하는 실행 속도를 누릴 수 있으므로, 속도와 성능 모두를 잡을 수 있게 된다.

### 자바스크립트와 비슷한 생태계

[이전에도 언급했던 것](/2022/02/rust-for-javascript-developer-chapter1) 처럼 자바스크립트와 러스트는 비교적 비슷한 생태계를 가지고 있다.

### Web Assembly를 위한 다양한 도구

WEb Assembly로서의 rust를 사용하기 용이하게 하기 위한 다양한 도구들이 존재한다.

- [wasm-pack](https://github.com/rustwasm/wasm-pack)
- [wasm-opt](https://github.com/MrRefactoring/wasm-opt)
- [wasm2js](https://github.com/thlorenz/wasm2js)
- [twiggy](https://github.com/rustwasm/twiggy)

특히 이 중에 첫 번째 라이브러리는 오직 rust 를 위해서 만들어져있는데, 이도구가 정말 강력하여 다른 언어에서는 여러 프로세스나 도구를 거쳐야하는 번거로움을 한번에 해결 할 수 있다.


Rust로 web assembly 만들어보기 (1) - Web Assembly란 무엇인가?

## Table of Contents

## tools

rust에서 사용하는 대표적인 툴을 nodejs 입장에서 비교해 보았다.

- [nvm](https://github.com/nvm-sh/nvm) ➝ [rustup](https://rustup.rs/)
- `npm` ➝ [cargo](https://rustup.rs/) (rust package manager)
- `eslint` ➝ [clippy](https://github.com/rust-lang/rust-clippy)
- `prettier` ➝ [rustfmt](https://github.com/rust-lang/rustfmt)

## rustup 설치 및 사용

가장먼저 할일은 [rustup](https://rustup.rs/)을 설치하는 것이다. 설치하는 방법은 간단하다.

```bash
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
```

기본으로 설치하면 알아서 잘 설치되는 것을 볼 수 있다. 몇가지 명령어를 사용해보자.

- `rustup show`: 현재 시스템에 설치된 러스트 버전을 알 수 있다.
- `rustup completions`: cli에서 tab 등으로 자동완성을 할 수 있도록 도와주는 도구. `rustup completions zsh`를 입력하면 `zsh`에서 자동완성을 할 수 있도록 도와준다.
- `rustup update`: 가장 최신버전으로 업데이트 한다.
- `rustup install [version]`: 특정 버전, stable, nightly 버전 등으로 설치할 수 있다.

## npm에서 cargo로 전환하기

cargo는 앞서 언급했던 것처럼 npm과 비슷하게 rust세계에서 사용하는 패키지 매니저다. cargo는 [crates.io](https://crates.io/)에서 의존성을 다운로드 하고 설치한다. npmjs.com 와 동작방식이 유사한데, 개발자들이 가입해서 여기에 모듈을 업로드할 수도 있다. 쉽게 공부하기 위해서, `npm`과 `cargo`를 매핑하는 방식으로 이해해보자.

## npm vs cargo

### 프로젝트 세팅 파일

node.js에 `package.json`이 있다면 rust에는 `Cargo.toml`이 있다. 확장자에서 알 수 있는 것 처럼, `json` 형식이 아닌 `toml` 형식으로 되어 있다. 그다지 어려운 설정 파일이 아니므로, 파일 형태에 대한 설명을 생략한다. 여기에는 어떤 의존성을 다운로드할지, 테스트는 어떻게 할지, 빌드는 어떻게 할지 등을 나타낼 수 있다.

> https://doc.rust-lang.org/cargo/reference/manifest.html

### 프로젝트 시작하기

`npm init`과 유사하게 `cargo init`과 `cargo new`가 있다. `cargo init`은 현재 디렉토리에서, `cargo new`는 새로운 디렉토리에서 시작한다.

### 의존성 설치

`npm install [dep]`가 있다면, rust에는 `cargo add [dep]`이 있다. 이 명령어를 사용하기 위해서는 [cargo-edit](https://github.com/killercup/cargo-edit)을 설치해야 한다.

> $ cargo install cargo-edit

`cargo-edit`은 `add` `rm` `upgrade` `set-version`등을 지원한다.

> https://github.com/killercup/cargo-edit

### 글로벌하게 tool 설치

앞서 눈치챘을 수도 있지만, `npm install -g`는 `cargo install`과 같다.

### 테스트

`npm test`는 `cargo test`와 같다. `cargo test`를 거치면 유닛테스트, 통합 테스트, 문서화 테스트를 자동으로 실행하게 된다.

### 모듈 publish

`npm publish`는 `cargo publish`와 같다. 앞서 언급했던 것 처럼, [crates.io](https://crates.io/) 계정과 인증이 필요하다.

### 그밖에 작업 실행하기

그밖에 cargo에서 대응되는 작업은 다음과 같다.

- `npm run start`: `cargo run`
- `npm run benchmarks`: `cargo bench`
- `npm run build`: `cargo build`
- `npm run clean`: `cargo clean` 이 작업을 실행하면 `target` 폴더를 청소한다.
- `npm run docs`: `cargo doc`

그외의 경우에는 rust 개발자가 개별적으로 대응해야 한다.

## 그밖에 다른 도구들

### `cargo-edit`

`cargo-edit` 는 앞서 언급했던 것 처럼 `cargo add` `cargo rm`과 같은 명령어를 가능하게 해준다.

### `cargo-workspaces`

cargo-workspaces는 워크스페이스를 만들고 관리할 수 있도록 도와주는 도구다. 이는 node의 lerna에 영감을 받아 만들어졌다. 여기에는 패키지 자동 publish, local 의존성을 publish 버전으로 대체하는 등 다양한 도구를 제공한다.

## VSCode에서 설치하면 도움이되는 도구들

- https://marketplace.visualstudio.com/items?itemName=rust-lang.rust
- https://marketplace.visualstudio.com/items?itemName=matklad.rust-analyzer
- https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb (debug)
- https://marketplace.visualstudio.com/items?itemName=bungcip.better-toml
- https://marketplace.visualstudio.com/items?itemName=serayuzgur.crates
- https://marketplace.visualstudio.com/items?itemName=belfz.search-crates-io

## Hello World

자, 이제 hello world를 작성해보자.

```bash
cargo new my-app
```

기본값으로, `cargo new`는 바이너리 애플리케이션 템플릿을 사용한다. 코드를 실행 한뒤에는, 아래와 같은 디렉토리 구조를 볼 수 있다.

```
my-app/
├── .git
├── .gitignore
├── Cargo.toml
└── src
  └── main.rs
```

`cargo run`을 실행해보자.

```bash
» cargo run
  Compiling my-app v0.1.0 (./my-app)
  Finished dev [unoptimized + debuginfo] target(s) in 0.89s
  Running `target/debug/my-app`
Hello, world!
```

`cargo run`은 `cargo build`를 실행하여 애플리케이션을 빌드하고, 그리고 실행한다. 빌드된 바이너리는 `./target/debug/my-app`에서 확인할 수 있다. 실행 없이 빌드만 하고 싶다면, `cargo build`를 실행하면 된다. 기본적으로, 빌드는 `dev` 프로파일에서 실행되기 때문에 파일의 크기, 성능과 같은 디버그에 유용한 정보를 얻을 수 있다. 실제 프로덕션에 필요한 프로그램을 얻기 위해서는 `cargo build --release`를 실행하면 되고, 해당 결과는 `./target/release/my-app`에 위치한다.

`src/main.rs`를 살펴보자.

```rust
fn main() {
  println!("Hello, World!")
}
```

음 별다르게 특이한건 없다. 🤔

- `main()`은 단독 실행 되는 애플리케이션을 만들 때 필요한 함수다. cli app의 시작지점이 된다.
- `println!()`는 받은 인수를 STDOUT해주고 있다.
- `"Hello, world!"`는 string이다.

### 자바스크립트와 다른 것 1

먼저 앞선 string을 변수에 넣어서 실행해보자. rust도 마찬가지로 변수를 선언할때 `let`을 쓴다. 자바스크립트 세계엔 `let` `const`가 있고, 대부분 `const`를 쓰지만, rust는 대부분 `let`을 쓴다.

`let`을 사용하여 변수를 할당해서 사용해보자.

```rust
fn main() {
  let message = "Hello, World!";
  println!(message)
}
```

```shell
@yceffort ➜ /workspaces/rust-playground/chapter1/hello_cargo (main ✗) $ cargo run
   Compiling hello_cargo v0.1.0 (/workspaces/rust-playground/chapter1/hello_cargo)
error: format argument must be a string literal
 --> src/main.rs:3:14
  |
3 |     println!(message)
  |              ^^^^^^^
  |
help: you might be missing a string literal to format with
  |
3 |     println!("{}", message)
  |              +++++

error: could not compile `hello_cargo` due to previous error
```

자바스크립트 개발자의 시선에서는 동작해야할 코드였던 것 같은데, 동작하지 않았다. 대부분의 언어에서는 잘 동작할 코드일 것 같은데, 러스트는 그렇지 않다. 에러 메시를 일단 잘 살펴보자.

> format argument must be a string literal

`println!()`은 첫번째 인수를 string literal을 요구하고, 변수를 활용하여 formatting하는 것을 지원한다. 따라서 우리는 코드를 아래와 같이 고쳐야 한다.

```rust
fn main() {
  let message = "Hello, World!";
  println!("{}", message)
}
```

### 자바스크립트와 다른 것 2

이번엔 함수를 사용한다고 가정해보자.

```rust
fn main() {
    greet("world")
}

fn greet(target: String) {
    println!("hello, {}", target)
}
```

이 코드 역시 에러가 난다.

```shell
@yceffort ➜ /workspaces/rust-playground/chapter1/hello_cargo (main ✗) $ cargo run
   Compiling hello_cargo v0.1.0 (/workspaces/rust-playground/chapter1/hello_cargo)
error[E0308]: mismatched types
 --> src/main.rs:2:11
  |
2 |     greet("world")
  |           ^^^^^^^- help: try using a conversion method: `.to_string()`
  |           |
  |           expected struct `String`, found `&str`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `hello_cargo` due to previous error
```

`String`을 `target`으로 예상했지만, 그것이 아닌 `&str`을 전달받았다는 에러다. 이러한 일이 왜 일어나는지 알기 위해서는, rust에서 String이 무엇인지 알아봐야 하고, 그것보다 이전에 우리는 러스트의 '소유권' 과 '빌림' 의 개념에 대해서 알아야 한다. rust의 가장 핵심이 되는 개념이다.

## 소유권과 빌림

소유권은 러스트를 이해하는데 있어 첫번째 난관이다. 이해하기가 어렵다기보다는, 러스트의 규칙은 다른 언어에서는 잘 통용되는 논리와 구조를 다시금 생각하게 만드는 구조이기 때문이다.

러스트는 가비지 컬렉터 없이 안전한 메모리 해제를 약속한 덕분에 많은 인기와 지지를 얻을 수 있었다. 자바스크립트나 GO는 메모리를 관리하기 위해 가비지 컬렉션을 사용한다. 객체에 대한 모든 참조를 추적하고, 이 참조 카운트가 0으로 감소했을 때만 메모리를 해제한다. 이 가비지 컬렉터는 자완과 성능을 희생하여 개발자를 좀더 편하게 만들어 준다. 물론 이정도로도 충분할 수 있다. 그러나, 이것으로 부족할때, 이 가비지 컬렉터 문제를 해결하고 최적화 하는 것은 굉장히 어려운 일이다. 러스트에서는 가비지 컬렉터의 오버헤드 없이 메모리 안정성을 달성할 수 있다. 모든 자원을 특별히 노력을 기울이지 않아도 돌려 받을 수 있다.

메모리의 안정성은 단순히 프로그램이 예기치 않은 크래쉬를 방지하는 것 그 이상의 것을 의미한다. 모든 종류의 보안 취약점을 차단한다는 것을 의미한다. SQL 인젝션을 들어보았는가? SQL 인젝션은 미처 관리되고 있지 않은 사용자 입력을 활용하여 의도치 않은 SQL 문을 만들어내고, 데이터를 빼돌리는 데이터베이스 클라이언트 쪽 취약성이다. 이 공격은 그다지 어려운 것이 아니라서 3관리가 가능하고 100% 예방 또한 가능하다. 그러나 오늘 날 웹 애플리케이션에서 가장 흔한 취약점으로 남아 있다. 메모리 측면에서 안전하지 않은 코드는 어디서나 나타날 수 있는 SQL 인젝션 취약성을 찾기 어려워진다는 것과 비슷하다. 메모리 안정성 측면의 버그는 심각한 취약점의 대부분을 차지한다. 그러므로, 성능에 영향을 미치지 않고 이러한 위협요소를 모두 제거할 수 있다는 것은 매력적인 개념이라고 볼 수 있다.

### 변수 할당과 mutability

앞서 이야기 한 것처럼 자바스크립트에는 `let` `const`가 있으며, `const`는 다시 재할당 할 수 없는 변수를 선언할 때 쓴다. 러스트에도 `let` `const`가 있지만, 일단 `let`만 쓴다.

자바스크립트에서 `const`가 쓰고 싶다면, rust에서는 `let`을 쓰면 된다. `let`을 쓰고 싶다면, `let mut`을 쓰면 된다. `mut`은 변수 중에서도 재할당 가능한 변수를 선언할 때 사용한다.

```javascript
let one = 1
console.log(one) // 1
one = 3
console.log(one) // 3
```

러스트에서는

```rust
fn main() {
  let mut one = 1;
  println!("{}", one);
  one = 3;
  println!("{}", one)
}
```

이렇게 작성하면 된다.

한가지 큰 다른점은, 오로지 같은 타입일때만 가능하다는 것이다. 즉 아래와 같은 코드는 불가능하다.

```rust
fn main() {
    let mut one = 1;
    println!("{}", one);
    one = "3";
    println!("{}", one)
}
```

```
@yceffort ➜ /workspaces/rust-playground/chapter1/hello_cargo (main ✗) $ cargo run
   Compiling hello_cargo v0.1.0 (/workspaces/rust-playground/chapter1/hello_cargo)
error[E0308]: mismatched types
 --> src/main.rs:4:11
  |
2 |     let mut one = 1;
  |                   - expected due to this value
3 |     println!("{}", one);
4 |     one = "3";
  |           ^^^ expected integer, found `&str`

For more information about this error, try `rustc --explain E0308`.
error: could not compile `hello_cargo` due to previous error
```

다른 타입을 변수에 할당하고 싶다면 `let`을 선언하여 같은 이름에 할당하는 방법을 쓰면 된다.

```rust
fn main() {
    let one = 1;
    println!("{}", one);
    let one = "3";
    println!("{}", one)
}
```

### 러스트에서 빌림을 확인하는 법

러스트에는 데이터를 전달하는 방법, 즉 데이터를 "빌리는 방법" 과 "소유권" 에대한 기본적인 규칙을 적용함으로써 메모리 안전성을 보장한다.

### 규칙1. 소유권

값을 전달하면, 호출하는 코드는 더이상 해당 데이터에 접근할 수 없다. 간단히 말해 소유권을 포기한 것이다. 아래 코드를 확인해보자.

```rust
use std::{collections::HashMap, fs::read_to_string};

fn main() {
    let source = read_to_string("./README.md").unwrap();
    let mut files = HashMap::new();
    files.insert("README", source);
    files.insert("README2", source);
}
```

```shell
@yceffort ➜ /workspaces/rust-playground/chapter1/hello_cargo (main ✗) $ cargo run
   Compiling hello_cargo v0.1.0 (/workspaces/rust-playground/chapter1/hello_cargo)
error[E0382]: use of moved value: `source`
 --> src/main.rs:7:29
  |
4 |     let source = read_to_string("./README.md").unwrap();
  |         ------ move occurs because `source` has type `String`, which does not implement the `Copy` trait
5 |     let mut files = HashMap::new();
6 |     files.insert("README", source);
  |                            ------ value moved here
7 |     files.insert("README2", source);
  |                             ^^^^^^ value used here after move
```

앞으로 rust를 공부하면서 가장 많이 마주하게될 에러 메시지, `use of moved value: source.`다. 처음 `source`를 HashMap에 넘겼을때, 이때는 우리는 소유권을 포기한 것이다. 따라서 두번째 줄에서는 동일하게 호출할 수 없었던 것이다. 위 코드가 실행되기 위해서는, 다음과 같이 고쳐야한다.

```rust
use std::{collections::HashMap, fs::read_to_string};

fn main() {
    let source = read_to_string("./README.md").unwrap();
    let mut files = HashMap::new();
    files.insert("README", source.clone());
    files.insert("README2", source);
}
```

### 규칙2. 빌림

데이터를 빌릴때, 즉 데이터의 참조를 가져가고 싶다면, `&` 키워드를 사용해서 참조를 가져올 수 있다. 이를 사용하면 앞서 했던 것 처럼 굳이 번거롭게 데이터를 계속 복사하지 않아도 참조를 안전하게 가져올 수 있다.

```rust
use std::{collections::HashMap, fs::read_to_string};

fn main() {
    let source = read_to_string("./README.md").unwrap();
    let mut files = HashMap::new();
    files.insert("README", source.clone());
    files.insert("README2", source);

    // rust 참조 가져오기
    let files_ref = &files;
    let files_ref2 = &files;

    print_borrowed_map(files_ref);
    print_borrowed_map(files_ref2)
}


fn print_borrowed_map(map: &HashMap<&str, String>) {
    println!("{:?}", map)
}
```

만약 map에 mutable reference가 필요하다면, `let files_ref = &mut files;`를 사용하면 된다.

```rust
use std::{collections::HashMap, fs::read_to_string};

fn main() {
    let source = read_to_string("./README.md").unwrap();
    let mut files = HashMap::new();
    files.insert("README", source.clone());
    files.insert("README2", source);

    let files_ref = &mut files;
    let files_ref2 = &mut files;

    print_borrowed_map(files_ref);
    print_borrowed_map(files_ref2);

    needs_mutable_ref(files_ref);
    needs_mutable_ref(files_ref2);
}

fn needs_mutable_ref(map: &mut HashMap<&str, String>) {}

fn print_borrowed_map(map: &HashMap<&str, String>) {
    println!("{:?}", map)
}
```

그러나 빌드 하면 에러가 나게된다.

```bash
@yceffort ➜ /workspaces/rust-playground/chapter1/hello_cargo (main ✗) $ cargo build
   Compiling hello_cargo v0.1.0 (/workspaces/rust-playground/chapter1/hello_cargo)
warning: unused variable: `map`
  --> src/main.rs:19:22
   |
19 | fn needs_mutable_ref(map: &mut HashMap<&str, String>) {}
   |                      ^^^ help: if this is intentional, prefix it with an underscore: `_map`
   |
   = note: `#[warn(unused_variables)]` on by default

error[E0499]: cannot borrow `files` as mutable more than once at a time
  --> src/main.rs:10:22
   |
9  |     let files_ref = &mut files;
   |                     ---------- first mutable borrow occurs here
10 |     let files_ref2 = &mut files;
   |                      ^^^^^^^^^^ second mutable borrow occurs here
11 |
12 |     print_borrowed_map(files_ref);
   |                        --------- first borrow later used here

For more information about this error, try `rustc --explain E0499`.
warning: `hello_cargo` (bin "hello_cargo") generated 1 warning
error: could not compile `hello_cargo` due to previous error; 1 warning emitted
```

보면 볼수록 rust 컴파일러의 메시지가 참 친절하다고 느낀다. 만약 다른 참조를 사용하기 전에, 하나의 참조가 끝날 수 있도록 순서를 조정한다면, 이 에러는 더이상 나타나지 않을 것이다.

```rust
use std::{collections::HashMap, fs::read_to_string};

fn main() {
    let source = read_to_string("./README.md").unwrap();
    let mut files = HashMap::new();
    files.insert("README", source.clone());
    files.insert("README2", source);

    let files_ref = &mut files;
    needs_mutable_ref(files_ref);
    let files_ref2 = &mut files;
    needs_mutable_ref(files_ref2);
}

fn needs_mutable_ref(map: &mut HashMap<&str, String>) {}
```

러스트를 시작할때, 코드의 순서를 조정하는 것만으로도 에러를 해결할 수 있는 경우가 많다.


[Rust] 자바스크립트에서 러스트로 (1) - rustup, hello world, 그리고 소유권과 빌림

## Introduction

코딩 하는 시간을 100이라고 가정한다면, 요즘 80은 자바스크립트를, 나머지 10씩을 각각 러스트와 파이썬을 하는데 쓰고 있다. 자바스크립트에 삼항연산자가 있고, 물론 러스트와 파이썬에도 삼항연산자가 있다.

```javascript
const protocol = isSecure ? 'https' : 'http'
```

```python
protocol = 'https' if isSecure else 'http'
```

```rust
let protocol = if isSecure ? { 'https' } else { 'http' };
```

3항 연산자를 쓰면서 느끼는 건, 이게 언어마다 서순이 조금씩 미묘해서 헷갈린다는 점이다. 자바스크립트와 파이썬이 특히 그렇다. 자바스크립트에 젖어서 그런지 파이썬은 코딩을 할 때 마다 헷갈리는 것 같다.

아무튼 지간에, 우리가 대부분 3항연산자를 쓰는 이유는 간결한 코드의 작성을 위해서다. 하지만 우리는 간결함과 명확성을 선택해야할 때가 있고, 그 둘을 모두 잡을 수 없을 때도 존재한다. 그리고 이 두가지는 모두 서로의 주장이 팽팽하게 맞선다. 코드를 적게 씀으로써 내 코드의 크기를 줄이고, 버그의 위험성을 줄일 것이냐, 혹은 명확하고 읽기 쉽게 써서 유지보수와 수정이 더 편하게 할것인가?

이러한 논쟁의 한가운데에 있는것이 바로 3항연산자 인 것 같다. 3항 연산자를 자칫 잘못쓰게 되면 코드를 이해할 수 없는 난장판으로 만들어버리곤 한다. 그렇지만, 3항 연산자는 보통 if-else와 동일한 작업을 할 수 있지만 더 간결하다는 이유로 많이 쓰인다.

하지만 만약에 그 둘이 동일하지 않고 무언가 숨은 차이점이 있다면 어떨까? 둘은 완전히 동일한 것 같지만 그렇지는 않다. 여기에는 사람들이 자주 놓치는 중요한 차이점이 있다. 그리고 이 차이는 코드에 영향을 미칠 수 있다.

## 3항 연산자의 문제점

### 보기에 조금은 이상한 3항 연산자

3항 연산자는, 그 이름인 '3항' 에서 알 수 있듯 세가지 다른 표현으로 동작한다. 이 세가지 표현은 `?` `:`으로 나뉘어져 있다.

```javascript
(/* First expression*/) ? (/* Second expression */) : (/* Third expression */)
```

```javascript
const protocol = isSecure ? 'https' : 'http'
```

첫번째 식이 참이면 두번째 식으로, 그렇지 않다면 세번째 식의 값이 나오게 된다. 그리고 이 연산자는 앞서 언급했듯 두가지 기호로 구분되어 있다. 3항 연산자외에 다른 연산자들은 이렇게 여러개의 기호로 구성되어 있지 않다.
이상한 것은 그것 뿐 만 아니다. 대부분의 바이너리 연산자는 일관적인 타입을 가지고 있다. 산술연산자는 숫자 타입으로만 동작하고, boolean 연산자는 boolean 에 대해서만 동작한다. 비트와이저는, 숫자타입에서만 동작한다. 그러나 삼항연산자는 어떠한 타입으로든 동작할 수 있다. 두번째와 세번째 식에서 어떤 타입이든 들어올 수 있다. 하지만 첫번째 식은 boolean으로 표현되어야 한다. 타입에 대해 이렇게 일관적이지 않다는 점은 확실히 이상하다.

### 초보자에게 별로 도움이 안되는 3항 연산자

3항 연산자는 특이하게 생겼다. 만약 나와 반대로 파이썬을 개발하다가 자바스크립트를 개발하러 온 사람이 있다면, 3항연산자는 항상 익숙하지 않은 존재일 것이다. 기억해야할 것이 많다. `?`도 찾아야 하고 `:`도 찾아야 한다. `if-else`와 달리 삼항연산자를 수도 코드로 읽는 것은 어렵다.

```javascript
if (someCondition) {
  takeAction()
} else {
  someOtherAction()
}
```

이 식을 읽는 것은 그리 어려운 일이 아니다. `someCondition`이 true면 `takeAction`을, 그렇지 않으면 `someOtherAction`을 실행할 것이다. 이는 크게 어려운 일이 아니다. 그러나 3항연산자는 기호와 구성되어 있기 때문에 위 코드처럼 쉽게 읽히지 않는다. 언어를 읽는 자연스러운 과정과 확실히 대비된다.

### 가독성이 떨어진다.

초보자가 아니더라도, 3항 연산자는 종종 읽기 어려운 것이 사실이다. 특히, 이런 가독성 문제는 삼항연산자가 길어질 때 더욱 문제를 만든다.

{/* prettier-ignore-start */}
```javascript
const ten = Ratio.fromPair(10, 1);
const maxYVal = Ratio.fromNumber(Math.max(...yValues));
const minYVal = Ratio.fromNumber(Math.min(...yValues));
const yAxisRange = (!maxYVal.minus(minYVal).isZero()) ? ten.pow(maxYVal.minus(minYVal).floorLog10()) : ten.pow(maxYVal.plus(maxYVal.isZero() ? Ratio.one : maxYVal).floorLog10());
```
{/* prettier-ignore-end */}

저 3항연산자 내부에서 정확히 무슨일이 일어나고 있는지 한번에 이해할 수 있는 사람은 별로 없다. 각 표현식 내부의 코드도 복잡하고, 3항 연산자도 내부에 중첩이 되어서 더욱 어렵다.

물론, prettier를 사용하면 조금더 상황이 나아질 수는 있다.

```javascript
const ten = Ratio.fromPair(10, 1)
const maxYVal = Ratio.fromNumber(Math.max(...yValues))
const minYVal = Ratio.fromNumber(Math.min(...yValues))
const yAxisRange = !maxYVal.minus(minYVal).isZero()
  ? ten.pow(maxYVal.minus(minYVal).floorLog10())
  : ten.pow(maxYVal.plus(maxYVal.isZero() ? Ratio.one : maxYVal).floorLog10())
```

그럼에도 여전히 읽기 어렵다는 사실엔 변함이 없다.

물론, 실제 이런식으로 3항연산자를 복잡하게 쓰는 사람은 별로 없을 것이다. (코드 리뷰어가 잔소리를 한두마디 하겠지) 하지만 우리가 기억해야할 포인트는 여전하다.

> Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler

우리는 컴퓨터가 아닌 사람이 읽기 좋은 코드를 짜야하는 책임을 가지고 있다. 그리고 이것이 3항 연산자가 가지는 가장 큰 문제라 생각한다. 일단 작성자가 코드를 우겨 넣는 것은 쉽다. 그러나 그렇게 코드를 우겨넣기 시작하면, 엉망진창이 될 가능성이 기하급수적으로 커진다. 특히 주니어 프로그래머라면, 3항연산자보다는 `if-else`를 쓰라고 이야기 하고 싶다.

## if-else의 신뢰성 문제

그래, 3항연산자는 그렇다 치자. `if-else`는 완벽한가? 그럼에도 3항연산자를 쓰는 이유는 간결하거나 조금더 영리하게 코드를 작성하기 위함이다. 아래 예시를 보자.

```javascript
let result;
if (someCondition) {
    result = calculationA();
} else {
    result = calculationB();
}`
```

```javascript
const result = someCondition ? calculationA() : calculationB()
```

사람들은 일반적으로 이 두 예제가 동일하다고 생각한다. 두 예제 모두 `result`라는 변수안에 조건에 따라 두 함수의 리턴 값을 넣어준다. 하지만 다른 측면으로 보면, 조금은 다르다. 먼저 `let`을 살펴보면 알수 있다. 두 차이점은, `if-else`는 문(statement)이지만, 3항연산자는 표현식(expression) 이라는데에 있다. 그래서 그 차이점이 뭔데?

- 표현식 (expression)은 항상 어떠한 값을 계산한다.
- 문(statement)는 하나의 실행 단위로 존재한다.

이는 중요한 개념이다. 표현식은 값을 계산하지만, 문은 그렇지 않다. statement의 결과값을 어떤 변수에 할당할 수 없다. statement의 결과를 함수의 인수로 넘겨줄 수 없다. 그리고 `if-else`는 statement로, 어떠한 값을 resolve하고 있지 않다. 따라서 이를 사용할 수 있는 가장 좋은 케이스는 부수효과 (side-effect)을 일으키는 경우다.

부수효과(side-effect)는 무엇인가? 이는 값을 resolve하는 것 이외에 코드에서 일어나는 모든 일들이다. 예를 들어

- 네트워크 요청
- 파일 읽고 쓰기
- 데이터베이스 쿼리
- DOM 엘리먼트 조작
- 전역변수 수정
- 콘솔 로그 등

이 부수효과는 함수형 프로그래밍의 핵심 아이디어다. 우리는 이 부수효과를 잘 다룸으로써 코드에 대한 자신감을 얻게 된다. 최대한 가능한, 우리는 순수 함수로 작성해야할 의무가 있다. 우리는 순수함수에서는 값을 계산하고 리턴하는 것만 해야 한다는 것을 명심해야 한다.

근데 이게 여기서 무슨 상관일까? `if-else`를 항상 의심의 눈초리로 봐야 한다는 것을 의미한다.

```javascript
if (someCondition) {
  takeAction()
} else {
  someOtherAction()
}
```

`someCondition` 의 결과가 어디로 이끌든 우리가 신경 쓸 문제가 아니다. 우리가 이 구문에서 주의해야할 것은 여기서 부수효과가 일어난다는 것이다. 여기서 부수효과는 `takeAction` `someOtherAction` 이다. 그리고 둘 모두 어떠한 값도 리턴하고 있지 않다. 그리고 이 두 함수가 수행하는 작업은 모두 이 블록 밖에서 이루어진다. 그리고 우리는 이 두함수가 어떤 부수효과를 이르키는지 알고 있어야 한다. 그것에 대해 대답할 수 없다면, 우리는 코드를 이해할 수 없다.

즉 if문에서 부수효과가 일어나고 있으며, 이는 더이상 순수하지 않다는 것을 의미한다.

## 3항연산자로 돌아와서

`if-else`를 의심스럽게 봐야 한다는 건 그렇다 치자. 그렇다면 3항연산자는 어떤가? 이러한 부수효과의 측면에서 더 나은가? 이전에 했던 모든 논란은 여기서도 여전히 유효하다.

우리가 표현식을 좋아하는 이유는 표현식은 다른 표현식과 합칠 수 있기 때문이다. 다양한 연산자와 함수를 사용하면 복잡한 표현식을 간결하게 아래 처럼 작성해 줄 수 잇다.

```jsx
'<h1>' + page.title + '</h1>'
```

우리는 이 표현식을 함수의 인수로 넘겨줄 수 있다. 또는 다른 표현식과 연산자로 결합할 수도 있다. 표현식을 여러개 결합하는 것은 더욱 복잡한 연산을 가능하게 해준다. 표현식을 묶는 것은 코드를 작성하는 훌륭항 방법이다.

하지만, statements도 결합할 수 있는 건 마찬가지 아닌가? for 문과 if 문도 합칠 수 있잖아? 그런데 왜 표현식에서 더 빛을 발하는 것일까?

표현식의 장점은 바로 [참조 투명성 (referential transparency)](https://ko.wikipedia.org/wiki/%EC%B0%B8%EC%A1%B0_%ED%88%AC%EB%AA%85%EC%84%B1)에 있다. 이는 우리가 표현식에 있는 값을 취해서 다시 표현식 자체에 사용할 수 있다는 것을 의미한다. 그리고 우리는 이것을 바탕으로 항상 같은 결과가 리턴된다는 것을 확신할 수 있다. 이 참조 투명성은 statements와 expression을 작성하는 것과 의 차이점을 설명해준다.

그러면 표현식인 3항연산자를 더 선호해야 한다는 것인가? 그렇지 않다. 다른 언어처럼, 자바스크립트도 표현식에서 부수효과로 부터 자유롭지는 않다. 아래 예제를 보자.

```javascript
const result = someCondition ? dropDBTables() : mineDogecoin()
```

표현식인 3항연산자에서도, 부수효과가 일어날 수 있는 여지는 충분히 존재한다.

## 조건문을 쓸 때 가져야할 책임감

그래 3항연산자도 별로고, if-else도 별로면 다른 언어를 써야하는 건가? 여기서 하고 싶은 말은 항상 신중히 행동해야 한다는 것이다.

### 안전한 statements를 선택하자.

statements가 없다면 자바스크립트 코드를 제대로 작성하기 어렵다. 우리는 이 statements에서 벗어날수가 없다. 우리는 이 statements를 안전하게 작성해야 한다.

가장 위험한 경우는 블록이 존재하는 경우다. 여기에는 if, for, while, switch 등이 포함된다. 이 들은 부수효과를 일으키는 것들이기 때문이다. 무언가 블록밖을 벗어나서, 현재의 환경을 변경시킬 수 있다.

이보다 안전한 statements는 변수할당문과 리턴문이다. 변수 할당은 expression의 결과를 레이블에 바인딩 한다. 그리고 변수는 그자체로 expression이다. 우리가 원하는 만큼 많이, 자주 사용할 수 있다. 이 값이 할당 된 이후에 변하는 것을 피한다면 (immutable하게 만든다면) 변수할당문은 안전하다.

반환 문은 함수 호출을 값으로 확인하므로 유용하다. 함수 호출은 하나의 표현식이다. 변수할당과 마찬가지로 return은 표현식을 만드는데 도움이 된다.

이 두가지 전제조건을 바탕으로, 안전한 조건문을 쓸 수 있는지 생각해볼 수 있다.

### 안전한 if 문

안전한 if문을 작성하기 위해서는 다음의 간단한 규칙을 따르면 된다. 첫번째 분기 조건에서 return으로 끝나면 된다. 그렇게 하면, if-staement가 값을 resolve하지 않더라도, 외부 함수는 가능해질 것이다.

```javascript
if (someCondition) {
  return resultOfMyCalculation()
}
```

이 규칙만 따른다면, else 블록을 작성할 필요가 없어진다. 만약 else가 들어간다면, 거기에 부수효과가 들어간다는 것을 의미한다. 물론 작고 별일 하지 않을 수도 있지만, 부수효과가 존재하는 것은 사실이다.

### 읽기 쉬운 3항 연산자

3항 연산자는 항상 작고 간결해야 한다. 만약 그 식이 길어진다면, 수직으로 나누어서 가독성을 높여야 한다. 그럼에도 길어진다면, 변수 할당을 통해서 더욱 간결하게 만들 필요가 있다.

중첩 3항 연산자는 어떤가? 항상 피해야할까? 그렇지 않다. 만약 수직으로 잘 정렬만 해둔다면, 좀 깊이가 되는 3항연산자라 할지라도 가독성을 해치지 않을 수 있다.

{/* prettier-ignore-start */}
```javascript
const xAxisScaleFactor =
    (xRangeInSecs <= 60)       ? 'seconds' :
    (xRangeInSecs <= 3600)     ? 'minutes' :
    (xRangeInSecs <= 86400)    ? 'hours'   :
    (xRangeInSecs <= 2592000)  ? 'days'    :
    (xRangeInSecs <= 31536000) ? 'months'  :
    /* otherwise */              'years';
```
{/* prettier-ignore-end */}

위 코드에 대해서 prettier가 뭐라고 하겠지만, 잠시 이를 꺼둘 수도 있다. 물론 이 과정은 손이 간다. 그러나 3항 연산자와 if문을 좀더 책임감있게 작성하는 것이 가능해진다.

## 미래엔..?

우리가 이렇게 더 신경쓸수는 있지만, 할 수 있는 일은 제한적이다. 하지만 미래에 약간의 변화가 있을 수도 있다. TC39에 있는 [do expression](https://github.com/tc39/proposal-do-expressions) 이 바로 그것이다.

```javascript
let x = do {
  if (foo()) {
    f()
  } else if (bar()) {
    g()
  } else {
    h()
  }
}
```

`do` 블록 안에 많은 statements를 넣었고, 여기에서 하나의 값을 완성해서 리턴했다. jsx에서 아마도 더 유용하게 사용될 수 있다.

```jsx
return (
  <nav>
    <Home />
    {do {
      if (loggedIn) {
        ;<LogoutButton />
      } else {
        ;<LoginButton />
      }
    }}
  </nav>
)
```

아직 이게 언제 도입될지 알수는 없지만 서도, [babel](https://babeljs.io/docs/en/babel-plugin-proposal-do-expressions)을 써서 미리 써볼 수는 있을 것이다.

## 참고

- https://github.com/getify/eslint-plugin-proper-ternary


그 옛날 이상한 코드를 반성하며

자바스크립트 3항연산자에 대한 고찰

## Table of Contents

## Introduction

[remix](https://remix.run/)는 새로운 리액트 기반 풀스택 웹 프레임워크다. 뭐 어떤 프레임워크고 어떻게 쓰는지는 remix 홈페이지에 잘 나와 있으므로, nextjs에서의 관점에서 remix는 어떤 웹 프레임워크고 무엇이 좋은지, 또 쓸만은 한지 한번 고민해보려고 한다.

## 클라이언트 - 서버 아키텍쳐

### nextjs

먼저 nextjs가 어떻게 애플리케이션을 구조화 하는지를 살펴보자. 일반적으로 nextjs에서는 클라리언트와 서버간의 통신을 위해서 클라이언트의 javascript에 의존하는 경우가 많다. 아래 예제를 살펴보자.

```jsx
// pages/contact.tsx

export default function ContactPage() {
  // form에 전송할 정보
  const [name, setName] = useState(null)
  const [email, setEmail] = useState(null)
  // form 제출 상태와 관련있는 상태 값
  const [submitting, setSubmitting] = useState(false)
  const [errors, setErrors] = useState(null)
  // 실제 클라이언트에 렌더링되는 form
  return (
    <form onSubmit={handleSubmit}>
      <input type="text" name="name" />
      {errors?.name && <em>Name is required</em>}
      <input type="text" name="email" />
      {errors?.email && <em>Email is required</em>}
      <button type="submit">Contact me</button>
    </form>
  )
  async function handleSubmit(e) {
    // form submit시 페이지로 넘어가지 않기 위해
    e.preventDefault()
    const formData = { name, email }
    // 클라이언트 측 validation
    const errors = validateForm()
    if (errors) {
      setErrors(errors)
    } else {
      setSubmitting(true)
      try {
        // 서버에 post 요청
        const response = await fetch('/api/contact', {
          method: 'POST',
          body: JSON.stringify({
            contact: {
              ...formData,
            },
          }),
        })
        const result = response.json()
        if (result.errors) {
          setErrors(result.errors)
        } else {
          // 홈으로 보내기
          router.push('/')
        }
      } finally {
        setSubmitting(false)
      }
    }
  }
}
```

그리고, nextjs에 `/api/` 동작을 추가할 수 있을 것이다.

```js
// pages/api/contact.js
export default function handler(req, res) {
  const { name, email } = req.body

  const errors = {}
  if (!name) errors.name = true
  if (!email) errors.email = true

  if (Object.keys(errors).length > 0) {
    res.status(400).json(errors)
  } else {
    await createContactRequest({ name, email })

    res.status(200).json({ success: true })
  }
}
```

이러한 방식은 nextjs에서 일반적인 방식으로, 위 코드에서 볼 수 있는 것 처럼 상당한 양의 자바스크립트 코드가 필요하다. (그리고 전체 페이지 번들에 hydration이 일어나지 않는다면 제대로 동작하지 않을 것이다.) 또한 위에 예제 처럼 수동으로 fetch 기반의 form을 만들어서 처리한다면, 비동기 fetch 이슈와 같은 문제도 처리해야 한다.

### remix

remix는 자바스크립트 코드를 훨씬 적게 썼던 php/rails 내부의 서버 템플릿 웹 앱 시절을 생각나게 한다. 아래 예제를 살펴보자.

```jsx
// app/routes/contact.tsx
export const action: ActionFunction = async ({ request }) => {
  const formData = await request.formData()

  const name = formData.get('name')
  const email = formData.get('email')

  const errors = {}
  if (!name) errors.name = true
  if (!email) errors.email = true

  if (Object.keys(errors).length > 0) {
    return errors
  }

  await createContactRequest({ name, email })

  return redirect('/')
}

export default function ContactPage() {
  // ActionFunction을 리턴으로 하는 action 함수가 기본으로 실행됨
  const errors = useActionData()
  return (
    <form method="post">
      <input type="text" name="name" />
      {errors?.name && <em>Name is required</em>}
      <input type="text" name="email" />
      {errors?.email && <em>Email is required</em>}
      <button type="submit">Contact me</button>
    </form>
  )
```

겉으로 보았을 때는 php 스타일로 작성된, post 핸들러를 갖춘 HTML form 일 뿐이다. 자바스크립트에 hydration이 이뤄지지 않더라도 이 코드는 작동한다. `useActionData`는 액션 핸들러에서 반환된 json 데이터를 사용할 수 있도록 한다. 이 액션 아키텍텨는 리액트를 풀스택 프레임워크로 정의하는 방법이다.

remix의 디자인은 기존의 브라우저가 지원하는 클라이언트 - 서버 모델을 본떠서 만들어졌기 때문에, 훨씬 더 적은 코드로 작성되었다.

이러한 방식에 익숙하지 않은 개발자들은, 이러한 핸들러에 일반적인 패턴이 다음과 같이 존재한다는 것을 인지하고 있어야 한다.

- validation이 실패하면, 에러를 서버로 부터 받고 동일한 페이지를 리렌더링 한다.
- validation이 성공하면 대상 페이지로 리다이렉트가 일어난다. 그리고 이 도착 페이지에 toast 메시지를 노출할 수 있다. (remix에는 빌트인 [session](https://remix.run/docs/en/v1/api/remix#using-sessions)이 있는데, 이를 활용하면 된다.)

만약 한 페이지에 여러개의 form이 있다면?

숨겨진 필드를 사용하여 각 form이 무엇을 나타내는지를 구별하거나, submit button에 추가적인 값을 넘겨주면 된다.

만약에 일반적인 REST API를 쓰고 싶다면?

nextjs의 경우에는, api 엔드포인트는 임의의 페이지와 클라이언트를 서비스할 수 있는 일반적인 REST api의 일부였다. 이에 반해 remix는 `loader` 함수를 정의하여 (뒤에서 설명) 임의의 데이터를 반환하는 라우트인 리소스 라우트를 정의할 수 있다. nextjs와 다르게, `/pages/api`에 위치할 필요는 없다.

만약 클라이언트 측에서 인터랙션이 있는 form validation을 사용하고 싶다면?

`Form`과 함께 `useTransition`을 사용하면 된다. (리액트의 `useTransition`과 다름 주의)

```jsx
// app/routes/contact.tsx

export const action: ActionFunction = async ({ request }) => {
  /*...*/
}

export default function ContactPage() {
  // 서버의 에러를 JSON 형태로 받을 수 있음. 이 경우에는 페이지를 리로드 하지 않고도 form을 리렌더링 할 수 있음
  const errors = useActionData()
  // form 성공시
  const { submission } = useTransition()
  return submission ? (
    <Confirmation contact={Object.fromEntries(submission.formData)} />
  ) : (
    <Form method="post">...</Form>
  )
}
```

서버사이드에서는 여전히 validation을 수행하지만, 이제 빠르게 클라이언트에서 피드백을 반영할 수 있다. 클라이언트 측에서 validation을 하고 싶을 경우, 추가적으로 로직을 추가하여 클라이언트에서 validation을 실행할 수 있다.

다만 이 경우 클라이언트가 JSON 데이터 fetch를 수행하거나, 자바스크립트를 아직 사용할 수 없는 경우 전체 html 응답을 요청하여 서버와 통신할 수 있다는 점이다.

## 항상 SSR

remix는 항상 서버사이드 렌더링이 일어나며, 특정 페이지가 정적으로 생성되는 것을 표시하는 개념을 지원하지 않는다. 그렇다고 정적 사이트를 만들 수 없다는 것은 아니다.

기본적인 측면에서, 서버 사이드 데이터 fetch 및 렌더링 속도가 충분하게 빠를 경우, edge server에 배치하여 정적 사이트 수준의 성능을 달성할 수 있다. (자세한 방법은 하단 예시를 참조)

그러나 이 방법은 언제나 가능한 것은 아니고, 페이지가 본질적으로 느린 백엔드 서비스에 의존할 수 있다. 이 경우 http 캐시를 활용할 수 있다. CDN을 서비스 인프라 최상단에 두고, 올바른 `Cache-Control` 헤더를 사용하면 CDN이 지연 시간을 최소화 하면서 변경되지 않은 콘텐츠를 저장하고 제공할 수 있다.

이를 통해 정적 사이트 빌드를 수행하는 대신, 변경 사항을 즉시 재구현 할 수 있다는 이점이 있다.

```jsx
// app/routes/some-page.tsx

export function headers() {
  return {
    'Cache-Control':
      'public, max-age=300, s-maxage=3600, stale-while-revalidate=300',
  }
}

export default function SomePage() {
  return <div>...</div>
}
```

이는 트레이드 오프가 있다. 직접적으로 프레임워크 수준에서 제어되는 invalidation을 포기하는 대신, CDN에 있는 전용 cache flushing 로직에 의존해야 한다. 사용자의 브라우저에서 캐시를 무효화하는 것 또 고려해야 하므로, 캐시 만료에 너무 지나치게 적극적으로 대응하지 않는 것이 좋다.

## hydration

Nextjs에서 달성하고자 하는 기능 중 하나는 부분적인 hydration이다. 특히 정적인 컨텐츠의 경우, 리액트 SSR/SSG 프레임워크는 필요한 자바스크립트 번들 보다 훨씬 더 많이 전달되고 hydration 되므로, 페이지 로드 성능에 큰 영향을 미칠 수 있다.

Remix는 개발자에게 언제 hydration이 일어날 수 있는지 결정할 수 있게 해준다. 하지만 현재는 페이지 단위로만 제공되고 있다. 이 방법은 조건부로 `Document` 내부의 `<Scripts/>`를 렌더링 하지 않는 것이다.

https://remix.run/docs/en/v1/guides/disabling-javascript

```jsx
// app/entry.server.tsx

import React from 'react'
import { Meta, Links, Scripts, Outlet, useMatches } from 'remix'

export default function App() {
  let matches = useMatches()

  // 아래 코드 참조
  let includeScripts = matches.some((match) => match.handle?.hydrate)

  // includeScripts 상태 값으로 제어 가능
  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <Meta />
        <Links />
      </head>
      <body>
        <Outlet />
        {/* 스크립트 제어! */}
        {includeScripts && <Scripts />}
      </body>
    </html>
  )
}
```

```jsx
// app/routes/some-page.tsx

export let handle = { hydrate: true }

export default function SomePage() {
  return <div>...</div>
}
```

Remix 개발자가 현재 부분적인 hydration을 할 수 있는 방안에 대해서 아주 깊게 연구 하고 있다고 하니 기대해봄직하다.

## 스타일

스타일을 적용하기 위해서는, header에 링크를 추가하면 된다. 이는 HTML 에 스타일 시트를 추가하는 것과 매우 유사하다. remix에 이러한 스타일 정보를 미리 제공하면, 모든 CSS를 캐시 가능한 스타일 시트 URL과 함께 병렬로 로딩할 수 있으므로, `prefetch`와 함께 사용한다면 최적의 페이지 로드 성능을 얻을 수 있다.

> 이와 관련되서 스타일 순서가 보장되지 않는 nextjs의 오랜 버그가 있다. https://github.com/vercel/next.js/issues/16630

```jsx
// app/routes/some-page.tsx

import styles from '~/styles/global.css'
// styles is now something like /build/global-AE33KB2.css

export function links() {
  return [
    {
      rel: 'stylesheet',
      href: 'https://unpkg.com/modern-css-reset@1.4.0/dist/reset.min.css',
    },
    {
      rel: 'stylesheet',
      href: styles,
    },
  ]
}

export default function SomePage() {
  return <div>...</div>
}
```

https://remix.run/docs/en/v1/guides/styling

위 가이드를 보면 알겠지만, scss, css, css-in-js를 사용해도 `links`를 통해서 스타일을 노출 시키는 것은 필수사항이다.

## 파일 기반 라우팅

remix는 nextjs를 사용하는 사람에게 매우 친숙한 파일 기반 라우팅을 사용한다. 그러나 nextjs 와 다르게 경로를 계층으로 구성할 수 있는 React Router 스타일의 중첩을 지원한다.

예를 들어, 아래와 같은 라우팅이 있다고 가정해보자.

- `/dashboard`
- `/dashboard/settings`
- `/dashboard/reports`

```jsx
// app/routes/dashboard.tsx

export default function DashboardLayout() {
  return (
    <div>
      <Header />
      {/* 내부 중첩 라우팅에 필요한 컨텐츠가 들어간다. */}
      <Outlet />
      <Footer />
    </div>
  )
}
```

```jsx
// app/routes/dashboard/settings.tsx
export default function Settings() {
  // ...
}
```

```jsx
// app/routes/dashboard/reports.tsx
export default function Reports() {
  // ...
}
```

```jsx
// app/routes/dashboard/index.tsx
export default function DashboardMain() {
  // ...
}
```

nextjs와 마찬가지로 remix는 isomorphic routing을 지원하므로 js에 hydration이 발생한다면 클라이언트에서 전환이 빠르게 일어난다.

## 경로 위치에 있는 데이터 가져오기

nextjs에서는 페이지 내부의 `getStaticProps` 또는 `getServerSideProps`에서 데이터를 가져올 수 있다. remix에서는 nextjs와 같은 방식으로 페이지 라우팅에 필요한 `loader` 함수를 사용할 수 있다. 마찬가지로, SSR 응답에 JSON으로 이 데이터를 직렬화한다.

```jsx
// app/routes/mypage.tsx

// 데이터를 가져온다. 이는 서버에서 수행된다.
export async function loader() {
  return fetch(/*...*/)
}

export default function MyPage() {
  const data = useLoaderData()
  return <div />
}
```

그러나 remix의 `loader`가 다른 점은 페이지 레벨 뿐만 아니라 중첩 라우팅에서도 사용이 가능하다는 것이다.

이것의 이점은, 데이터를 배치하는 것이 용이 해진다는 것이다. 예를 들어 `/dashboard`라는 루트 라우팅이 있을 경우, 하위 라우팅에 공통 페이지 레이아웃을 렌더링 할 수 있다는 것이다.

```jsx
export async function loader() {
  return getCurrentUser()
}

export default function DashboardLayout() {
  const currentUser = useLoaderData()
  return (
    <div>
      <Header>
        <UserAvatar user={currentUser} />
      </Header>
      {/* 하위 렌더링 페이지가 여기에 배치된다. */}
      <Outlet />
      <Footer />
    </div>
  )
}
```

그리고 ` /dashboard/settings` 에 또다른 `loader`가 있다고 가정해보자. 루트는 이에 대해 관심이 없으며, 마찬가지로 다른 페이지에서도 이에 대해 가지고 있을 필요가 없다. nextjs에서는 `getServerSideProps`의 일부를 분산하여 이를 수동으로 구현할 수 있지만, remix는 좀더 자연스러운 지원을 제공한다.

```jsx
// parent route
import { Outlet } from 'remix-utils'

export default function Parent() {
  return <Outlet data={{ something: 'here' }} />
}
```

```jsx
// child route
import { useParentData } from 'remix-utils'

export default function Child() {
  const data = useParentData()
  return <div>{data.something}</div>
}
```

이러한 분산된 fetch 설계는 스타일 시트의 링크와 마찬가지로, remix가 전체 트리의 데이터 의존성을 미리 알고 있기 때문에 별렬로 실행할 수 있다는 장점이 있다.

## 배포

remix는 vercel, cloudflare worker, deno deploy, fly.io와 같은 다양한 배포 환경을 지원한다. 각 배포에는 프로젝트 별로 약간 다른 구성 및 패키지가 필요할 수 있겠지만, 노드 환경과 비노드 환경 (cloudflare)에서 모두 실행 가능하다.

특정 배포 대상에 따른 remix 설정은 `create-remix`를 사용할 때 자동으로 구성되지만, 기본 설정에서 다른 설정으로 옮겨갈 경우에는 약간의 수정을 추가하면 된다.

## 기타

- remix 내부에는 세션과 쿠키를 처리할 수 있는 함수가 내장되어 있으며, 이는 클라이언트 서버 아키텍쳐에서 중요하다.
- `app/routes/reports/$report.tsx` 형태의 동적 라우팅을 지원한다. nextjs는 `[param]`, remix는 `$param`이다.
  ```jsx
  export default function Report() {
    // ...
    return <div>...</div>
  }
  ```
- nextjs 에 글로벌 `App` `Document` Wrapper가 있다면, remix에는 `entry.server.tsx`가 있다. 또한 `entry.client.tsx`를 사용하여 hydration과정에서 정확히 어떤일이 일어나는지 확인할 수 있다.
- nextjs에 있지만 remix에 없는 것은
  - 이미지 최적화 컴포넌트 `next/image`
  - 구글 폰트와 Typekit를 위한 자동 폰트 CSS 인라이닝
  - 스크립트 스케쥴링 및 우선순위 지정과 같은 세부적인 제어

## 느낀점

- react-router-dom 스타일의 중첩 routing 지원, 그리고 부모 데이터를 불러올 수 있는 기능이 인상적이다. nextjs는 페이지별로 다 찢어져있어서 특정 페이지들을 위한 context 구현이 opt-out 하지 않는 이상 불가능 했는데 이점은 굉장히 맘에 든다.
- static한 페이지가 많은 애플리케이션은 여전히 nextjs가 더 좋은 방식을 제공하고 있는 것 같다. CDN과 cache를 사용하는 것은 물론 기존에 있는 접근이지만 서도, nextjs가 더 편리한 방식으로 구현했다고 본다.
- 기본적으로 ssr이라는 점은 좋은 것 같다. 프론트엔드 개발자들이 static 파일을 upload하고 서빙하는 시대는 지났다. 이제 node 서버, 더 나아가 배포와 devOps에 대해서도 고민해야할 때가 왔다. (사실 진작에 왔다)
- 위와 마찬가지로, SPA의 패러다임은 이제 조금씩 쇠퇴하고 있는 느낌이다. 기기의 성능이 갈수록 좋아지는 시대일 수록 SPA가 빛을 발한다는 이야기를 들었던 것 같은데 이제 틀린게 아닌가 싶다. 성능을 사용자의 기기에 의존해서는 안된다.
- javascript가 실행되지 않는 환경을 고민하는 것 또한 인상적이다. 성능 측면에서 우리가 항상 고민해봐야할 문제다.
- 다음 토이 프로젝트는 remix다.


늘 새로워 짜릿해 새로운게 또 나왔어

Remix nextjs와 비교하면서 살펴보기

[여기](/2022/02/docker-best-practice-2022) 에서 이어집니다.

하단 권장사항은 효율적이고 유지관리가 용이한 `Dockerfile`을 만드는데 도움이 되도록 제공되었다.

## Table of Contents

## `FROM`

[https://docs.docker.com/engine/reference/builder/#from](https://docs.docker.com/engine/reference/builder/#from)

가능하면, 현재 제공되고 있는 공식 이미지를 사용하는 것이 좋다. 알파인 이미지는 리눅스 배포 판 중에서 크키가 매우작고 (6mb) 엄격하게 관리되고 있기 때문에 사용을 추천한다.

## `LABEL`

[https://docs.docker.com/config/labels-custom-metadata/](https://docs.docker.com/config/labels-custom-metadata/)

이미지에 레이블을 추가하여 프로젝트별 이미지 구성, 라이센스 정보 기록, 자동화 정보 등 기타 여러가지 정보를 기록할 수 있다. 각 레이블은 `LABEL`로 시작하고, 하나 이상의 키-값 쌍으로 추가하면 된다.

공백이 있는 문자열은 따옴표로 묶거나 공백을 이스케이프 해야 한다. (`''` 도 마찬가지다.)

```Dockerfile
# Set one or more individual labels
LABEL com.example.version="0.0.1-beta"
LABEL vendor1="ACME Incorporated"
LABEL vendor2=ZENITH\ Incorporated
LABEL com.example.release-date="2015-02-12"
LABEL com.example.version.is-production=""
```

모든 이미지는 레이블을 하나 이상 가지고 있을 수 있다. Docker 1.10 이전 버전에서는, 추가적인 레이어가 생성되지 않도록 여러 레이블을 하나의 `LABEL`로 묶는 것이 권장되었다. 이제 더이상 필요하진 않지만 여전히 여러개를 결합하는 방식은 가능하다.

```Dockerfile
# Set multiple labels on one line
LABEL com.example.version="0.0.1-beta" com.example.release-date="2015-02-12"
```

```Dockerfile
# Set multiple labels at once, using line-continuation characters to break long lines
LABEL vendor=ACME\ Incorporated \
      com.example.is-beta= \
      com.example.is-production="" \
      com.example.version="0.0.1-beta" \
      com.example.release-date="2015-02-12"
```

- [https://docs.docker.com/config/labels-custom-metadata/](https://docs.docker.com/config/labels-custom-metadata/)
- [https://docs.docker.com/engine/reference/builder/#label](https://docs.docker.com/engine/reference/builder/#label)

## `RUN`

[https://docs.docker.com/engine/reference/builder/#run](https://docs.docker.com/engine/reference/builder/#run)

길거나 복잡한 `RUN` 구문은 백슬래시를 활용하여 여러줄로 분할하는 것이 `Dockerfile` 관리에 좋다.

### `apt-get`

`RUN`에서 아마 가장 자주 사용되는 명령어는 `apt-get`일 것이다. `RUN apt-get`은 패키지를 설치하는 명령어이기 때문에 몇가지를 고려 해야 한다.

`RUN apt-get update` 와 `apt-get install`은 항상 같은 `RUN`구문 안에 있어야 한다.

```Dockerfile
RUN apt-get update && apt-get install -y \
    package-bar \
    package-baz \
    package-foo  \
    && rm -rf /var/lib/apt/lists/*
```

`apt-get update`를 `RUN`구문에서 단독으로 쓰면 캐시 문제가 있을 수 있고, 이어지는 `apt-get install`가 실패할 가능성도 있다. 예를 들면

```Dockerfile
# syntax=docker/dockerfile:1
FROM ubuntu:18.04
RUN apt-get update
RUN apt-get install -y curl
```

이미지가 빌드된 이후에, 모든 레이어가 도커 캐시안에 들어가게 된다. `apt-get install` 뒤에 구문을 추가했다고 가정해보자.

```Dockerfile
# syntax=docker/dockerfile:1
FROM ubuntu:18.04
RUN apt-get update
RUN apt-get install -y curl nginx
```

도커는 이전 명령어와 수정된 명령어가 동일 할 때에만 이전단계의 캐시를 사용한다. 따라서 빌드가 캐신된 버전을 사용하기 때문에 `apt-get update`가 실행되지 않는다. 그러므로 이 빌드는 잠재적으로 오래된 버전의 `curl`과 `nginx` 패키지를 얻게되는 결과를 초래할 수 있다.

`RUN apt-get update && apt-get install -y` 를 수행하면, 도커파일이 더이상의 코딩이나 수동작업 없이 최신 패키지 버전을 설치할 수 있다. 이 기술을 `cache busting`이라고 한다. 패키지 버전을 지정하여 이 캐시버스팅을 수행할 수도 있다.

```Dockerfile
RUN apt-get update && apt-get install -y \
    package-bar \
    package-baz \
    package-foo=1.3.*
```

버전을 이런식으로 고정하면 캐시에 무엇이 있든 상관없이 특정 버전을 검색하도록 강제할 수 있다. 또한 이 기술을 사용하면 예기치 않은 필수 패키지의 버저닝으로 인한 장애를 줄일 수 있다.

아래는 모든 적절한 권장사항을 잘 수행한 예시다.

```Dockerfile
RUN apt-get update && apt-get install -y \
    aufs-tools \
    automake \
    build-essential \
    curl \
    dpkg-sig \
    libcap-dev \
    libsqlite3-dev \
    mercurial \
    reprepro \
    ruby1.9.1 \
    ruby1.9.1-dev \
    s3cmd=1.1.* \
 && rm -rf /var/lib/apt/lists/*
```

`s3cmd`는 `1.1.*` 버전을 사용하도록 했다. 이미지가 만약 이전 버전을 사용하고, 새로운 버전을 지정하면 `apt-get update`에 캐시 버스팅을 발생시키고 새로운 버전을 설치한다. 각 라인에 패키지를 나열하면 패키지가 중복되는 오류도 방지할 수 있다.

또한 `/var/lib/apt/lists`를 제거하여 캐시를 적절히 정리하면 캐시가 레이어에 저장되지 않기 때문에 이미지 용량을 줄일 수 있다. `RUN` 구문은 `apt-get update`와 함께 시작하므로, 패키지 캐시는 항상 `apt-get install` 전에 정리될 것이다.

> Debian Ubuntu에서는 자동으로 `apt-get clean`을 수행해주므로 이럴 필요가 없다.

### `Pipe`

몇 몇 `RUN` 커맨드는 `|`에 의존하여 동작할 수 있다. 예를 들어

```Dockerfile
RUN wget -O - https://some.site | wc -l > /number
```

도커는 `/bin/sh -c` 커맨드를 사용하여, 이러한 명령어를 실행한다. 이 명령어는 마지막 작업의 종료코드만 확인하여 성공 실패 여부를 결정한다. 위의 예제에서 살펴보면, 이 빌드 단계는 `wget` 명령어가 실패하더라도, `wc -l` 명령어가 성공하면 새로운 이미지를 만들어 낼 것이다.

파이프의 어느 단계에서든 오류로 인해 명령이 실패하도록 하려면, `set -o pipefail &&`를 앞에 추가하면 된다.

```Dockerfile
RUN set -o pipefail && wget -O - https://some.site | wc -l > /number
```

> 모든 쉘이 `-o pipefail`을 제공하는 것은 아니므로, 아래와 같이 별도로 나눠서 실행해야 할 수도 있다.

```Dockerfile
RUN ["/bin/bash", "-c", "set -o pipefail && wget -O - https://some.site | wc -l > /number"]
```

## `CMD`

[https://docs.docker.com/engine/reference/builder/#cmd](https://docs.docker.com/engine/reference/builder/#cmd)

`CMD` 는 나열되어 있는 인수와 함께, 이미지에 포함되어 있는 소프트웨어를 실행하는데 사용된다. CMD는 거의 대부분 항상 `["실행 파일", "param1", "param2"...]` 와 같은 형태로 사용되어야 한다.

대부분의 경우, `CMD`는 bash, paython, perl과 같은 대화형 셸이 필요하다. 예를들어 `CMD ["perl", "-de0"]`, CMD `["python"]`, or CMD `["php", "-a"]` 등이 있다. 이러한 형태를 사용하면, `docker run -it python`고과 같은 것을 실행하면 바로 셸로 진입할 수 있다.

## `EXPOSE`

[https://docs.docker.com/engine/reference/builder/#expose](https://docs.docker.com/engine/reference/builder/#expose)

`EXPOSE`는 컨테이너가 연결을 받는 포트를 나타낸다. 따라서 애플리케이션에서 공통으로 사용되는 기존 포트를 사용해야 한다. (아파치 `EXPOSE 80`, 몽고 디비 `EXPOSE 27017`과 같이)

외부에서 접근을 위해 `docker run`에 플래그를 사용하여 이 포트가 어떤 포트에 연결될지 지정할 수 있다.

## `ENV`

[https://docs.docker.com/engine/reference/builder/#env](https://docs.docker.com/engine/reference/builder/#env)

`ENV`를 사용하여 컨테이너가 설치하는 소프트웨어의 PATH 환경변수를 업데이트 할 수 있다. 예를 들어, `ENV PATH=/usr/local/nginx/bin:$PATH`는 `CMD ["nginx"]` 명령어가 실행될 수 있도록 해준다.

또한 Postgres의 `PGDATA`와 같이 컨테이너에 포함하려는 서비스와 관련된 필수 환경변수를 제공하는데 유용하다.

마지막으로, `ENV`는 일반적으로 사용되는 버전 번호를 설정하기 위해 사용할 수도 있다.

```Dockerfile
ENV PG_MAJOR=9.3
ENV PG_VERSION=9.3.4
RUN curl -SL https://example.com/postgres-$PG_VERSION.tar.xz | tar -xJC /usr/src/postgres && …
ENV PATH=/usr/local/postgres-$PG_MAJOR/bin:$PATH
```

프로그램에 상수값이 있는 것과 비슷하게, `ENV`를 사용하면 자동적으로 컨테이너 내부의 소프트웨어 버전을 지정하는 것도 가능하다.

각 `ENV` 라인은 `RUN`과 동일하게 새로운 중간 레이어를 생성한다. 즉, 이후 레이어에서 환경변수를 설정해제하더라도, 이 레이어에서 계속 유지되며 해당 값이 덤프될 수 있다.

```Dockerfile
# syntax=docker/dockerfile:1
FROM alpine
ENV ADMIN_USER="mark"
RUN echo $ADMIN_USER > ./mark
RUN unset ADMIN_USER
```

```shell
$ docker run --rm test sh -c 'echo $ADMIN_USER'

mark
```

이러한 사태를 방지하고, 환경 변수를 실제로 해지 하기 위해서는 `RUN`을 사용하여 변수를 단일 레이어에서 설정, 사용, 해제를 하면 된다. 이 명령어는 `;` `&&`을 사용하여 구분할 수 있다. 후자를 사용한다면, 명령이 실패한다면 도커 빌드도 실패한다.

```Dockerfile
# syntax=docker/dockerfile:1
FROM alpine
RUN export ADMIN_USER="mark" \
    && echo $ADMIN_USER > ./mark \
    && unset ADMIN_USER
CMD sh
```

## `ADD` or `COPY`

- [https://docs.docker.com/engine/reference/builder/#add](https://docs.docker.com/engine/reference/builder/#add)
- [https://docs.docker.com/engine/reference/builder/#copy](https://docs.docker.com/engine/reference/builder/#copy)

`ADD` `COPY` 두 명령어가 기능적으로 거의 유사하지만, `COPY`가 일반적으로 더 사용된다. 그 이유는 `ADD` 보다 더 순수하기 때문이다. `COPY`는 단순히 컨테이너에 있는 로컬 파일을 복사할 뿐이다. 반면 `ADD`는 몇가지 추가적이 있다. (로컬 전용 tar 파일 해제, 원격 URL 지원 등) 따라서 `ADD`는 `ADD rootfs.tar.xz /` 와 같은 상황에서 사용하는 것이 좋다.

컨텍스트에서 다른 파일을 사용하는 여러 단계가 `Dockerfile` 내부에 있을 경우, 한번에 하지말고 개별적으로 복사하는 것이 좋다. 이렇게 하면 각 단계의 빌드 캐시는 필요한 파일이 변경되었을 경우에만 무효화 (재실행)된다.

예를 들어

```Dockerfile
COPY requirements.txt /tmp/
RUN pip install --requirement /tmp/requirements.txt
COPY . /tmp/
```

`COPY . /tmp/` 를 앞에 두는 경우보다 캐시 무효화가 더 줄어든다.

이미지 크기는 중요한 문제이므로, 원격 URL에서 패키지를 가져올때는 `ADD`를 사용하는 것은 권장되지 않는다. 대신 `curl` `wget`을 사용해야 한다. 이렇게 하면 파일 압축을 해제한 후 더이상 필요 없는 파일을 삭제할 수 있으며, 이미지에 다른 레이어를 추가할 필요가 없다. 예를 들어, 아래와 같은 경우는 피해야 한다.

```Dockerfile
ADD https://example.com/big.tar.xz /usr/src/things/
RUN tar -xJf /usr/src/things/big.tar.xz -C /usr/src/things
RUN make -C /usr/src/things all
```

이 대신,

```Dockerfile
RUN mkdir -p /usr/src/things \
    && curl -SL https://example.com/big.tar.xz \
    | tar -xJC /usr/src/things \
    && make -C /usr/src/things all
```

자동 tar 파일 압축 해제 기능 등이 필요하지 않은 다른 항목 (파일, 디렉토리) 에는 `COPY`를 쓰자.

## `ENTRYPOINT`

[https://docs.docker.com/engine/reference/builder/#entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint)

`ENTRYPOINT`를 쓰는 가장 좋은 방법은 이미지의 메인 커맨드를 설정해두어, 해당 명령어를 기본으로 사용할 수 있게 하는 것이다.

```Dockerfile
ENTRYPOINT ["s3cmd"]
CMD ["--help"]
```

이렇게 하면 아래와 같이 실행했을 때 도움말을 볼 수 있다.

```shell
docker run s3cmd
```

혹은 파라미터를 바로 두어서 바로 커맨드를 실행할 수도 있다.

```shell
docker run s3cmd ls s3://mybucket
```

`ENTRYPOINT` 명령은 helper 스크립트와 함께 사용할 수 있으므로, 특정 tool 을 시작할때 위의 명령어와 유사한 방식으로 동작할 수도 있다.

예를 들어, [Postgres 공식 이미지](https://hub.docker.com/_/postgres/)는 다음 스크립트를 `ENTRYPOINT`로 사용한다.

```Dockerfile
#!/bin/bash
set -e

if [ "$1" = 'postgres' ]; then
    chown -R postgres "$PGDATA"

    if [ -z "$(ls -A "$PGDATA")" ]; then
        gosu postgres initdb
    fi

    exec gosu postgres "$@"
fi

exec "$@"
```

helper 스크립트는 컨테이너에 복사되고, 컨테이너 시작시 `ENTRYPOINT`에 의해 실행된다.

```Dockerfile
COPY
Learn more about the "COPY" Dockerfile command.
 ./docker-entrypoint.sh /
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["postgres"]
```

이 스크립트는 유저가 Postgres를 다양한 방식으로 상호작용할 수 있도록 해준다.

단순히 Postgres를 실행할수도 있고

```shell
 docker run postgres
```

서버에 파라미터를 전달하여 실행할 수도있고

```shell
 docker run postgres postgres --help
```

또한 Bash와 같은 완전히 다른 툴에서도 실행할 수 있다.

```shell
 docker run --rm -it postgres bash
```

## `VOLUME`

[https://docs.docker.com/engine/reference/builder/#volume](https://docs.docker.com/engine/reference/builder/#volume)

`VOLUME`은 도커 컨테이너에서 만든 데이터 저장소 영역, 설정 저장소, 또는 파일이나 폴더를 노출하는데 사용해야 한다. 이미지의 변경 가능한 부분 및 사용자가 수정가능한 부분에는 `VOLUME`을 사용하는 것이 좋다.

## `USER`

[https://docs.docker.com/engine/reference/builder/#user](https://docs.docker.com/engine/reference/builder/#user)

서비스를 실행하는데 별도로 권한이 필요 없다면, `USER` 를 사용하여 루트가 아닌 사용자로 변경해야 한다. `RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres`와 같은 명령어로 유저나 그룹을 생성할 수 있다.

`sudo`는 문제를 일으킬 여지가 있으므로 사용하지 않는 것이 좋다. 그럼에도 `sudo`가 어쩔 수 없이 필요한 경우 [gosu](https://github.com/tianon/gosu)의 사용을 고려해보자.

마지막으로, 레이어와 복잡성을 줄이기 위해서는 너무 자주 `USER`를 사용하지 않는 것이 좋다.

## `WORKDIR`

[https://docs.docker.com/engine/reference/builder/#workdir](https://docs.docker.com/engine/reference/builder/#workdir)

명확성, 그리고 신뢰성을 위해 `WORKDIR`은 항상 절대 경로를 사용해야 한다. 읽기 어렵고, 유지보수도 어려운 `RUN cd … && do-something` 대신 `WORKDIR`을 사용하자.

## `ONBUILD`

[https://docs.docker.com/engine/reference/builder/#onbuild](https://docs.docker.com/engine/reference/builder/#onbuild)

`ONBUILD` 명령은 현재 `Dockerfile`의 빌드가 완료된 후 실행된다. `ONBUILD`는 현재 이미지에서 파생된 하위 이미지에서 실행된다. `ONBUILD` 명령은 상위 `Dockerfile`이 하위 `Dockerfile`에 제공하는 명령이라고 보면 된다.

도커는 하위 Dockerfile의 명령에 앞서 `ONBUILD`를 수행한다.

`ONBUILD`는 지정된 이미지에서 빌드할 이미지가 필요할 때 유용하다. 예를 들어, `Dockerfile`내에서 해당 언어로 소프트웨어를 필요로 하는 이미지가 있다면, `ONBUILD` 명령어가 유용하다.

`ONBUILD`로 빌드된 이미지에는 별도 태그가 있어야 한다. (`ruby:1.9-onbuild` `ruby:2.0-onbuild`)

`ONBUILD`에 `ADD` `COPY`를 넣을 때 주의하자. 새 빌드 컨텍스트에 이렇게 추가되는 리소스가 없을 경우 하위 "onbuild" 이미지가 실패할 것이다. 위에서 권장한대로 태그를 추가해서 구별하면, `Dockerfile` 작성자가 이를 선택할 수 있으므로 이러한 문제를 예방할 수 있다.


Page 6

Rust로 web assembly 만들어보기 (1) - Web Assembly란 무엇인가?

[Rust] 자바스크립트에서 러스트로 (1) - rustup, hello world, 그리고 소유권과 빌림

자바스크립트 3항연산자에 대한 고찰

Remix nextjs와 비교하면서 살펴보기

Dockerfile 작성 가이드