```javascript
function sayHello(name) {
 return new Promise((resolve, reject) => {
 setTimeout(() => resolve(`Hello, ${name}`), 2000)
 })
}

const message1 = await sayHello('yceffort')
console.log(message1)
```

요런 비동기 함수가 있고, 이를 map으로 처리한다고 가정해보자.

```javascript
const names = [
 'yceffort1',
 'yceffort2',
 'yceffort3',
 'yceffort4',
 'yceffort5',
 'yceffort6',
]

const messages = names.map(async (name) => await sayHello(name))
console.table(messages)
```

이렇게 하면 될 것 같지만?

```
(6) [Promise, Promise, Promise, Promise, Promise, Promise]
0: Promise {<pending>}
1: Promise {<pending>}
2: Promise {<pending>}
3: Promise {<pending>}
4: Promise {<pending>}
5: Promise {<pending>}
```

아쉽게도 모든 결과가 pending으로 뜬다. `await`은 `Promise` 객체만 기다려 주기 때문에 그런 것으로 보인다. 반변에 우리가 넘긴 것은 `list`다.

따라서 이를 정상적으로 실행하기 위해서는 `Promise.all`을 사용해야 한다.

```javascript
const promiseMessages = await Promise.all(
 names.map(async (name) => await sayHello(name)),
)
console.log(promiseMessages)
```

```javascript
;[
 'Hello, yceffort1',
 'Hello, yceffort2',
 'Hello, yceffort3',
 'Hello, yceffort4',
 'Hello, yceffort5',
 'Hello, yceffort6',
]
```

그렇다면 `reduce`의 경우에는 어떻게 처리하면 좋을까?

```javascript
const oddMessages = names.reduce(async (prev, current, index) => {
 if (index % 2 > 0) {
 return [...prev, await sayHello(current)]
 } else {
 return prev
 }
}, [])
```

이렇게 하면 당연히 안될 것이다. 여기에서 `prev`는 기존의 값이 아닌 `Promise`일 것이다.

```javascript
const oddMessages = await names.reduce(async (prev, current, index) => {
 const prevResult = await prev.then()
 if (index % 2 === 0) {
 const result = await sayHello(current)
 return Promise.resolve([...prevResult, result])
 } else {
 return Promise.resolve(prevResult)
 }
}, Promise.resolve([]))
```

기존에 있던 모든 return을 `Promise.resolve`로 감싸고, 이전에 넘어온 `prev`는 `then`처리를 했다.

```javascript
;['Hello, yceffort1', 'Hello, yceffort3', 'Hello, yceffort5']
```

map과 reduce에서 async await 사용하기

<pre class="language-javascript"><code class="language-javascript">function sayHello(name) {
 return new Promise((resolve, reject) => {
 setTimeout(() => resolve(`Hello, ${name}`), 2000)
 })
}

const message1 = await sayHello('yceffort')
console.log(message1)
</code></pre>
요런 비동기 함수가 있고, 이를 map으로 처리한다고 가정해보자.
<pre class="language-javascript"><code class="language-javascript">const names = [
 'yceffort1',
 'yceffort2',
 'yceffort3',
 'yceffort4',
 'yceffort5',
 'yceffort6',
]

const messages = names.map(async (name) => await sayHello(name))
console.table(messages)
</code></pre>
이렇게 하면 될 것 같지만?
<pre><code>(6) [Promise, Promise, Promise, Promise, Promise, Promise]
0: Promise {&#x3C;pending>}
1: Promise {&#x3C;pending>}
2: Promise {&#x3C;pending>}
3: Promise {&#x3C;pending>}
4: Promise {&#x3C;pending>}
5: Promise {&#x3C;pending>}
</code></pre>
아쉽게도 모든 결과가 pending으로 뜬다. <code>await</code>은 <code>Promise</code> 객체만 기다려 주기 때문에 그런 것으로 보인다. 반변에 우리가 넘긴 것은 <code>list</code>다.
따라서 이를 정상적으로 실행하기 위해서는 <code>Promise.all</code>을 사용해야 한다.
<pre class="language-javascript"><code class="language-javascript">const promiseMessages = await Promise.all(
 names.map(async (name) => await sayHello(name)),
)
console.log(promiseMessages)
</code></pre>
<pre class="language-javascript"><code class="language-javascript">;[
 'Hello, yceffort1',
 'Hello, yceffort2',
 'Hello, yceffort3',
 'Hello, yceffort4',
 'Hello, yceffort5',
 'Hello, yceffort6',
]
</code></pre>
그렇다면 <code>reduce</code>의 경우에는 어떻게 처리하면 좋을까?
<pre class="language-javascript"><code class="language-javascript">const oddMessages = names.reduce(async (prev, current, index) => {
 if (index % 2 > 0) {
 return [...prev, await sayHello(current)]
 } else {
 return prev
 }
}, [])
</code></pre>
이렇게 하면 당연히 안될 것이다. 여기에서 <code>prev</code>는 기존의 값이 아닌 <code>Promise</code>일 것이다.
<pre class="language-javascript"><code class="language-javascript">const oddMessages = await names.reduce(async (prev, current, index) => {
 const prevResult = await prev.then()
 if (index % 2 === 0) {
 const result = await sayHello(current)
 return Promise.resolve([...prevResult, result])
 } else {
 return Promise.resolve(prevResult)
 }
}, Promise.resolve([]))
</code></pre>
기존에 있던 모든 return을 <code>Promise.resolve</code>로 감싸고, 이전에 넘어온 <code>prev</code>는 <code>then</code>처리를 했다.
<pre class="language-javascript"><code class="language-javascript">;['Hello, yceffort1', 'Hello, yceffort3', 'Hello, yceffort5']
</code></pre>

일반적으로 캐싱은 데이터를 저장해두었다가, 다시 요청할 때 이를 요청하지 않고 저장한 데이터를 불러와서 성능을 향상시켜 요청이 더 빨리 처리되도록 한다. 예를 들어, 네트워크의 캐시된 리소스는 서버로 왔다리 갔다리 하는 일을 피할 수 있다. 캐시된 결과는 동일한 계산을 수행하는 것을 막을 수 있다. 크롬에서는, 이러한 캐싱을 위한 여러가지 메커니즘이 있으며, HTTP 캐시를 그중 하나로 예를 들 수 가 있다.

## Chrome 85 까지의 캐싱 동작

크롬 85 버전 까지는, 크롬은 네트워크로 부터 요청한 데이터를 캐싱하는데 있어서 각 리소스 URL을 캐시키로 활용했다. 아래 예를 살펴보자.

1. `https://a.example`에서 `https://x.example/doge.png`를 요청했다. 이 미지는 `https://x.example/doge.png`를 캐시키로 캐싱이 된다.
2. 1과는 다른 `https://b.example`에서 1과 동일한 이미지인 `https://x.example/doge.png`를 요청했다. 브라우저는 HTTP 캐시를 확인할 때 해당 미지 URL 키를 기준으로 검사하여 이 리소스가 캐시되었는지 확인한다. 1에서 이미 캐시를 했었으므로 캐시된 리소스 버전을 사용한다.
3. `https://c.example`에서 iframe 으로 `https://d.example`를 요청하고, 이 `https://d.example`에서 `https://x.example/doge.png` 를 요청했다고 가정해보자. 이 경우에도 마찬가지로 리소스 URL을 캐시키로 활용하기 때문에 캐싱된 이미지를 사용한다.

이러한 매커니즘은 성능이라는 관점에서 굉장히 잘 작동하므로 오랫동안 이용되어 왔다. 그러나 HTTP 요청에 응답하기 위해 웹 사이트가 필요로 하는 이 시간은, 과거 브라우저가 동일한 리소스에 액세스 했다는 것을 식별할 수 이으며, 이는 브라우저를 다음과 같은 보안 공격에 취약하게 만든다.

1. 유저가 특정한 사이트를 방문했는지를 식별할 수 있음: 공격자는 캐시에 특정 사이트 또는 사이트 cohort에 해당하는 리소스가 있는지 확인하여 사용자의 검색 기록을 탐지할 수 있다.
2. [크로스 사이트 검색 공격](https://portswigger.net/daily-swig/new-xs-leak-techniques-reveal-fresh-ways-to-expose-user-information): 공격자는 특정 웹 사이트에 사용하는 '검색 결과 없음' 이미지가 브라우저의 캐시에 있는지 확인하여, 사용자의 검색 결과에 특정 문자열이 있는지 여부를 확인할 수 있다.
3. 크로스 사이트 트래킹: 이 캐시를 사용하여 쿠키와 유사한 식별자를 크로스 사이트 트래킹 매커니즘으로 악용할 수 있다.

이런 이유 때문에, 크롬에서는 86부터 (사파리는 이미 적용된듯) 파티셔닝 HTTP 캐시 전략을 사용하기로 결정했다.

## 캐시 파티셔닝이 크롬 HTTP 캐시에 미치는 영향

캐시 파티셔닝을 사용하면, 캐시된 리소스는 리소스 URL 외에 추가로 'Network Isolation Key'를 활용하여 키를 만든다. 이 키는 최상위 사이트와 현재 프레임 사이트로 구성된다.

이 전략을 사용하면, 위의 예제가 아래처럼 바뀌게 된다.

1. `https://a.example`에서 `https://x.example/doge.png`를 요청한다. 이 경우 캐시키는 아래오 같이 구성될 것이다. (위에서 부터 top-level site, current-frame site, resource url)

```bash
{
  https://a.example,
  https://a.example,
  https://x.example/doge.png
}
```

2. `https://b.example`에서 `https://x.example/doge.png`를 요청한다. 1에서 같은 이미지를 요청했음에도 불구하고, 캐시 키가 일치하지 않기 때문에 캐시를 불러오지 않는다.

```bash
{
  https://b.example,
  https://b.example,
  https://x.example/doge.png
}
```

3. `https://a.example`에서 iframe으로 embedded 된 `https://a.example`를 불러오는 경우. 여기에서 같은 이미지 `https://x.example/doge.png` 를 요청했다고 가정해보자. 이 경우에는 캐시를 불러올 수 있다.

```bash
{
  https://a.example,
  https://a.example,
  https://x.example/doge.png
}
```

4. `https://a.example`에서 iframe으로 embedded 된 `https://c.example`를 불러오는 경우. 여기에 같은 이미지 리소스를 불러온 다 하더라도, frame이 다르기 때문에 캐시키를 불러올 수 없다.

```bash
{
  https://a.example,
  https://c.example,
  https://x.example/doge.png
}
```

5. `https://a.example`의 서브 도메인 `https://sub.a.example`에서 iframe으로 embedded 된 `https://c.example:8080`를 불러오는 경우. 이 경우엔 키는 `"scheme://eTLD+1"` 전략으로 생성되기 때문에, 4번에서 생성한 캐시를 가져올 수 있게 된다.

```bash
{
  https://a.example,
  https://c.example,
  https://x.example/doge.png
}
```

6. `https://a.example`에서 `https://b.example`를 embedded하고 또 이것이 `https://c.example`를 불러오는 경우. 이 경우에는 top-site 가 기준이므로 캐시키는 아래와 같이 생성되고, 이경우에도 4번의 캐시키를 히트 할 수 있다.

```bash
{
  https://a.example,
  https://c.example,
  https://x.example/doge.png
}
```

## 적용되었는지 확인하는 법

https://www.zdnet.com/article/chromes-new-cache-partitioning-system-impacts-google-fonts-performance/

1. `chrome://net-export/`로 진입해서 `Start Logging to Disk`를 누른다.
2. 로그를 저장할 위치를 고른다
3. 크롬에서 웹 서핑을 한다
4. 1번으로 돌아가서 로깅을 멈춘다.
5. https://netlog-viewer.appspot.com/#import 로 들어간다
6. 저장한 로그 파일을 업로드 한다.

`SplitCacheByNetworkIsolationKey`에서 `Experiment_`로 되어 있다면 파티셔닝 캐시가 활성화 되어 있는 것이다. `Control_`나 `Default_`는 활성화 되지 않은 것이다.

```bash
SplitCacheByNetworkIsolationKey:Experiment_Triple_Key_20201210
```

내 경우엔 활성화 되어 있었다.

## 테스트 하는법

크롬을 `--enable-features=SplitCacheByNetworkIsolationKey`와 [함께 실행하면 된다.](https://www.chromium.org/developers/how-tos/run-chromium-with-flags)

## 개발자가 취해야할 조치

breaking change는 아니지만, 일부 웹서비스의 성능에 대한 고려를 해볼 수 있다. 글꼴이나 인기 있는 스크립트를 제공하는 CDN 사이트의 경우 트래픽 요청이 증가할 수 있다.

> 예를 들어 google font를 사용한다고 해서 이제 웹 사이트의 성능적인 이점을 누릴 수 없다. 여기저기서 범용적으로 사용하는 google font를 사용한다 하더라도, 파티셔닝 캐시로 인해서 캐시를 히트하지 못하고, 이는 사이트 방문시에 같은 폰트를 다른 사이트에서 쓴적이 있다 하더라도 새롭게 받을 것이다. 따라서 그냥 google font를 쓰는 것보다 폰트나 리소스를 self-hosting 하는게 낫다.

## 성능에 미치는 영향

전체 캐시 누락률이 약 3.6% 정도 증가하고, FCP (First Contentful Paint)가 0.3%, 네트워크에서 로드되는 전체 바이트 비율이 4%정도 증가할 수 있다.

## 브라우저 별 차이

[HTTP cache partitions은 fetch 표준](https://fetch.spec.whatwg.org/#http-cache-partitions)이다. 그러나 브라우저 별로 약간의 차이가 있다.

- Chrome: top-level 과 프레임에 `scheme://eTLD+1`를 사용한다.
- Safari: top-level `scheme://eTLD+1`를 사용한다. [참고](https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/)
- Firefox: [적용 예정](https://bugzilla.mozilla.org/show_bug.cgi?id=1536058) top-level `scheme://eTLD+1`를 사용하며, 크롬처럼 2번째 키 사용을 고려중

출처: https://developers.google.com/web/updates/2020/10/http-cache-partitioning


Google Font 를 써도 이제 캐시 효과는 못받겠네요

파티셔닝 캐시 (partitioning cache)

2020년에도 많은 사이드 프로젝트를 진행했다. 대다수의 사이드 프로젝트는 웹 애플리케이션으로 제작했고, 서버와 프론트 데이터베이스를 구축했어야 했고, 이것들을 어떻게 구축했는지, 그리고 어떤 것을 느꼈는지 간단하게 요약하고자 한다.

## 개발환경

- nextjs
- react
- typescript (급할 땐 javascript도 함)
- firestore
- cloud functions
- github
- vercel
- styled component

### nextjs

nextjs는 Server Side React 환경을 구축하는데 있어서 필수적인 라이브러리로 자리잡은 것 같다. 비단 SSR 때문 만이 아니더라도, 라우팅을 하는데 있어서도 편하게 적용할 수 있었다. `/pages` 폴더 하단에 디렉토리 구조로 만 설정해두면, 알아서 라우팅을 구성하기 때문에 굉장히 좋았다.

다만 이 방법의 한계는 당연하게도 라우팅이 복잡해 질수록 디렉토리 관리가 어려워 진다는 것이다. 가령 path param으로 `/id`를 가져오기 위해서 `[id].js`를 만들어 두면, 이 파일을 찾는 것도 피곤하고 관리하기도 어려웠다.

![next-path](./images/next-path.png)

> `[id].js` 라는 파일이 많아지면,, 이제 감당할 수 없는 미래...

그래서 `api`에서는 귀찮아지니까 그냥 다 query param으로 가져오는 방식으로 변경해버렸다.

혹은 불가피 하게 라우팅이 복잡해지면, `koa`를 별도 서버를 둬서 페이지 분기를 여기에서 처리하도록 만들었다. 이는 이전 회사에서 즐겨 쓰던 방식으로, 굳이 복잡하게 디렉토리 구조를 만들지 않아도 되서 유용했다. (감사합니다.)

하지만 대부분의 사이드 프로젝트가 라우팅이 복잡했던 것은 아니므로, 이 방법은 많이 쓰지 않았다.

### react

jquery 부터 웹 개발을 해오면서, 이제는 react가 어느정도 front 개발의 표준으로 자리잡은 것 같다. 물론 이러한 react에 대한 아쉬움 내지는 성토의 글도 있었지만, 많은 수의 프로젝트들이 react로 쓰여지면서 커뮤니티가 커지고, 그에 따른 많은 편의성을 얻은 것도 사실이다. 나 또한 모든 사이드 프로젝트에서 웹 애플리케이션이 필요할 때 마다 리액트를 선택했고, 이는 탁월한 선택이었다. 이에 관해 흥미로운 글이 있었는데 한번 읽어보면 좋을 것 같다.

https://jake.nyc/words/no-one-ever-got-fired-for-choosing-react/

누구도, 리액트를 고른다고 해서 해고되는 것은 아니다.

> I have heard from many developers who have told me that they accepted the argument that vanilla JavaScript or microlibraries would let them write leaner, meaner, faster apps. After a year or two, however, what they found themselves with was a slower, bigger, less documented and unmaintained in-house framework with no community. As apps grow, you tend to need the abstractions that a framework offers. Either you or the community write the code.

### typescript

사실 타입스크립트가 협업을 하는 경우에 한해서 좋다고 생각해서, 초창기 사이드 프로젝트를 진행할 때에는 자바스크립트로 진행을 했었다. 물론 어느 정도 타입과 이런저런 제약에 벗어나서 정말 편리했고, 일정수준 프로젝트가 커지지 않는다면 생산성도 향상됐다.

문제는 내 스스로가 만든 데이터 구조가 복잡해지면서 내 머리로 조차 기억하지 못하고 급기야 버그를 만들기 시작했다는 것이었다. (오오 33살,,,) 그렇게 타입과 갖가지 버그로 인해 혼란을 겪고 나니, 이럴거면 초창기에 타입을 잘 선언해두고 프로젝트를 꾸몄다면 이런 혼선을 줄일 수 있었을 거라는 아쉬움이 남았다.

그래서 앞으로는 그냥 혼자 하든, 둘이 하든 지간에 타입스크립트로 진행하고자 마음먹었다. 잘 선언해둔 타입으로 프로젝트를 꾸미게 되면, 이후에 데이터 구조를 가져다 쓸 때도, 리팩토링을 할 때도 많은 도움을 얻을 것 같다.

### firestore

부끄럽고 미련하게도 초창기에는 SQL을 node와 연결해서 썼었다. 그러나 스키마 구성, 트랜잭션 관리, 테이블 관리 등을 겪고 나니 배보다 배꼽이 더 큰 느낌이었고, 빠르게 가져다 쓸 수 있는 NoSQL을 찾던 와중에 Firebase의 firestore 을 쓰기 시작했다. SQL 데이터 베이스를 구성하는데 걸린 시간을 제로에 가깝게 줄일 수 있었고, 데이터 관리 또한 JSON 형태로 아주 편하게 가져다 쓸 수 있었다.

다만 join 이나 or, in 과 같은 식의 복합쿼리는 안되기 때문에 어느 정도의 불편함을 감수해야 했다.

https://firebase.google.com/docs/firestore/query-data/queries?hl=ko

> Cloud Firestore는 다음 유형의 쿼리를 지원하지 않습니다.

> - 이전 섹션에서 설명한 것과 같이 여러 필드에 범위 필터가 있는 쿼리
> - 논리적 OR 쿼리: 이 경우 각 OR 조건에 해당하는 별도의 쿼리를 만들고 앱에서 쿼리 결과를 병합해야 합니다.
> - != 절을 사용하는 쿼리: 이 경우 쿼리를 초과 및 미만 쿼리로 분할해야 합니다. 예를 들어 where("age", "!=", "30") 쿼리 절은 지원되지 않지만 where("age", "<", "30") 절이 있는 쿼리 하나와 where("age", ">", 30) 절이 있는 쿼리 하나를 결합하면 동일한 결과 집합을 얻을 수 있습니다.

예컨데 장바구니와 같은 데이터 베이스를 꾸밀일이 있었는데, 이를 조회하기 위해서 불가피하게 2n 회로 데이터 조회를 요청할 수 밖에 없었다.

![firestore](./images/firestore-quota.png)

그러다 보니 개발 단계에서 마저도 읽기 횟수가 눈에 띄게 튀기 시작했다. 아직 눈에 띄게 document가 있지 않은 상태라 무료 수준에서 커버를 치고 있지만, document가 늘어 나면 이제 모든 쿼리를 쓰는데 신중에 신중을 기하게 될 것이다. (한번 읽기 마다 `0.06$`)

https://firebase.google.com/docs/firestore/pricing

없는 살림에 GCP를 이것저것 쓰고 있기 때문에 굉장히 덜덜덜 하고 있는데,, 부디 나에게 예산 알림이 오는날이 없었으면 한다. 그리고 그날이 온다면, mock을 잘만들어서, 쿼리를 잘만들어서 대처해보는 걸로...

### Cloud functions

cloud function은 slack, survey monkey, jandi 등의 웹 훅 용으로 유용하게 썼다. 함수 하나만 클라우드에 올려서 서버 없이 쓸 수 있기 때문에 굉장히 유용했다. firestore에 비해서 가격도 비교적 저렴해서 (그리고 애초에 많이 호출되는 함수도 아니었지만) 안심하고 여러 함수를 서버없이 잘 사용했다. 예전에 이거 하자고 인스턴스 따고 보안규칙 따고 생쇼를 했던 과거에 비하면, 너무나도 편리하다.

![cloud functions](./images/cloud-functions.png)

[최근에는 블로그 썸네일 생성기로도 사용하기도 했다.](https://yceffort.kr/2020/12/generate-serverless-thumbnail) 감사합니다. 다음엔 꼭 픽셀 폰 싸서 보답하겠습니다.

### vercel

heroku의 시대가 가고, 이제는 vercel 의 시대가 온 것 같다. 웹 애플리케이션을 프로덕션에 올리는 용도로는 망설임없이 vercel을 썼다. heroku에 비해 기능은 rich 하지 않지만 필요한 기능만 들어있고, (heroku는 너무 이것저것 많은 기분이다) 배포도 용이하며, 무엇보다 github 에 integration 할 수 있다는 점이 매력적이다.

https://github.com/yceffort/yceffort-blog-v2/pull/222#issuecomment-740369078

또한 가격도 heroku 보다 저렴했다. 웹 애플리케이션 당 가격이 아니고 한 member 당 가격을 책정하기 때문에 20달러에 프로 계정으로 나 혼자 잘 먹고 잘 쓰고 있다. (프로 계정은 최대 10명의 멤버, 50 도메인, 1000gb의 bandwidth 제한이 있다.)

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

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

### github

마이크로소프트에 인수된 뒤로 나날이 발전하고 있는 github 도 빼 놓을 수 없다. github action 덕분에 CI, CD 등도 편리하게 수행할 수 있었고, 각종 bot을 통해서 다양한 작업을 할 수 있었다. 또한 cron job 도 편리하게 이용할 수 없었다. 기존에는 클라우드에 인스턴스 띄워서 크론 설정하고, https://healthchecks.io/ 로 healthcheck 까지 확인했다면, 이제는 github action 하나면 충분하다.

또한 유용하게 썼던 것 중 하나는 github code spaces 다. 개발 환경이 불안정했던 외부에서도 인터넷만 연결되어 있다면, codespaces로 편리하게 개발을 할 수가 있었다.

pro 계정을 활용하면서 private repository도 자유롭게 꾸민 것이 개인적으로 많은 도움도 되었다. 내 작업물 대다수가 private 으로 되어 있어서 많은 코드를 세상과 공유(?) 하지 못했지만, 그래도 덕분에 각종 예민한 private key를 편하게 관리할 수 있었다.

올해에는 dark 모드 까지 지원되었는데, 앞으로도 github에서 더욱 rich한 기능을 지원해 줬으면 좋겠다.

### styled-component 그리고 css

css-in-js 에 대해서는 이제는 하나의 흐름이라고 개인적으로 생각했다.

- Global namespace
- Dependencies
- Dead Code Elimination
- Minification
- Sharing Constants
- Non-deterministic Resolution

하지만 지나가다가 본 글이 있는데, 보면서 이런저런 생각을 하게 됐다.

- https://blueshw.github.io/2020/09/27/css-in-js-vs-css-modules/
- https://blueshw.github.io/2020/09/14/why-css-in-css/

각자의 장단이 있는 것 같고, 글쓴이의 의도에도 적극 공감한다.

그러나 이와 별개로 문제는 내가 css에 대한 이해와 디자인 감각이 현저히 떨어진다는 것이다.🤪 내년에는 정녕 css를 공부해야 하는 것일까. 이쁘게는 못하더라도 (이미 디자인에 감각이 없다는 것을 블로그가 증명하고 있다), 기본적인 css에 대한 이해도 아직은 조금 부족하고, 더 공부해야 겠다는 생각이 든다.

## 마치며

일하는 회사에서 이것저것 새로운 최신의 기술, 내가 배웠던 다른 코드들을 모두 적용해 볼 수 있으면 정말 좋다. 돈도 받고, 공부도 하고, 개인적으로 성장도 할 수 있고 회사 연말 평가에 반영할 수도 있다.

그러나 아쉽게도 회사 업무에서 펼칠 수 있는 상상의 나래는 한정적이다. 기존에 쓰고 있는 기술은 한정적이고 뒤쳐져 있으며, 설득해야 하는 사람은 많고 새로운 것에 대한 반론 또한 존재한다. 이미 잘되고 있는 레거시가 있는데 굳이 왜? 그렇다고 내가 모든 책임을 다 안고 시도하기엔, 일단 나부터가 쫄린다. 로컬에선 잘됐는데? 알파에선 잘됐는데? 라는 변명으로 막을 것인가? 또한 개발자만 있는게 아니다. 기획자 분들도, 테스터 분들도, 그리고 높으신 양반들도 있다. 개발자 입장에서는 아무런 변화가 없는 코드라고 자신할 수 있지만, 그들의 눈에서는 테스트해야할 골칫거리가 하나 더 생기는 것 뿐일지도 모른다.

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

> 미안합니다,,,

이런 저런 이유로 미루어, 사이드프로젝트는 개발자로서의 성장, 그리고 킬링타임을 위해 필수인 것 같다. 비록 아무도 안보는 블로그지만, 그게 오히려 좋다. CSR을 SSR 바꾸고, 새로운 기술을 적용해보고 공부해 볼 수도 있고 트렌드에 뒤쳐지지 않을 수도 있다. 버그로 프로젝트가 망가져도 트래픽은 잃을 지언정 아무도 뭐라고 하지 않으며, 부담없이 새로운일을 해볼 수 있다. 개발자가 된 이후로 몇년만에 처음으로, 각종 컨퍼런스의 타이틀을 보고 '다 아는 기술이구만' 이라며 고개를 끄덕여 봤다.

새로운 기술, 코드가 있는데 회사에서 시도할 수가 없다? 회사에서 잘 만들어 놓은 사내 서비스 보다 AWS, GCP를 써보고 싶다? 체크카드를 꺼내서 payment를 등록하고 지금 당장 나만의 프로젝트를 만들어서 공부해보자. 기술은 많고, 내가 써본 것은 손에 꼽는다. 이대로 회사일만 하기엔, 밖에는 재밌는게 너무 많다.

2020년 사이드 프로젝트 회고

2020년에도 많은 사이드 프로젝트를 진행했다. 대다수의 사이드 프로젝트는 웹 애플리케이션으로 제작했고, 서버와 프론트 데이터베이스를 구축했어야 했고, 이것들을 어떻게 구축했는지, 그리고 어떤 것을 느꼈는지 간단하게 요약하고자 한다.
<h2 id="개발환경">개발환경</h2>
<ul>
<li>nextjs</li>
<li>react</li>
<li>typescript (급할 땐 javascript도 함)</li>
<li>firestore</li>
<li>cloud functions</li>
<li>github</li>
<li>vercel</li>
<li>styled component</li>
</ul>
<h3 id="nextjs">nextjs</h3>
nextjs는 Server Side React 환경을 구축하는데 있어서 필수적인 라이브러리로 자리잡은 것 같다. 비단 SSR 때문 만이 아니더라도, 라우팅을 하는데 있어서도 편하게 적용할 수 있었다. <code>/pages</code> 폴더 하단에 디렉토리 구조로 만 설정해두면, 알아서 라우팅을 구성하기 때문에 굉장히 좋았다.
다만 이 방법의 한계는 당연하게도 라우팅이 복잡해 질수록 디렉토리 관리가 어려워 진다는 것이다. 가령 path param으로 <code>/id</code>를 가져오기 위해서 <code>[id].js</code>를 만들어 두면, 이 파일을 찾는 것도 피곤하고 관리하기도 어려웠다.
<img src="./images/next-path.png" alt="next-path">
<blockquote>
<code>[id].js</code> 라는 파일이 많아지면,, 이제 감당할 수 없는 미래...
</blockquote>
그래서 <code>api</code>에서는 귀찮아지니까 그냥 다 query param으로 가져오는 방식으로 변경해버렸다.
혹은 불가피 하게 라우팅이 복잡해지면, <code>koa</code>를 별도 서버를 둬서 페이지 분기를 여기에서 처리하도록 만들었다. 이는 이전 회사에서 즐겨 쓰던 방식으로, 굳이 복잡하게 디렉토리 구조를 만들지 않아도 되서 유용했다. (감사합니다.)
하지만 대부분의 사이드 프로젝트가 라우팅이 복잡했던 것은 아니므로, 이 방법은 많이 쓰지 않았다.
<h3 id="react">react</h3>
jquery 부터 웹 개발을 해오면서, 이제는 react가 어느정도 front 개발의 표준으로 자리잡은 것 같다. 물론 이러한 react에 대한 아쉬움 내지는 성토의 글도 있었지만, 많은 수의 프로젝트들이 react로 쓰여지면서 커뮤니티가 커지고, 그에 따른 많은 편의성을 얻은 것도 사실이다. 나 또한 모든 사이드 프로젝트에서 웹 애플리케이션이 필요할 때 마다 리액트를 선택했고, 이는 탁월한 선택이었다. 이에 관해 흥미로운 글이 있었는데 한번 읽어보면 좋을 것 같다.
<a href="https://jake.nyc/words/no-one-ever-got-fired-for-choosing-react/">https://jake.nyc/words/no-one-ever-got-fired-for-choosing-react/</a>
누구도, 리액트를 고른다고 해서 해고되는 것은 아니다.
<blockquote>
I have heard from many developers who have told me that they accepted the argument that vanilla JavaScript or microlibraries would let them write leaner, meaner, faster apps. After a year or two, however, what they found themselves with was a slower, bigger, less documented and unmaintained in-house framework with no community. As apps grow, you tend to need the abstractions that a framework offers. Either you or the community write the code.
</blockquote>
<h3 id="typescript">typescript</h3>
사실 타입스크립트가 협업을 하는 경우에 한해서 좋다고 생각해서, 초창기 사이드 프로젝트를 진행할 때에는 자바스크립트로 진행을 했었다. 물론 어느 정도 타입과 이런저런 제약에 벗어나서 정말 편리했고, 일정수준 프로젝트가 커지지 않는다면 생산성도 향상됐다.
문제는 내 스스로가 만든 데이터 구조가 복잡해지면서 내 머리로 조차 기억하지 못하고 급기야 버그를 만들기 시작했다는 것이었다. (오오 33살,,,) 그렇게 타입과 갖가지 버그로 인해 혼란을 겪고 나니, 이럴거면 초창기에 타입을 잘 선언해두고 프로젝트를 꾸몄다면 이런 혼선을 줄일 수 있었을 거라는 아쉬움이 남았다.
그래서 앞으로는 그냥 혼자 하든, 둘이 하든 지간에 타입스크립트로 진행하고자 마음먹었다. 잘 선언해둔 타입으로 프로젝트를 꾸미게 되면, 이후에 데이터 구조를 가져다 쓸 때도, 리팩토링을 할 때도 많은 도움을 얻을 것 같다.
<h3 id="firestore">firestore</h3>
부끄럽고 미련하게도 초창기에는 SQL을 node와 연결해서 썼었다. 그러나 스키마 구성, 트랜잭션 관리, 테이블 관리 등을 겪고 나니 배보다 배꼽이 더 큰 느낌이었고, 빠르게 가져다 쓸 수 있는 NoSQL을 찾던 와중에 Firebase의 firestore 을 쓰기 시작했다. SQL 데이터 베이스를 구성하는데 걸린 시간을 제로에 가깝게 줄일 수 있었고, 데이터 관리 또한 JSON 형태로 아주 편하게 가져다 쓸 수 있었다.
다만 join 이나 or, in 과 같은 식의 복합쿼리는 안되기 때문에 어느 정도의 불편함을 감수해야 했다.
<a href="https://firebase.google.com/docs/firestore/query-data/queries?hl=ko">https://firebase.google.com/docs/firestore/query-data/queries?hl=ko</a>
<blockquote>
Cloud Firestore는 다음 유형의 쿼리를 지원하지 않습니다.
</blockquote>
<blockquote>
<ul>
<li>이전 섹션에서 설명한 것과 같이 여러 필드에 범위 필터가 있는 쿼리</li>
<li>논리적 OR 쿼리: 이 경우 각 OR 조건에 해당하는 별도의 쿼리를 만들고 앱에서 쿼리 결과를 병합해야 합니다.</li>
<li>!= 절을 사용하는 쿼리: 이 경우 쿼리를 초과 및 미만 쿼리로 분할해야 합니다. 예를 들어 where("age", "!=", "30") 쿼리 절은 지원되지 않지만 where("age", "&#x3C;", "30") 절이 있는 쿼리 하나와 where("age", ">", 30) 절이 있는 쿼리 하나를 결합하면 동일한 결과 집합을 얻을 수 있습니다.</li>
</ul>
</blockquote>
예컨데 장바구니와 같은 데이터 베이스를 꾸밀일이 있었는데, 이를 조회하기 위해서 불가피하게 2n 회로 데이터 조회를 요청할 수 밖에 없었다.
<img src="./images/firestore-quota.png" alt="firestore">
그러다 보니 개발 단계에서 마저도 읽기 횟수가 눈에 띄게 튀기 시작했다. 아직 눈에 띄게 document가 있지 않은 상태라 무료 수준에서 커버를 치고 있지만, document가 늘어 나면 이제 모든 쿼리를 쓰는데 신중에 신중을 기하게 될 것이다. (한번 읽기 마다 <code>0.06$</code>)
<a href="https://firebase.google.com/docs/firestore/pricing">https://firebase.google.com/docs/firestore/pricing</a>
없는 살림에 GCP를 이것저것 쓰고 있기 때문에 굉장히 덜덜덜 하고 있는데,, 부디 나에게 예산 알림이 오는날이 없었으면 한다. 그리고 그날이 온다면, mock을 잘만들어서, 쿼리를 잘만들어서 대처해보는 걸로...
<h3 id="cloud-functions">Cloud functions</h3>
cloud function은 slack, survey monkey, jandi 등의 웹 훅 용으로 유용하게 썼다. 함수 하나만 클라우드에 올려서 서버 없이 쓸 수 있기 때문에 굉장히 유용했다. firestore에 비해서 가격도 비교적 저렴해서 (그리고 애초에 많이 호출되는 함수도 아니었지만) 안심하고 여러 함수를 서버없이 잘 사용했다. 예전에 이거 하자고 인스턴스 따고 보안규칙 따고 생쇼를 했던 과거에 비하면, 너무나도 편리하다.
<img src="./images/cloud-functions.png" alt="cloud functions">
<a href="https://yceffort.kr/2020/12/generate-serverless-thumbnail">최근에는 블로그 썸네일 생성기로도 사용하기도 했다.</a> 감사합니다. 다음엔 꼭 픽셀 폰 싸서 보답하겠습니다.
<h3 id="vercel">vercel</h3>
heroku의 시대가 가고, 이제는 vercel 의 시대가 온 것 같다. 웹 애플리케이션을 프로덕션에 올리는 용도로는 망설임없이 vercel을 썼다. heroku에 비해 기능은 rich 하지 않지만 필요한 기능만 들어있고, (heroku는 너무 이것저것 많은 기분이다) 배포도 용이하며, 무엇보다 github 에 integration 할 수 있다는 점이 매력적이다.
<a href="https://github.com/yceffort/yceffort-blog-v2/pull/222#issuecomment-740369078">https://github.com/yceffort/yceffort-blog-v2/pull/222#issuecomment-740369078</a>
또한 가격도 heroku 보다 저렴했다. 웹 애플리케이션 당 가격이 아니고 한 member 당 가격을 책정하기 때문에 20달러에 프로 계정으로 나 혼자 잘 먹고 잘 쓰고 있다. (프로 계정은 최대 10명의 멤버, 50 도메인, 1000gb의 bandwidth 제한이 있다.)
<img src="./images/vercel1.png" alt="vercel1">
<img src="./images/vercel2.png" alt="vercel2">
<h3 id="github">github</h3>
마이크로소프트에 인수된 뒤로 나날이 발전하고 있는 github 도 빼 놓을 수 없다. github action 덕분에 CI, CD 등도 편리하게 수행할 수 있었고, 각종 bot을 통해서 다양한 작업을 할 수 있었다. 또한 cron job 도 편리하게 이용할 수 없었다. 기존에는 클라우드에 인스턴스 띄워서 크론 설정하고, <a href="https://healthchecks.io/">https://healthchecks.io/</a> 로 healthcheck 까지 확인했다면, 이제는 github action 하나면 충분하다.
또한 유용하게 썼던 것 중 하나는 github code spaces 다. 개발 환경이 불안정했던 외부에서도 인터넷만 연결되어 있다면, codespaces로 편리하게 개발을 할 수가 있었다.
pro 계정을 활용하면서 private repository도 자유롭게 꾸민 것이 개인적으로 많은 도움도 되었다. 내 작업물 대다수가 private 으로 되어 있어서 많은 코드를 세상과 공유(?) 하지 못했지만, 그래도 덕분에 각종 예민한 private key를 편하게 관리할 수 있었다.
올해에는 dark 모드 까지 지원되었는데, 앞으로도 github에서 더욱 rich한 기능을 지원해 줬으면 좋겠다.
<h3 id="styled-component-그리고-css">styled-component 그리고 css</h3>
css-in-js 에 대해서는 이제는 하나의 흐름이라고 개인적으로 생각했다.
<ul>
<li>Global namespace</li>
<li>Dependencies</li>
<li>Dead Code Elimination</li>
<li>Minification</li>
<li>Sharing Constants</li>
<li>Non-deterministic Resolution</li>
</ul>
하지만 지나가다가 본 글이 있는데, 보면서 이런저런 생각을 하게 됐다.
<ul>
<li><a href="https://blueshw.github.io/2020/09/27/css-in-js-vs-css-modules/">https://blueshw.github.io/2020/09/27/css-in-js-vs-css-modules/</a></li>
<li><a href="https://blueshw.github.io/2020/09/14/why-css-in-css/">https://blueshw.github.io/2020/09/14/why-css-in-css/</a></li>
</ul>
각자의 장단이 있는 것 같고, 글쓴이의 의도에도 적극 공감한다.
그러나 이와 별개로 문제는 내가 css에 대한 이해와 디자인 감각이 현저히 떨어진다는 것이다.🤪 내년에는 정녕 css를 공부해야 하는 것일까. 이쁘게는 못하더라도 (이미 디자인에 감각이 없다는 것을 블로그가 증명하고 있다), 기본적인 css에 대한 이해도 아직은 조금 부족하고, 더 공부해야 겠다는 생각이 든다.
<h2 id="마치며">마치며</h2>
일하는 회사에서 이것저것 새로운 최신의 기술, 내가 배웠던 다른 코드들을 모두 적용해 볼 수 있으면 정말 좋다. 돈도 받고, 공부도 하고, 개인적으로 성장도 할 수 있고 회사 연말 평가에 반영할 수도 있다.
그러나 아쉽게도 회사 업무에서 펼칠 수 있는 상상의 나래는 한정적이다. 기존에 쓰고 있는 기술은 한정적이고 뒤쳐져 있으며, 설득해야 하는 사람은 많고 새로운 것에 대한 반론 또한 존재한다. 이미 잘되고 있는 레거시가 있는데 굳이 왜? 그렇다고 내가 모든 책임을 다 안고 시도하기엔, 일단 나부터가 쫄린다. 로컬에선 잘됐는데? 알파에선 잘됐는데? 라는 변명으로 막을 것인가? 또한 개발자만 있는게 아니다. 기획자 분들도, 테스터 분들도, 그리고 높으신 양반들도 있다. 개발자 입장에서는 아무런 변화가 없는 코드라고 자신할 수 있지만, 그들의 눈에서는 테스트해야할 골칫거리가 하나 더 생기는 것 뿐일지도 모른다.
<img src="./images/sorry.png" alt="sorry">
<blockquote>
미안합니다,,,
</blockquote>
이런 저런 이유로 미루어, 사이드프로젝트는 개발자로서의 성장, 그리고 킬링타임을 위해 필수인 것 같다. 비록 아무도 안보는 블로그지만, 그게 오히려 좋다. CSR을 SSR 바꾸고, 새로운 기술을 적용해보고 공부해 볼 수도 있고 트렌드에 뒤쳐지지 않을 수도 있다. 버그로 프로젝트가 망가져도 트래픽은 잃을 지언정 아무도 뭐라고 하지 않으며, 부담없이 새로운일을 해볼 수 있다. 개발자가 된 이후로 몇년만에 처음으로, 각종 컨퍼런스의 타이틀을 보고 '다 아는 기술이구만' 이라며 고개를 끄덕여 봤다.
새로운 기술, 코드가 있는데 회사에서 시도할 수가 없다? 회사에서 잘 만들어 놓은 사내 서비스 보다 AWS, GCP를 써보고 싶다? 체크카드를 꺼내서 payment를 등록하고 지금 당장 나만의 프로젝트를 만들어서 공부해보자. 기술은 많고, 내가 써본 것은 손에 꼽는다. 이대로 회사일만 하기엔, 밖에는 재밌는게 너무 많다.

오늘날 90%가 넘는 브라우저가 모던 자바스크립트를 실행할 수 있음에도 불구하고, 레거시 자바스크립트는 오늘날 웹 성능 문제에 큰 원인 중 하나로 남아 있다. ES2017 문법을 사용하여 웹 페이지 또는 패키지를 작성하고 퍼블리싱 하면 성능을 매우 향상 시킬 수 있다.

## 모던 자바스크립트란 무엇일까

모던 자바스크립트는 특정 ECMAScript 버전으로 작성된 코드를 말하는게 아니고, 모던 브라우저에서 지원하는 문법으로 이루어진 것을 의미한다. 크롬, 엣지, 파이어폭스, 사파리와 같은 모던 웹 브라우저는 브라우저 시장의 90% 이상을 차지하고 있으며, 이 렌더링 엔진에 의존하는 다른 브라우저가 5% 쯤 된다. 따라서 글로벌 웹 트래픽의 95%가 지난 10년간 가장 널리 사용되는 자바스크립트 언어 기능을 지원하는 브라우저에서 비롯된다.

> 아마도 엣지 레거시와 구 IE를 제거한 수치로 보면 될 것 같다. 우리나라에서는 약 93% 정도 된다.

<div id="all-browser-KR-monthly-201912-202011" width="600" height="400" style="width:600px; height: 400px;"></div>Source: <a href="https://gs.statcounter.com/browser-market-share/all/south-korea/#monthly-201912-202011-bar">StatCounter Global Stats - Browser Market Share</a><script type="text/javascript" src="https://www.statcounter.com/js/fusioncharts.js"></script><script type="text/javascript" src="https://gs.statcounter.com/chart.php?all-browser-KR-monthly-201912-202011&chartWidth=600"></script>

여기서 말하는 문법은 이정도다.

- 클래스 (ES2015)
- 화살표 함수 (ES2015)
- 제네레이터 (ES2015)
- 블록 스코프 (ES2015)
- 디스트럭쳐링 (ES2015)
- 전개 연산자 (ES2015)
- 객체 축약 (ES2015)
- async await (ES2017)

이 후에 나온 기능, 예를 들어 ES2020, ES2021에 나온 기능들은 브라우저의 70% 정도가 지원한다. 여전히 70%면 많은 수치이지만, 그 기능에 온전히 기대는 것은 안전하지 않다. 따라서 모던 자바스크립트를 타겟으로 한다면, 가장 널리 알려져 있으며 지원하는 브라우저가 많은 ES2017 정도가 적당해 보인다. 다른 말로 하자면, ES2017이 오늘날의 가장 모던한 문법인 것이다.

> 물론 이 글은 2020년 12월 15일에 작성되어 있습니다. 시간이 흐르면 더 달라지겠죠?

https://dev.to/garylchew/bringing-modern-javascript-to-libraries-432c

## 레거시 자바스크립트

레거시 자바스크립트란 위에서 언급한 새로운 기능을 사용하지 않은 코드라 볼 수 있다. 대부분의 개발자는 모던한 문법으로 작성하지만, 브라우저의 지원을 늘리기 위하여 레거시 구문으로 컴파일한다🤪. 레거시 구문으로 컴파일하면 브라우저 지원 범위가 증가하지만, 그 효과는 우리가 생각하는 것보다 작다. 레거시 자바스크립트로 95% 정도의 수치를 98% 로 늘릴 수 는 있지만, 그 비용은 엄청나다.

> 나머지 2%는 no javascript 가 아닐까 싶습니다

- 레거시 자바스크립트는 모던 자바스크립트와 비교 했을 때 일반적으로 20% 정도 용량이 더 크고 느리다. 만약 여기에서 잘못 구성한다면 그 차이가 더 커질 수 있다.
- 별도로 설치하는 자바스크립트 라이브러리의 경우 일반적인 자바스크립트 코드의 90% 정도를 차지 한다. 이 코드에 폴리필 등이 추가 된다면 더 많은 자바스크립트 오버헤드가 발생할 수 있다.

## npm에서 모던 자바스크립트

[최근에 nodejs는 패키지의 엔트리 포인트를 지정할 수 있게 해주었다.](https://nodejs.org/api/packages.html#packages_package_entry_points)

```json
{
 "exports": "./index.js"
}
```

`exports` 필드에서 참조하는 모듈은 최소 ES2019를 지원하는 12.8의 노드 버전을 의미한다. 따라서 exports를 참조하는 모듈은 모던 자바스크립트로 작성할 수 있음을 의미한다. 따라서 모던 코드만 있는 패키지를 배포하고, 트랜스파일링은 사용하는 사람에게 맡기고 싶다면 위처럼 `exports` 필드만 사용하면 된다.

`exports`와 함께 `main`을 사용한다면, 레거시 브라우저를 위한 ES5와 CommonJS를 제공할 수 있다. 일종의 modern 한 코드의 레거시 폴백이다.

```json
{
 "name": "foo",
 "exports": "./modern.js",
 "main": "./legacy.cjs"
}
```

CommonJS로 작성된 fallback에, `module`을 추가한다면 유사하게 legacy fallback 번들로 동작하지만, 자바스크립트 모듈 문법인 `import`와 `export`도 사용 가능하다.

```json
{
 "name": "foo",
 "exports": "./modern.js",
 "main": "./legacy.cjs",
 "module": "./module.js"
}
```

이렇게 하는 이유는, 웹팩과 롤업과 같은 번들러에서 트리쉐이킹을 할 수 있도록 하기 위해서다. 이 코드는 `import` `export` 이외에 모던 코드를 사용하지 않는 레거시 번들 이므로, 레거시 코드를 지원함과 동시에 번들링에 최적화 시킬 수 있다는 장점을 가지고 있다.

## 애플리케이션의 모던 자바스크립트

써드파티 디펜던시는 프로덕션 웹 애플리케이션의 대부분을 차지한다. npm 의존성은 역사적으로 레거시 ES5로 퍼블리싱 되어왔지만, 이에 의존하는 것은 더이상 안전하지 못한 가정이며, 애플리케이션에서 브라우저 지원을 해칠 수도 있는 위험한 행동이다.

모던 자바스크립트로 이동하는 npm 패키지가 점차 많아지면서 이를 다룰 수 있는 도구를 설치하는 것이 중요 해졌다. 여거라지 방법이 있지만, 일반적으로 좋은 아이디어는 의존성을 내가 작성하는 코드의 문법 수준과 맞춰 트랜스파일 하는 것이다.

## 웹팩

웹팩5에서 부터, 번들 및 모듈에 대한 코드를 생성할 때 마다 사용할 문법을 설정할 수 있다. 이는 코드나 의존성을 트랜스파일링 하는 것이 아니고, 오직 webpack에 의해 생성된 코드를 붙일 때 영향을 미친다. 브라우저 지원 타겟을 설저하기 위해서는 `browserlist`설정을 추가하거나, 혹은 웹팩 설정에 바로 넣어두면 된다.

```javascript
module.exports = {
 target: ['web', 'es2017'],
};
```

또한 웹팩에서 모던 ES 모듈 환경을 타겟으로 한다면, 불필요한 wrapper 함수를 생략하여 번들 크기를 최적화하는 설정을 할 수 다.

```javascript
module.exports = {
 target: ['web', 'es2017'],
 output: {
 module: true,
 },
 experiments: {
 outputModule: true,
 },
};
```

이외에도 웹팩을 활용하여 모던 자바스크리븥 문법을 활용하면서 동시에 레거시 브라우저도 지원할 수 있도록 도와주는 많은 도구들이 존재한다.

## Optimize Plugin

[Optimize Plugin](https://github.com/developit/optimize-plugin)은 개별 자바스크립트 파일을 레거시 자바스크립트로 만드는 대신에, 최종적으로 만들어진 모던 번들 코드를 레거시 자바스크립트로 변환시켜주는 도구다. 웹팩 설정을 통해 모든 것이 모던 자바스크립트라고 가정하기 때문에, 특별한 처리가 필요하지 않다. 또한 이는 개별 모듈이 아닌 번들 레벨에서 동작하므로 애플리케이션의 코드와 디펜던시를 동등하게 처리한다. 이는 최종 번들링된 파일을 다시 레거시 문법으로 만드는 것이기 때문에, 전통적인 방식보다 빠를 수 있다. 이러한 두개의 모듈은 [module/nomodule pattern](https://web.dev/serve-modern-code-to-modern-browsers/)에서 사용된다.

```javascript
// webpack.config.js
const OptimizePlugin = require('optimize-plugin');

module.exports = {
 // ...
 plugins: [new OptimizePlugin()],
};
```

`Optimize Plugin`은 모던 코드와 레거시 코드를 따로 번들링 하는 기존 방식보다 더 빠르고 효율적이다. 또한 `Babel`처리도 가능하며, `Terser`를 활용하여 각각의 번들 크기를 줄일 수도 있다. 마지막으로, 레거시 번들에 필요한 폴리필을 따로 관리하기 때문에, 모던 브라우저에서 이를 로딩하지 않도록 도와준다.

<video style="width: 100%;" controls="" autoplay="" loop="" muted="" class="w-screenshot">
 <source src="https://storage.googleapis.com/web-dev-assets/fast-publish-modern-javascript/transpile-before-after.webm" type="video/webm">
 <source src="https://storage.googleapis.com/web-dev-assets/fast-publish-modern-javascript/transpile-before-after.mp4" type="video/mp4">
 </video>

 ## BabelEsmPlugin

 웹팩 플러그인 중 하나인 [BabelEsmPlugin](https://github.com/prateekbh/babel-esm-plugin)는 `@babel/preset-env` 와 함께 사용할 수 있으며, 현재 가지고 있는 번들을 모던 브라우저에 서비스 할 수 있도록 트랜스파일링을 최소화 해준다. 이는 Next.js나 preact cli에서도 사용하는 가장 유명한 module/nomodule 솔루션이다.

 ```javascript
 // webpack.config.js
const BabelEsmPlugin = require('babel-esm-plugin');

module.exports = {
 //...
 module: {
 rules: [
 // your existing babel-loader configuration:
 {
 test: /\.js$/,
 exclude: /node_modules/,
 use: {
 loader: 'babel-loader',
 options: {
 presets: ['@babel/preset-env'],
 },
 },
 },
 ],
 },
 plugins: [new BabelEsmPlugin()],
};
```

`BabelEsmPlugin`는 애플리케이션에서 크게 분리된 두가지 빌드를 실행하기 때문에 다양한 웹팩 설정을 지원한다. 두 번 컴파일 하는 것은 대규모 애플리케이션에 약간의 추가 시간이 걸릴 수 있지만, 이는 BabelEsmPlugin이 기존의 웹팩 설정에 원활한 통합 등을 도와주며, 편의성도 제공한다.

## node_modules을 트랜스파일 하기 위한 babel-loader 설정

위에서 언급한 두개의 플러그인 대신 `babel-loader`를 사용하고 있다면, npm 모듈을 모던 자바스크립트로 사용하기 위한 중요한 단계가 남아 있다. 두개의 개별적인 바벨 로더를 구성해서 정의한다면, node_modules에서 발견되는 최신 언어 스펙을 ES2017로 자동으로 컴파일 하는 동시에, 프로젝트에 구성된 babel 플러그인과 사전 설정으로 자신의 코드를 1차적으로 변환할 수 있다. 이는 module/nomodule 설정의 번들을 생성하지는 않지만, 오래된 브라우저 지원을 깨트리지 않고 모던 자바스크립트가 포함된 npm 패지키를 설치하고 사용하는 것을 가능하게 한다. 

[webpack-plugin-modern-npm](https://www.npmjs.com/package/webpack-plugin-modern-npm) 을 사용하면, npm 디펜던시에 `exports`가 있는 코드들을 컴파일한다.

```javascript
// webpack.config.js
const ModernNpmPlugin = require('webpack-plugin-modern-npm');

module.exports = {
 plugins: [
 // auto-transpile modern stuff found in node_modules
 new ModernNpmPlugin(),
 ],
};
```

대신에 이 기능을 수동으로 설정할 수 도 있다.

```javascript
// webpack.config.js
module.exports = {
 module: {
 rules: [
 // Transpile for your own first-party code:
 {
 test: /\.js$/i,
 loader: 'babel-loader',
 exclude: /node_modules/,
 },
 // Transpile modern dependencies:
 {
 test: /\.js$/i,
 include(file) {
 let dir = file.match(/^.*[/\\]node_modules[/\\](@.*?[/\\])?.*?[/\\]/);
 try {
 return dir && !!require(dir[0] + 'package.json').exports;
 } catch (e) {}
 },
 use: {
 loader: 'babel-loader',
 options: {
 babelrc: false,
 configFile: false,
 presets: ['@babel/preset-env'],
 },
 },
 },
 ],
 },
};
```

이 방법을 사용할 때는 minifier가 이러한 모던 코드를 지원할 수 있도록 해야 한다. `Terser` `Uglify-es`에 `{ecma: 1027}`를 지정할 수 있는 옵션이 있으며, 경우에 따라 압축하거나 포맷하는 와중에 `ES2017`구문을 생성하기도 한다. 

## 추가적인 빌드 툴

- https://parceljs.org/
- https://www.snowpack.dev/
- https://github.com/vitejs/vite
- https://github.com/preactjs/wmr

## 결론

ES2017 이 요즘 흔히 말하는 모던 자바스크립트에 가장 근접한 스펙이며, npm, babel, rollup 등을 빌드 시스템에 사용하여 패키지와 문법을 모던 자바스크립트에서 동작할 수 있도록 설정할 수 있다. 

출처: https://web.dev/publish-modern-javascript/

아니 그래서 IE 11 언제 없앨 건데요

더 빠른 웹 애플리케이션을 위한 모던 자바스크립트

사이트를 카카오톡, 페이스북 등 SNS에서 공유할 때 이른바 썸네일이 보이게 하기 위해서는 [open graph tool](https://ogp.me/)를 사용해야 한다. 트위터의 경우에는 자체 정의된 `twitter:*` 시리즈의 무언가를 이용해야 한다. 내 모든 블로그 글에 이쁜 대문 이미지가 있으면 좋겠지만, 모든 것에 현실적으로 이미지를 만드는 것은 불가능하고 귀찮다. 그래서 주어진 이미지에 블로그의 메타 정보를 쓰는 방식으로 정적 이미지를 만든 다음, 이 이미지를 공유용 이미지로 서빙하는 방법에 대해서 고민해 보았다.

## 구성

og tag image 주소 요청 > 해당 주소로 cloudinary에 이미지가 있는지 확인

- 있다면 그 주소로 리다이렉트
- 없다면 > 블로그에 이미지 형태로 준비되어 있는 페이지 방문 > 해당 페이지 스크린샷 > 스크린샷 한 이미지를 cloudinary에 업로드 > 해당 이미지 주소로 리다이렉트

## 1. 정적인 이미지를 만들 페이지 구성하기

`/generate-screenshot`이라는 이름으로 페이지를 하나 만들고, 거기에 정적으로 생성할 이미지를 일단 웹페이지 형태로 만들어보았다.

https://yceffort.kr/generate-screenshot?tags=javascript&title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions

https://github.com/yceffort/yceffort-blog-v2/blob/master/pages/generate-screenshot.tsx

여기저기 글을 본 결과 최적의 사이즈는 `1200x630`으로 알려져 있으며, 해당 사이즈에 맞게 페이지를 구성하면 된다.

## 2. 해당 페이지를 스크린샷 찍기

이제 해당 페이지를 방문해서 스크린샷을 찍어야 한다. 첫 번째로 시도한 것은 [nextjs에 api를 활용하여 vercel에서 시도하는 것](https://nextjs.org/docs/api-routes/introduction)이었다. 그러나 결과적으로 이 시도는 실패했는데, 일단 스크린샷을 찍기 위해서는 puppetter의 headless chrome instance를 띄워야 하는데 이 메모리가 생각보다 많이 들었다. 그리고 별개의 폰트도 설치해야 하는데 그 과정까지 vercel에서 할 수 없었으므로, [firebase functions](https://firebase.google.com/docs/functions)을 활용하기로 했다.

시작하는 방법은 [여기](https://firebase.google.com/docs/functions/get-started)에 잘 나와있다. 심지어 한글로 되어 있다.

```javascript
exports.screenshot = functions.https.onRequest(async (req, res) => {
 const query = req.query
 const title = encodeURI(query.)
 const firebaseTitle = title.replace(/\//gi, '-')
 const screenshotRef = db.collection('screenshot')

 const exist = await screenshotRef.doc(firebaseTitle).get()

 if (exist.exists) {
 return res.redirect(exist.data().url)
 }

 try {
 const postUrl = `http://yceffort.kr/generate-screenshot?${queryString.stringify(
 query,
 )}`
 const screenshot = await takeScreenshot(postUrl)
 const uploadedImage = await putImage(title, screenshot)
 screenshotRef.doc(firebaseTitle).set({
 url: uploadedImage,
 })
 res.redirect(uploadedImage)
 } catch (e) {
 console.error(e)
 res.json({ error: e.toString() })
 }
})
```

```javascript
const takeScreenshot = async function (url) {
 const chromiumPath = await chromium.executablePath

 const browser = await chromium.puppeteer.launch({
 executablePath: chromiumPath,
 args: chromium.args,
 defaultViewport: chromium.defaultViewport,
 headless: chromium.headless,
 })

 const page = await browser.newPage()
 await page.setViewport({ height: 630, width: 1200 })
 await page.goto(url)
 const buffer = await page.screenshot({ encoding: 'base64' })
 await browser.close()
 return `data:image/png;base64,${buffer}`
}
```

여기서 겪은 삽질을 몇가지 소개해본다.

### 1) puppeteer는 무겁다

puppeteer를 npm install 로 설치해보면 꽤 시간이 걸린다는 것을 알 수 있다. 그래서 `puppeteer`를 `puppeteer-core`만 설치하고, cloud function에서 쓸 수 있는 다른 chromium 브라우저를 알아 봐야 한다. 그래서 https://github.com/alixaxel/chrome-aws-lambda 를 설치했다. 그리고 `iltorb` 도 함께 설치해 주어야 한다.

### 2) react metatag의 query escape

원래는 이 주소를 넘겼다.

https://us-central1-yceffort.cloudfunctions.net/screenshot?slug=2020%2F12%2Fmeasuring-performance-of-javascript-functions&tags=javascript&title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions

그러나 소스 보기로 해당 주소를 보면 아래와 같이 되어 있었다.

```html
<meta
 property="og:image"
 content="https://us-central1-yceffort.cloudfunctions.net/screenshot?slug=2020%2F12%2Fmeasuring-performance-of-javascript-functions&amp;tags=javascript&amp;title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&amp;url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions"
/>
```

`&`가 `&amp;`로 escape 처리 되어 있는 것이다.

- https://github.com/facebook/react/issues/13838
- https://github.com/vercel/next.js/issues/2006

두가지 선택이 있었는데, query param 구조로 되어 있는 주소를 path variable 로 모두 바꾸거나, 혹은 받는 쪽에서 처리를 하는 것이다. path를 다 바꾸기는 넘 귀찮아서 아래와 같은 처리를 추가해주었다.

```javascript
const query = Object.keys(context.query).map(
 (key) => (query[key.replace(/amp;/, '')] = context.query[key]),
 ) as any
```

### 3) 느린 속도

스크린샷을 찍고, 이미지를 업로드 해서 내려주는 최초의 과정은 느릴 수 밖에 없다.그러나 문제는 두번째 과정 이후 부터 있었다. 이미 이미지가 생성되었는지 확인하기 위해 cloudinary에 get 요청을 날리는데, 이 과정 또한 쓸데 없이 오래 걸렸다. 그래서 cloudinary에 찔러서 확인하는대신, 한번 생성된 이미지는 key와 value 형태로 주소를 firebase에 저장해 두어 더 빠르게 내려주었다.

저장

```javascript
const uploadedImage = await putImage(title, screenshot)
screenshotRef.doc(firebaseTitle).set({
 url: uploadedImage,
})
```

불러오기

```javascript
const exist = await screenshotRef.doc(firebaseTitle).get()

if (exist.exists) {
 return res.redirect(exist.data().url)
}
```

그렇다고 해서 속도문제가 완전히 해결된 것은 아니었다. 첫단계에서는 여전히 생성속도가 느리고, 주소에서 느껴지겠지만, 미국 동부를 거쳐서 왔다리 갔다리 해야 하기 때문에 여전히 좀 답답한면이 있다.

## 3. 메타 태그에 심기

```html
<meta
 property="og:image"
 content="https://us-central1-yceffort.cloudfunctions.net/screenshot?slug=2020%2F12%2Fmeasuring-performance-of-javascript-functions&amp;tags=javascript&amp;title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&amp;url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions"
/>
```

```html
<meta
 name="twitter:image"
 content="https://us-central1-yceffort.cloudfunctions.net/screenshot?slug=2020%2F12%2Fmeasuring-performance-of-javascript-functions&amp;tags=javascript&amp;title=%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%20%ED%95%A8%EC%88%98%EC%9D%98%20%EC%84%B1%EB%8A%A5%20%EC%B8%A1%EC%A0%95%ED%95%98%EA%B8%B0&amp;url=https%3A%2F%2Fyceffort.kr%2F2020%2F12%2Fmeasuring-performance-of-javascript-functions"
/>
```

## 결과

![preview1](./images/metadata-preview1.png)

![preview2](./images/metadata-preview2.png)

## 문제점

- 여전히 좀 느리다. 당연히, 초기 생성단계에서는 느릴 수 밖에 없다. 이것을 어떻게 해결할 것인가가 관건이다. 글이 올라간 뒤에, github action으로 트리거 해서 생성할 것인가? 혹은 배포 단계에 이를 포함할 것인가?
- firebase functions, firebase storage, 거기에 cloudinary까지 사용하고 있다. 코로나 시대에 줄어든 용돈으로, 과연 여기까지 커버할 수 있을 것인가? vercel은 언제 또 나에게 pro 버전으로 내 지갑을 재차 노릴 것인가?

참으로 무시무시한 일이 아닐 수 없다.

yceffort

map과 reduce에서 async await 사용하기

파티셔닝 캐시 (partitioning cache)

2020년 사이드 프로젝트 회고

더 빠른 웹 애플리케이션을 위한 모던 자바스크립트

서버리스로 블로그 포스트 썸네일 생성하기