PWA가 나타난 이후로, [이제 모든 웹 프로젝트는 PWA로 이루어져야 한다](https://alistapart.com/article/yes-that-web-project-should-be-a-pwa/), 라든지 PWA가 웹 프로젝트의 미래라든지, 이제 모든 애플리케이션이 PWA로 만들어질 것이라든지, 더이상 일렉트론은 사라질 것이라든지의 많은 글을 봐왔다. 귀에 딱지가 앉도록 많이 들었기 때문에, 한번 해보고 싶은 마음이 들었다. 어차피 막나가는 토이 프로젝트 블로그에 PWA 하나 추가된다고 별일 없을 것이다, 라는 생각으로 블로그에 PWA를 적용해 보았다.

## HOW TO

정석대로 하는 방법은 https://web.dev/progressive-web-apps/ 여기를 참고 하는게 좋다. 원래 번역까지 해보려고 했는데, 굳이 그렇게 까지 안해도 될 것 같아서 읽고 공부해보기만 했다.

### next-pwa

고맙게도 nextjs 환경에서 pwa를 적용해줄 수 있는 라이브러리가 존재한다. 바로 [next-pwa](https://github.com/shadowwalker/next-pwa)이다. 별다른 설정을 해주지 않아도 next를 pwa환경으로 바꾸어 주었다. 그외에 설정에 맞게 `manifest.json` 추가, `<meta/>` 를 추가했다.

### pwa-asset-generator

pwa를 ios나 안드로이드에서 제대로 보여주기 위해서는 아이콘과 splash이미지를 잘 준비해야 한다. 특히 ios의 splash 이미지는 [apple launch screen 가이드에 따라서 모든 사이즈에 대응할 수 있는 이미지](https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/#device-screen-sizes-and-orientations)가 준비되어 있어야 해서 조금 귀찮다. 그런 작업들을 모두 [pwa-asset-generator](https://github.com/onderceylan/pwa-asset-generator)가 도와주었다. 아이콘과 스플래시 이미지, 그리고 그에 따른 태그를 알아서 만들어준다. 감사합니다

## 결과

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

lighthouse 검사결과에서 PWA로 잘 인식되는 것을 볼 수 있다. `start_url`이 응답을 안한다고 하는 것은 [light house의 버그로 보인다.](https://github.com/shadowwalker/next-pwa/issues/107)

![pwa-offline](./images/pwa-offline.png)

네트워크가 오프라인으로 되어 있어도 서비스 워커를 통해서 서비스가 잘 작동하는 것을 볼 수 있다.

![pwa2-1](./images/pwa2-1.png)

![pwa2-2](./images/pwa2-2.png)

![pwa2-3](./images/pwa2-3.png)

pwa로 등록되면 크롬 주소창에 앱으로 등록할 수 있다는 뜻의 작은 아이콘이 뜬다. 이를 등록해두면 애플리케이션처럼 사용가능해진다.

![pwa-splash](./images/pwa-splash.png)

안드로이드가 없어서 테스트 해보지는 못했지만, ios에서는 splash이미지가 잘나오고 있었다.

![pw3-1](./images/pwa3-1.png)

![pw3-2](./images/pwa3-2.png)

ios에서 이렇게 실제 앱과 비슷하게 사용할 수 있었다.

## 단점

장점은 여기저기에 나열되어 있으니, 단점과 개인적인 소회를 적어보려고 한다.

### 네이티브 인터페이스를 사용할 수 없다는 한계

네이티브 인터페이스가 없기 때문에 당연히 일반 모바일 애플리케이션 대비 할 수 있는 액션이 제한되어 있다. iOS의 경우 푸쉬 알림이 불가능하며, 사용자가 PWA를 앱 아이콘으로 등록하지 않으면, 7일이 넘는 캐시데이터를 자동으로 삭제한다.

### (모바일 애플리케이션을 대체할 수 있다는 관점에 한해서) 높은 진입 장벽

PWA를 정말 일반 애플리케이션 처럼 쓰려면 모바일 기준으로, 일반사용자가 한다고 했을 때 아래와 같은 과정을 거쳐야 한다.

- PWA로 되어 있는 해당 사이트 방문 (사파리만 가능)
- 화면 중앙 하단의 공유 버튼 클릭
- 스크롤을 조금 더 내려서 홈 화면에 추가

일반적인 사용자가 절대로 경험해본적이 없을 UX이며, 설령 이 과정을 toast 든 팝업이든 알려준다 치더라도 실제로 이를 실행에 옮길 사용자가 몇이나 될까 싶다.

대부분의 사용자들은 애플리케이션 설치를 곧 앱스토어에 접속한다는 행위로 인식하고 있기 때문에, 앱스토어에 PWA를 등록하게 해주지 않는 이상 - 이러한 장점은 거의 없다고 봐야할 것이다.

## PWA의 의미

https://medium.com/iquii/progressive-web-app-pwa-what-they-are-pros-and-cons-and-the-main-examples-on-the-market-318f4538c670 의 글을 빌리자면, PWA의 장점은 아래와 같다(고한다.)

- Progressive
- Responsive
- AppLike
- Updated
- Secure
- Searchable
- Reactivable
- Installable
- Linkable
- Offline

이에 대해 의견을 달아보면

- ~~Progressive~~: 브라우저에 관계없이 사용할 수 있다는 것은, 그냥 웹의 장점이다. 모바일 웹 어플리케이션을 만들어도 가능하다.
- ~~Responsive~~: 반응형은 모든 웹사이트에서 구현 가능한 것이다.
- ~~AppLike~~: 위에서 언급한 이유 때문에, 앱과 비슷한 경험을 준다는 것은 사용자에게 장점으로 어필하기 쉽지 않다. 어차피 모바일 웹 어플리케이션으로 만드나, 네이티브 애플리케이션으로 만드나 일반사용자들은 차이를 느끼기가 어려울 것이다.
- ~~Updated~~: 서비스워커로든, http fetch로든 언제든 데이터를 제공할 수 있다. 앱과 다르게 배포가 필요하지 않다는 장점도 있지만 이는 비단 PWA만의 장점은 아니다.
- ~~Secure~~: https를 반드시 이용해야 PWA를 사용가능하지만, secure는 장점이 아니고 필수다.
- ~~Searchable~~: 웹 도 충분히 검색엔진에서 검색될 수 있다.
- Reactivable
- ~~Installable~~: AppLike와 같음
- ~~Linkable~~: 웹 사이트도 링크를 제공할 수 있다.
- Offline: 확실히 오프라인상태에서도 사용자 경험을 제공할 수 도 있다는 것은 장점이긴 했다. 그러나 이는 크게 장점으로 어필하긴 어려울 것 같다. 이미 대부분의 사용자들은 거의 99% 온라인 상태로 휴대기기를 유지하고 있을 것이고, `오프라인 = 앱이 동작하지 않는 상태`로 이미 이해하고 있다. 오프라인 상태로도 정적인 컨텐츠를 제공하고 이게 유의미한 서비스라면 모를까?

그외에 장점으로는 개발하기 굉장히 쉬웠다는 것이 있다. 앱스토어 권한 획득하고, 무거운 에뮬레이터 띄워가면서 난리 치지 않더라도 쉽게 만들 수 있었다. https로 서비스 할 수 있는 PWA를 만드는 것은, 여러가지 면에서 실제 모바일 네이티브 애플리케이션을 만드는것보다 쉬웠다.

사용자 입장에서, PWA의 장점은 앱과 비슷한 경험을 웹으로도 줄 수 있다는 정도로 볼 수 있을 것 같다. 물론 그 비슷한 경험에도 명확하게 한계가 있기 때문에 100% 호환이 된다고 하긴 어렵지만, iOS와 안드로이드에서 PWA를 얼마나 밀어주느냐에 따라서 미래가 달려있다고 볼 수 있을 것 같다. 물론 이 또한 긍정적이지는 않다. 인앱결제도 못하는 PWA를 자사 앱스토어 시장을 그대로 둔채로 밀어줄 것 같지는 않다. 하다못해 푸쉬라도 제대로 되면 좋을텐데, 애플느님이 해주실 것 같진 않다.

그렇기 때문에 여전히, 모바일 서비스의 대부분은 지금처럼 앱/플레이 스토어가 중심이 될 것이다. 그렇다고 웹이 들어갈 자리가 없는 것은 아니다. 언제든 업데이트가 가능하다는점, 브라우저 스펙을 잘 따르면 거의 비슷한 사용자 경험을 줄 수 있다는 장점 때문에 앱처럼 보이는 웹, 그러니까 하이브리드 앱이 지금처럼 계속 대세를 이룰 것 같다. (그에 대한 방증으로 대부분의 회사에서 프론트 엔드 인력을 필요로 하고 있다.) 멀티플랫폼 지원, iOS, 안드로이드 의 공통 리소스 확보, 상시 업데이트를 위해 대다수의 사이즈가 큰 애플리케이션들은 이미 하이브리드 앱으로 구동되고 있다. 데스크톱 앱의 경우, 일렉트론이 여전히 유의미한 대안으로 존재하고 있다.

## 요약

- PWA로 일반 모바일 애플리케이션과 비슷한 경험을 제공할 수 있다
- 그러나 그 경험을 일반 사용자가 느끼기엔 ...........
- PWA로 느낄 수 있는 향상된 경험은 일반 웹에서도 충분히 고민해볼만한 것들이다 (secure, responsive, progressive...)
- 하이브리드 앱/일렉트론은 계속해서 유의미한 선택지로 남아있을 것 같다.

노력은 나만 하고 즐기는것도 나만 즐긴다

PWA 적용 후기 및 장단점

인터넷 연결은 시시때때로 끊길 수 있고 불안정하므로, PWA에서는 오프라인 환경과 신뢰할 수 있는 성능을 안정적으로 제공하는 것이 필수다. 또한 완벽히 온라인 환경이 제공된다 하더라도, 캐싱과 다른 스토리지 기술을 적절히 활용한다면 사용자의 경험을 향상 시킬 수 있다. 정적 애플리케이션 리소스(HTML, Javascript, CSS)와 데이터 (사용자 데이터, 뉴스 기사 등)를 캐싱하는 방법이 꽤 있다. 어떤 것이 가장 좋은 해결책이며, 이들은 얼마나 저장할 수 있을까?

## 무엇을 사용해야 하는가?

- 네트워크 리소스나 파일 기반의 콘텐츠가 필수적일 때는, [Cache Storage API](https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage)를 사용하는 것이 좋다.
- 다른 데이터의 경우에는, [IndexedDB](https://developer.mozilla.org/ko/docs/Web/API/IndexedDB_API) 를 사용하는 것이 좋다.

이 두 방식은 모두 모던 브라우저에서 지원한다 (IE 제외). 그리고 둘다 비동기로 이루어지며 메인스레드를 블로킹하지 않는다. 또한 `window`, 웹 워커, 서비스 워커에서 접근 가능 하기 때문에 어디서든 사용하기 쉽다.

## 다른 스토리지는?

물론 이 외에도 브라우저에서 사용할 수 있는 다른 스토리지가 존재한다. 그러나 이들은 사용에 제한이 있으며, 성능적인 문제 또한 존재한다.

- [SessionStorage](https://developer.mozilla.org/ko/docs/Web/API/Window/sessionStorage): 데이터가 탭과 연결되어 있기 때문에, 탭의 라이프타임과 함께 한다. 따라서 세션과 관련된 작은 양의 데이터를 저장하는데 유용하다. (IndexedDB의 키 등) 또한 동기로 작동하며 메인스레드를 블로킹하기 때문에 사용에 주의가 필요하다. 5MB 까지의 데이터만 저장가능하며, 문자열만 가능하다. 또한 탭에 묶여 있기 때문에, 웹워커나 서비스워커에서는 사용이 불가능하다.
- [LocalStorage](https://developer.mozilla.org/ko/docs/Web/API/Window/localStorage): 마찬가지로 메인스레드를 블로킹하고 동기로 작동한다. 마찬가지로 5MB까지 가능하며, 문자열 데이터만 저장가능하다. 웹 워커와 서비스워커에서는 사용이 불가능하다.
- [Cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies): 쿠키는 쿠키 나름대로의 사용처가 있기 때문에, 데이터 저장용도로 사용해서는 안된다. 쿠키는 모든 HTTP 요청에 함께 보내지기 때문에, 큰 데이터를 저장했다가는 모든 HTTP 요청에 함께 날라가게 되므로 신 사이즈가 커지게 된다. 또한 이들은 동기로 작동하며, 웹워커에서는 접근이 불가능하다. 위 두개와 마찬가지로, 문자열 데이터만 저장 가능하다.
- [File System API](https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction): 샌드박스 (제한된 영역의) 파일시스템에 파일을 읽고 쓸 수 있도록 도와준다. 비동기로 작동되는 반면 [크로미윰에서만 지원되기 때문에](https://caniuse.com/filesystem) 널리 사용하기는 어렵다.
- [File System Access API](https://web.dev/file-system-access/): 사용자가 로컬 파일 시스템에 파일을 읽고 쓰기 쉽게 만들어주는 API다. 따라서 사용자에게 권한을 획득하는 것이 필수 이며, 또한 이 권한은 세션을 넘어가면 유지 되지 않는다.
- WEB SQL: IndexedDB의 등장과 함께 사라진 기능으로, 사용해서는 안된다.
- [Application Cache](https://developer.mozilla.org/ko/docs/Web/HTML/Using_the_application_cache): 이 또한 deprecated 되었다. 브라우저에서 지원이 중단될 예정이며, 서비스워커와 Cache API로 대체 해야 한다.

## 얼마나 저장할 수 있는가?

몇 백 메가바이트, 그리고 잠재적으로 수백 기가바이트 이상이 될 수도 있다. 브라우저 별로 다를 수 있지만, 사용가능한 스토리지의 크기는 대개 장치에서 사용 가능한 스토리지의 크기에 따라서 결정된다.

- 크롬에서는 원래 전체 디스크 공간의 60%까지 허용해주었지만, 이제는 80% 까지 가능하다. StorageManger API를 이용해서 사용가능한 스토리지의 크기를 점검할 수 있다. 다른 크로미윰 기반 브라우저의 경우 더 많은 스토리지를 사용할 수도 있다. [여기](https://github.com/GoogleChrome/web.dev/pull/3896)를 참고
- IE 10 이상의 브라우저에서는 250mb까지 가능하며, 10mb이상의 스토리지를 사용할 경우 사용자에게 메시지를 띄운다.
- 파이어폭스는 여유 디스크공간의 50%까지 사용하게 해준다. `eTLD+1` (effective Top Level Domain) 의 경우에는 최대 2GB까지 가능하다. StorageManager API를 통해서 얼마나 사용가능한지 확인할 수 있다.
- 사파리는 1gb까지 지원하는 것으로 보인다. 최대 스토리지에 도달하면, 사용자에게 메시지를 띄우고 200mb 를 추가로 사용할 수 있게 해준다. (이에 대한 정확한 공식문서는 찾지 못했으므로, 약간의 차이가 있을수 있다.)

과거 스토리지 용량 최대치에 근접하게 되면, 브라우저는 사용자에게 메시지를 띄워서 권한을 획득한 후, 추가로 스토리지용량을 제공했다. 그러나 요즘 모든 브라우저는 사용자에게 특별히 메시지를 띄우지 않고 최대 사용량 까지 사용하게 해준다. 사파리의 경우는 조금 다르다. 앞서 이야기 한것처럼 추가 할당량 사용여부를 유저에게 묻고 허락할 경우 사용하게 해주지만, 그 이상은 불가능 한 것으로 보인다.

## 사용가능한 스토리지 용량 확인하는 방법

[Storage Manager API](https://caniuse.com/mdn-api_storagemanager)를 통애서 확인 가능하다.

```javascript
if (navigator.storage && navigator.storage.estimate) {
  const quota = await navigator.storage.estimate()
  const percentageUsed = (quota.usage / quota.quota) * 100
  const remaining = quota.quota - quota.usage

  console.table(quota)
}
```

| index        | value        | caches    | indexedDB | serviceWorkerRegistrations |
| ------------ | ------------ | --------- | --------- | -------------------------- |
| quota        | 299977904946 |           |           |                            |
| usage        | 621244075    |           |           |                            |
| usageDetails |              | 620952837 | 256156    | 35082                      |

Storage Manager API가 모든 브라우저에서 사용가능한 것은 아니므로, feature detect를 꼭 걸어줘야 한다. 또한 quota를 넘는 경우 에러가 발생할 수도 있으므로, `try.. catch`로 이를 잡아 주는 처리를 해야 한다.

[예제 사이트 확인해보기](https://storage-quota.glitch.me/)

## 사용량 초과시 대처

중요한 점은 코드를 작성할 시에 `QuotaExceededError`와 같은 에러에 대해 염두해 두어야 한다는 것이다. IndexedDB 와 Cache API 모두 사용량 초과시에 `DOMError`나 `QuotaExceededError`를 던진다.

### IndexedDB

데이터 사용량을 초과한다면, `IndexedDB`에 쓰려는 시도는 모두 실패한다. 트랜색션의 `onabort()`가 호출된다. 여기에는 `DOMException`이 포함된다. 에러의 `name`을 확인하면 `QuotaExceededError`가 보일 것이다.

```javascript
const transaction = idb.transaction(['entries'], 'readwrite')
transaction.onabort = function (event) {
  const error = event.target.error // DOMException
  if (error.name == 'QuotaExceededError') {
    // Fallback code goes here
  }
}
```

### Cache API

```javascript
try {
  const cache = await caches.open('my-cache')
  await cache.add(new Request('/sample1.jpg'))
} catch (err) {
  if (error.name === 'QuotaExceededError') {
    // Fallback code goes here
  }
}
```

## Eviction

> 최대 용량 초과로 인해 데이터가 지워지는 것을 의미한다.

웹 스토리지는 `Best Effort`와 `Persistent` 두개의 버켓으로 구분할 수 있다. `Best Effort`란 스토리지가 사용자를 방해하지 않고 브라우저에 의해 정리될 수 있다는 것을 의미하는데, 이는 중요한 데이터에 적합하지 않다는 것을 의미한다. `Persistent` 스토리지는 저장가용량이 낮더라도 자동으로 삭제 되지는 않는다. 사용자가 수동으로 데이터를 삭제 해야 한다.

기본적으로, 사이트의 데이터는 `Best Effort`로 분류되어 사이트가 별도로 [persistent storage를 요청](https://web.dev/persistent-storage/)하지 않는다면, 가용량이 낮아지게 되면 자동으로 데이터를 삭제하게 된다.

`best effort`내에서 eviction 정책은 아래와 같다.

- 크로미윰 기반 브라우저는 브라우저의 저장공간이 부족할 때 데이터를 제거하며, 브라우저의 저장공간이 초과되지 않을 때 까지 가장 오래된 데이터부터 삭제하기 시작한다.
- IE 10이상에서는 데이터를 제거되지는 않지만, 더이상 데이터를 쓰는 것이 불가능해진다.
- 파이어 폭스는 크로미윰과 마찬가지로 저장공간이 초과되지 않을 때까지 오래된 데이터부터 삭제한다.
- 사파리의 경우 이전 버전에서는 데이터를 제거하지 않았는데, 최근에는 스토리지에 대해 7일짜리 제한을 두기 시작했다.

> iOS, iPadOS 13.4, 맥의 safari 13.1 부터, Cache API, indexed DB, storage 등의 쓰기 스토리지에 대해서 7일간의 제한을 걸어두기 시작했다. 이는 사용자가 사이트에서 인터랙션을 하지 않을 경우, 사파리가 7일 이후에는 캐시에서 모든 데이터를 제거한다는 것을 의미한다. 이 정책은 홈스크린에 설치된 PWA에는 적용되지 않는다. 자세한 내용은 [여기](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/)를 참조!

## 왜 indexedDB 래퍼를 사용해야 할까?

IndexedDB는 저수준 API로, 아주 작은 양의 데이터를 저장하는데 사용한다 할지라도 처음 설치에 있어 많은 심혈을 기울여야 한다. 다른 모든 promise 기반 API와는 다르게, 이벤트 베이스로 작동된다. [idb](https://github.com/jakearchibald/idb)를 사용하면 일부 강력한 기능을 사용할수 없지만 트랜잭션과 스키바 버전과 같은 복잡한 기능을 사용하지 않더라도 promise 기반의 indexeddb를 사용할 수 있게 해준다.

출처: https://web.dev/storage-for-the-web/


PWA에서 가장 적절한 것은 무엇일까

웹에서 사용 가능한 스토리지 살펴보기

```javascript
const memoize = (func) => {
  // 메모이제이션을 위한 클로져 생성

  // 메모이제이션 값을 저장해둔다.
  const results = {}

  return (...args) => {
    // 파라미터로 메모이제이션 키 생성
    const memoKey = JSON.stringify(args)

    // 결과가 없으면 메모이제이션 값을 넣어둔다.
    if (!results[memoKey]) {
      results[memoKey] = func(...args)
    }

    // 메모이제이션 값을 리턴
    return results[memoKey]
  }
}
```


자바스크립트로 메모이제이션 구현하기

<pre class="language-javascript"><code class="language-javascript">const memoize = (func) => {
 // 메모이제이션을 위한 클로져 생성

 // 메모이제이션 값을 저장해둔다.
 const results = {}

 return (...args) => {
 // 파라미터로 메모이제이션 키 생성
 const memoKey = JSON.stringify(args)

 // 결과가 없으면 메모이제이션 값을 넣어둔다.
 if (!results[memoKey]) {
 results[memoKey] = func(...args)
 }

 // 메모이제이션 값을 리턴
 return results[memoKey]
 }
}
</code></pre>

세상 많은 javascript 패키지에 감사하며 개발을 하고 있지만, 때로는 이러한 오픈소스에도 버그가 존재하곤 한다. 한 달 전 쯤에는, [리액트에서 ie11에 존재하지 않는 `Array.fill()`을 쓰는 바람에 패치를 한 것을 본 적도 있다.](https://github.com/facebook/react/issues/20069) 공짜로 가져다 쓰는 주제에 감사는 못할 망정 비난을 하는 것은 아니지만, 모두가 완벽할 수는 없고, 때로는 이런 버그를 내가 찾아서 적용해야 할 때가 있다. 아래 과정은 이슈 업해서 고쳐지는 것을 기다리기엔 너무 급한 나에게 필요한 방법이다.

## 1. 패치 폴더 만들기

```bash
mkdir patches
```

## 2. 해당 폴더에 패치를 적용할 파일을 만들기

일단 `node_modules` 에 버그를 수정한 패치를 적용해서 작동을 확인했다고 가정하자. (이번 예제에서는 `react-dom`에 `console.log`를 찍어볼 것이다.)

```bash
cp node_modules/react-dom/index.js patches/react-dom-index.js
```

그리고 아래 명령어로 `node_modules`를 다 지운 다음, 다시 설치해서 비교해 볼 것이다.

```bash
rm -rf ./node_modules && npm install
```

## 3. 패치 파일 만들기

그리고 diff 로 비교해보자

```bash
» diff -Naur node_modules/react-dom/index.js patches/react-dom-index.js
--- node_modules/react-dom/index.js 1985-10-26 17:15:00.000000000 +0900
+++ patches/react-dom-index.js 2020-11-23 16:55:32.000000000 +0900
@@ -28,6 +28,8 @@
 }
 }

+console.log('==========REACT DOM START==========')
+
 if (process.env.NODE_ENV === 'production') {
 // DCE check should happen before ReactDOM bundle executes so that
 // DevTools can report bad minification during injection.

```

그리고 이를 `patch`로 export 한다.

```bash
diff -Naur node_modules/react-dom/index.js patches/react-dom-index.js > patches/react-dom-bug.patch
```

```
--- node_modules/react-dom/index.js	1985-10-26 17:15:00.000000000 +0900
+++ patches/react-dom-index.js	2020-11-23 16:55:32.000000000 +0900
@@ -28,6 +28,8 @@
 }
 }

+console.log('==========REACT DOM START==========')
+
 if (process.env.NODE_ENV === 'production') {
 // DCE check should happen before ReactDOM bundle executes so that
 // DevTools can report bad minification during injection.
```

## 4. 적용하기

아까 지우고 다시 설치했기 때문에 버그가 있던 깔끔한 상태로 있을 것이다. 이에 패치 파일을 씌워보자.

```bash
patch --forward node_modules/react-dom/index.js < patches/react-dom-bug.patch
patching file node_modules/react-dom/index.js
```

적용이 잘되었는지 확인해보자. 잘 되었는지 확인 되었다면, 맨처음에 만들었던 파일 (버그 수정버전)을 삭제해도 된다.

```bash
rm patches/react-dom-index.js
```

## 5. `postinstall` 에 걸어두기

[npm postinstall](https://docs.npmjs.com/cli/v6/using-npm/scripts#npm-install)에 걸어두면 설치한 후애 해당 커맨드를 실행한다. `npm install` 과 `npm ci`에서 모두 동작한다.

`package.json`

```json
{
 "postinstall": "patch --forward node_modules/react-dom/index.js < patches/react-dom-bug.patch"
}
```

## 6. 기다리기

이제 오픈소스 컨트리뷰터가 해당 버그를 수정해주시기를 기도하자. 🙏🙏

이러고 있을 때가 아니고 이슈 업해서 오픈소스 컨트리뷰터가 되야 되는데

node_modules에 임시 패치 적용하기

100%의 테스트 리커버리가 도달한 이상적인 세계가 왔다. 오류 처리 또한 완벽했고, 모든 실패는 우아하게 처리되었다. 모든 시스템이 정말로 완벽에 도달했기 때문에, 이런 오류에서의 회복 같은 논의 따위는 필요가 없다.

그러나 나부터 시작해서, 2020년의 지구에는 아직 그런 이상적인 시스템이 있는 곳은 단언코 아무 곳도 없을 것이다. 누군가의 서버는 여전히 프로덕션에서 박살나고 있다.

이 글에서, 서버를 더욱 탄력적으로 만들고 프로세스 관리 능력을 향상시키는 몇가지 개념과 도구를 살펴보자.

## `node index.js`

Nodjs, 특히 서버 관련 작업을 처음 접하는 경우 원격 프로덕션이나, 개발 환경이든간에 동일한 방식으로 앱을 실행한다.

nodejs를 설치하고, repo를 clone하고, `npm install` 이후에 `node index.s`또는 `npm start` 로 시작한다.

이는 모든 프로젝트를 시작하는 완벽한 방법 처럼 보인다. 만약 이게 정말 제대로 작동만 한다면, 우리는 더이상 수정할 필요가 없다.

그러나 사전에 예상하지 못했던 발생할 수가 있다. vm또는 호스트가 재시작 된다면? 서버 크래쉬가 발생한다면?

복구(Recovery)는 다양한 방법으로 처리할 수 있다. 크래시 이후 서버를 다시 시작하는 편리한 솔루션도 있고, 프로덕션을 크래쉬로 부터 안전하게 만드는 것보다 더 우아한 방법들이 많다.

우리가 실행하려는 환경에 따라서, 복구는 다른 특성을 가지고 있다. 개발환경에서의 목표는 편의성이고 (코드를 수정하면 알아서 재시작 되는 것과같은), 프로덕션의 경우에는 오류로부터의 탄력성이라 볼 수 있다.

## 문제가 발생하자 마자 해결하기

개발 환경에서 nodejs 서버를 작성하고 있다고 상상해보자. 몇줄의 코드를 고칠 때마다 탭을 전환하여 `node index`나 `npm start`로 프로세스를 실행한다. 이는 몇번 반복하게 되면 끔찍할 정도로 지루해진다.

코드를 변경한 뒤에 자체적으로 그냥 재시작하면 좋지 않을까?

여기에서 도움이 되는 것이 바로 `nodemon`이다.

```bash
nodemon index.js
```

혹은 `Supervisor`를 동일한 방식으로 사용할 수도 있다.

```bash
supervisor index.js
```

두 서비스 보두 인기만큼이나 유용하다. 두 개의 차이점은, `nodemon`은 코드(파일)이 변경되면 재시작 되는 반면, `supervisor`는 에러가 발생할 때 다시 시작한다는 것이다.

개발 환경에서의 문제는 해결이 쉽다. 그러나 프로덕션 환경의 문제는 다르다. 프로덕션 서버에 내보내기 시작하면 대학을 보낸 부모마냥 안절부절해진다. 여기에서 사용하는 것이 프로세스 관리자다.

## 프로세스 관리

앱을 실행하게 되면, 프로세스가 생성된다.

개발환경에서는, 터미널 윈도우를 열고 코맨드를 실행한다. foreground proccess가 만들어 진것이며, 앱이 실행된다.

그러나 터미널 윈도우를 닫는다면, 앱 또한 종료된다. 또한 터미널 윈도우는 더이상 추가적인 작업을 할 수 없는 상태가 된다. `Ctrl+c`로 끄지 않는 이상, 터미널은 사용할 수 없게 된다.앱 실행이 터미널 윈도우와 강하게 연결되어 있기 때문에, 로그와 에러 또한 볼 수 있다. 그러나 프로덕션 서버에서는 앱을 백그라운드에서 실행해야 하기 때문에 이러한 장점을 잃게 된다.

이 때 등장하는 것이 프로세스 관리자다.

### PM2

nodejs에서 가장 널리 쓰이는 프로세스 관리자는 [PM2](https://github.com/Unitech/pm2)다. `PM2`를 설치하고 아래 명령어로 실행하면 된다.

```bash
pm2 start index.js
```

```bash
===============================================================================
--- PM2 development mode ------------------------------------------------------
Apps started : src
Processes started : 1
Watch and Restart : Enabled
Ignored folder : node_modules
===============================================================================
```

실행하게 되면, 무언가 다른점을 눈치챌 수 있을 것이다. 마치 아무것도 일어나지 않는 것처럼 보이지만, 앱의 엔드포인트로 가면 앱이 실행중인 것을 알 수 있다. `PM2`는 앞서 언급된 것처럼, 앱을 백그라운드에서 실행하게 해준다. 또한 `--watch` 명령어로 pm2가 파일을 감시하고 재시작하는 것을 볼 수도 있다.

```bash
pm2 start index.js --watch
```

그럼에도 여전히 가시성이 조금은 부족하다. 서버로그를 보기 위해서는, 아래와 같은 명령어를 쓰면 된다.

https://blog.appsignal.com/2020/09/09/nodejs-resiliency-concepts-recovery-and-self-healing.html

| command | Description |
| ----------------- | --------------------------------------------------------------------------------------------------------------------- |
| `pm2 list` | 앱의 목록을 보여준다. pm2에서 관리하고 있는 애플리케이션의 ID를 볼 수 있다. 이 아이디로 아래 명령어를 실행할 수 있다. |
| `pm2 logs <id>` | 앱의 로그를 확인한다. |
| `pm2 stop <id>` | 프로세스를 중단한다. 단순히 중단만 되는 것이므로, 프로세스까지 제거하기 위해서는 `delete` 를 사용해야 한다. |
| `pm2 delete <id>` | 프로세스를 지운다. 지우게 되면 `stop` 도 이루어진다. |

`pm2` 는 설정하기 용이하며, 로드밸런싱도 수행할 수 있고, hot reload도 가능하다.

`pm2`는 놀랍도록 편리하지만, 몇가지더 살펴볼 것이 존재한다.

## Systemd

만약 Linux VM에서 앱을 실행하려고 계획중이라면, 컨테이너와 오케스트레이터 개념을 깊게 들어가기이전에 `systemd`를 언급할 필요가 있다. (그러나 Azure, AWS Lambda, GCP App Engine 등에서 실행하려고 준비중이라면 그다지 필요가 없다.)

`systemd`는 프로세스를 시작, 중지, 재시작을 할수가 있다. VM이 재시작 된다면, `systemd`는 앱이 다시 시작하게끔 도와준다.

`systemd`는 다음 시스템에서 사용가능하다.

- Ubuntu Xenial 또는 그 이상
- Centos 7 / RHGEL 7
- Debian Jessie 또는 그 이상
- Fedora 15 또는 그 이상

추가로 확인해야 할 것은 해당 유저가 `sudo`권한이 있어야 한다는 것이다.

이제부터 예제는 `Ubuntu`를 사용하고 있고, 홈 디렉토리는 `/home/user/`라고 가정하며,`index.js`는 이 홈 디렉토리에 있다고 가정한다.

### systemd 서비스 파일

`systemd` 파일은 서비스에 대한 설정을 보관할 수 있는 시스템영역을 만드는데 도움을 주는 파일이다. 먼저 한번 설정해보자.

`systemd` 파일은 아래 디렉토리에 존재한다.

```bash
/lib/systemd/system
```

```bash
cd /lib/systemd/system
```

```bash
sudo nano myapp.service
```

그리고 이 파일을 만들어보자.

```bash
# /lib/systemd/system/myapp.service

[Unit]
Description=My awesome server
Documentation=https://awesomeserver.com
After=network.target

[Service]
Environment=NODE_PORT=3000
Environment=NODE_ENV=production
Type=simple
User=user
ExecStart=/usr/bin/node /home/user/index.js
Restart=on-failure

[Install]
WantedBy=multi-user.target
```

몇가지 설정들은 꽤 분명하게 되어 있지만, `After` `Type`에 대해서만 알아보자.

`After=network.target`은 포트가 필요하기 때문에, 서버의 네트워킹이 가동되고 실행될 때 까지 기다려야 한다는 것을 의미한다. `Type`은 단순히 미친짓 하지말고 실행하라는 것을 의미한다.

### systemctl로 앱 실행하기

파일을 생성했으니, `systemd`에게 새롭게 변경된 파일을 이용하라고 알려줄 때다. 이 파일에 변화가 있으면, 아래 명령어를 계속 실행해야 한다.

```bash
sudo systemctl daemon-reload
```

이제 `systemctl` 명령을 사용하여 서비스를 시작하고 중지할 수 있어야 한다.

```bash
sudo systemctl start myapp
```

멈추고 싶다면 `stop`을, 재시작하고 싶다면 `restart`를 쓰면 된다.

이제 제일 중요한 부분이다. VM이 실행될 때 애플리케이션이 자동으로 시작되게 하고 싶다면, 아래 명령어를 입력하면 된다.

```bash
sudo systemctl enable myapp
```

작동중지는 `disable`을 쓰면 된다.

이게 전부다. 이제 Node.js가 아닌 프로세스를 관리를 하는 다른 시스템이 생겼다.

하지만 아마도 🤔 요즘 이렇게 리눅스 VM에 직접 서비스를 올려서 굴리는 시스템은 별로 없을 것이다......... 컨테이너로 넘어갈 차례다.

## 컨테이너란 무엇인가

Mesos, CoreOS, LXC, OpenVZ 등 다양한 컨테이너 런타임 환경이 존재하지만, 아마도 가장 유명한 것, 그리고 컨테이너의 진정한 동의어로 취급받는 것은 Docker다. 현재 컨테이너로 굴러가는 시스템의 80%가 Docker로 이루어져 있고, 사람들이 컨테이너를 이야기 하면 아마두 열에 아홉은 도커를 이야기 하고 있다고 봐도 무방하다.

컨테이너가 하는 일은 정확히 무엇인가? 컨테이넌 말그대로 컨테이너다. 그리고 이 컨테이너에는 무엇을 보관하고 있을까?

컨테이너에는 응용프로그램과 그에 필요한 모든 종속성이 포함되어 있다. 단순히 그것 뿐이다. 그렇다면 Nodejs 서버가 가지고 있어야 할 것이 있는지 생각해보자. Nodejs, index.js파일, 그리도 npm 패키지 종속성들이 필요할 것이다. 따라서 컨테이너를 만든다면, 이것이 존재하며 제대로 담겨있는지 확인하고 싶을 것이다. 그리고 컨테이너가 준비되어 있다면, 컨테이너를 컨테이너 엔진(도커)를 이용해 실행 시킬 수 있다.

### Container vs VM

Docker의 마법은 동일한 기반의 물리적 시스템과 운영체제를 사용하여 서로 충돌하지 않고, 다양한 형태의, 다양한 애플리케이션을 원활하게 실행할 수 있다는 것이다.

### 도커 컨테이너 만들기

도커 컨테이너를 만드는 것은 정말로 쉽다. 로컬 머신에 Docker를 먼저 설치하면 된다. Docker는 어떤 운영체제에서든 설치가 가능하지만, 프로덕션 머신에는 Linux 환경에서 설치하기를 권한다.

도커는 `Dockerfile`이라고 불리우는 파일을 참조하며, 도커 이미지라고 불리우는 컨테이너의 레시피를 만드는데 사용할 것이다. 따라서 컨테이너를 만들기 전에 이 파일을 생성해야 한다. `index.js`와 동일한 위치에 생성하면 된다.

```Dockerfile
# Dockerfile

# Base image (we need Node)
FROM node:12

# Work directory
WORKDIR /usr/myapp

# Install dependencies
COPY ./package*.json ./

RUN npm install

# Copy app source code
COPY ./ ./

# Set environment variables you need (if you need any)
ENV NODE_ENV='production'
ENV PORT=3000

# Expose the port 3000 on the container so we can access it
EXPOSE 3000

# Specify your start command, divided by commas
CMD [ "node", "index.js" ]
```

`.dockerignore`를 사용하면 `node_modules`와 같이 복사를 원치 않는 파일목록을 명시할 수 있다. `.gitignore`와 정확히 똑같이 동작한다.

```Dockerfile
# .dockerignore

node_modules
npm-debug.log
```

이제 설정이 완료되었고, Docker Image를 만들 차례다.

이미지는 컨테이너를 만드는 일종의 레시피다. 또는 소프트웨어를 인스톨을 하기 위한 플로피 디스크/씨디롬과 같은 존재로도 볼 수 있다. 이는 실제 작동하는 소프트웨어가 아니지만, 패키징된 소프트웨어 데이터를 포함하고 있다고 보면 된다.

```bash
docker build -t myapp .
```

이미지가 준비되어있다면, 이미지 목록에서 확인할 수 있다.

```bash
docker image ls
```

그리고 실행은 아래와 같이 하면 된다.

```bash
docker run -p 3000:3000 myapp
```

컨테이너에서 시작하는 서버를 볼 수 있고, 그 과정에서 로그도 확인할 수 있다. 백그라운드에서 실행시키기 위해서는 `-d` 플래그를 사용하면 된다. 또한 컨테이너를 백그라운드에서 실행중인 경우, 아래 명령어를 활용하여 컨테이너 목록을 확인할 수 있다.

```bash
docker container ls
```

이제 컨테이너에 대한 이해는 마쳤으므로, 원래 글의 주제인 복구와 매우 밀접한 오케스트레이션에 대해 알아보자.

## Orchestration

이상적으로 생각해봤을때, 레고블록과 같은 인프라는 개별적으로 관리하는 것은 굉장히 손이 많이 가기 때문에 어렵다. 앞서 이야기한 프로세스 관리자 처럼, 다른 존재가 이러한 관리를 대신 해주는 것이 좋을 것이다. 여기에서 오케스트레이터가 활약한다.

오케스트레이터는 컨에테이너를 관리하고 스케줄링 할 수 있도록 도와주며, 여러 위치에 분산되어 흩어져있는 VM (컨테이너 호스트)에 걸쳐서 이러한 작업을 할 수 있도록 해준다.

여기에서 우리가 특히 관심을 가져야 하는 것은 `Replication`이다.

### Replication과 높은 가용성

크래시가 발생했을 때 서버가 재기동하는 것은 좋은일이다. 그러나 재기동 중에는 어떤 일이 생기는가? 사용자들이 서비스가 다시 시작 되길 기다려야 하는가? 우리의 목표는 서비스를 고 가용성으로 만드는 것인데, 이는 사용자들이 서버에서 크래시가 있어도 앱을 사용할 수 있어야 함을 의미한다. 어떻게 하면 가능할까?

답은 간단하다. 서버의 복사본을 만들어두고, 동시에 실행하는 것이다.

처음에 이를 설정하는 것은 골치 아프지만, 다행히도 이 매커니즘을 가능하게 하는 모든 것을 가지고 있다. 일단 앱이 컨테이너화가 되어 있으면, 원하는 만큼의 복사본을 실행할 수 있는데 이를 Replica라고 한다.

이제 컨테이너 오케스트레이션 엔진을 활용하여, 어떻게 이를 설정할지를 알아보자. 여러가지 방법이 있지만, 도커 오케스트레이션 엔진과 가장 쉽게 할 수 있는 방법은 Docker Swarm이다.

### swarm 내의 replication

머신에 Docker가 설치 되어있다면, docker swarm은 비교적 간단하게 시작할 수 있다.

```bash
docker swarm init
```

이 명령어로 Docker swarm을 사용할 수 있으며, 다른 VM을 스웜에 연결하여 분산 클러스터를 구성하라 수 있다. 이번 예제에서는, 단순히 하나의 머신만 사용할 것이다.

스웜이 활성화 되어 있으면, 서비스라 불리우는 컴포넌트에 접근할 수 있게 된다. 이는 일종의 마이크로 서비스 아키텍쳐의 빵과 버터인데, replica를 만들기 쉽게 해준다.

이제 서비스를 만들어 보자.

```bash
docker service create --name myawesomeservice --replicas 3 myapp
```

위 명령어는 `myawesomeservice`라 불리우는 서비스를 만들어주며, `myapp`이라고 하는 이미지를 활용하여 3개의 동일한 컨테이너를 만들게 된다.

```bash
docker service ls
```

이제 서버가 복제되어 실행되며, 컨테이너가 크래쉬가 되도 재시작 되며, 프로세스 전체에 결쳐 온전한 컨테이너 엑세스를 제공할 수 있다. 서비스 replica의 수를 조정하기 위해서는 아래 명령어를 활용하면 된다.

```bash
docker service scale <name_of_service>=<number_of_replicas>
```

```bash
docker service scale myapp=5
```

이제 원하는 만큼 복제본을 만들어 실행시킬 수 있다.

### 쿠버네틱스에서의 replication

오케스트레이션을 논하는데 쿠버네틱스를 빼먹으면 섭섭하다. 컨테이너하면 도커 듯이, 오케스트레이션하면 쿠버네틱스다.

개인적인 의견으로는, 도커의 스웜보다 쿠버네틱스가 더 학습하기 어렵다. 따라서 이제 막 컨테이너를 시작했다면, 도커 스웜을 먼저 해보는 것이 좋다. 그렇긴하더라도, 쿠버네틱스 세계가 어떻게 작동하는지 이해하는 것도 나쁘지 않다.

- https://minikube.sigs.k8s.io/docs/start/
- https://labs.play-with-k8s.com/

이 예제에서는 두개의 yaml파일을 만들어 설정을 진행한다. 하나는 A 클러스터 IP 인데, 이는 앱과 통신할 수 있는 포트를 연다. 또다른 하나는 도커 스웜과 같은 서비스이다.

`cluster-ip.yml`

```yaml
# cluster-ip.yml

apiVersion: v1
kind: Service
metadata:
 name: cluster-ip-service
spec:
 type: ClusterIP
 selector:
 component: server
 ports:
 - port: 3000
 targetPort: 3000
```

`development.yml`

```yaml
# deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
 name: server-deployment
spec:
 replicas: 3
 selector:
 matchLabels:
 component: server
 template:
 metadata:
 labels:
 component: server
 spec:
 containers:
 - name: server
 image: your_docker_user/your_image
 ports:
 - containerPort: 3000
```

`your_docker_user/your_image`를 실제 도커 유저와 이미지로 교체하고, 도커 레포에 해당 이미지가 호스팅 되고 있는지 확인해야 한다.

이제 아래 명령어를 실행해보자.

```bash
kubectl apply -f .
```

이제 서비스가 실행되고 있는지, 아래 명령어로 확인해볼 수 있다.

```bash
kubectl get deployments
kubectl get services
```

모든 것이 정상적으로 되고 있다면, `cluster-ip-service`에서 보여주는 IP와 포트를 복사하여 브라우저에 붙여넣기 한다면, 애플리케이션에 접속할 수 있을 것이다.

생성된 복제본을 보고 싶다면, 아래 명령어를 활용하면 된다.

```bash
kubectl get pods
```

나열된 pod는 `deployment.yaml`에 지정한 replica의 수와 일치해야 한다. 모든 컴포넌트를 정리하기 위해서는, 아래 명령어를 사용하면 된다.

```bash
kubectl delete -f .
```

## 결론

이제 우리는 고 가용성의 복구 가능한 애플리케이션을 가지고 있다. 물론, 이게 다가 아니다.

실제로 애플리케이션이 고장이 나지 않는데, 어떤 문제가 있는지 어떻게 알까?

로그를 확인해야할까? 만약 엔드포인트를 확인할 때마다 앱이 작동한다면, 아마도 일년에 한두번 정도만 로그를 볼 것이다. 따라서 앱이 개선되고 있는지 확인하기 위해서는 모니터링, 오류처리 및 오류 전파에 대해서 생각해볼 필요가 있다. 문제가 발생할 때마다 인지하고, 서버를 다운시키지 않더라도 문제를 해결할 수 있도록 해봐야 한다.

출처: https://blog.appsignal.com/2020/09/09/nodejs-resiliency-concepts-recovery-and-self-healing.html

아 내 서비스는 완벽해서 그런거 필요 없다니까요?

yceffort

PWA 적용 후기 및 장단점

웹에서 사용 가능한 스토리지 살펴보기

자바스크립트로 메모이제이션 구현하기

node_modules에 임시 패치 적용하기

Nodejs 서비스 Recovery 전략