클라우드 네이티브 프로그래밍을 위한 쿠버네티스 개발 전략


![image](https://github.com/prefer2/algorithm/assets/67692759/b3cffcb3-769c-48eb-92f1-1f8f7016a4d7)

## typescript array 값들중 하나인지 좁히기

하고싶었던 것, 가능한 값들을 array로 뽑아두고 ⇒ 이것들을 타입화 하기

요렇게 하면 type narrowing 할때 includes를 사용하지 못함(include가 타입관련된 정보를 바라보지 않음) 어쩌면 원하는 값들을 배열로 관리하는것이 적절하지 않은 방법이었을지도 모르겠다는 생각이 든다

[https://elvanov.com/2535](https://elvanov.com/2535)

[https://fettblog.eu/typescript-array-includes/](https://fettblog.eu/typescript-array-includes/)

[https://stackoverflow.com/questions/74077651/includes-method-doesnt-support-type-narrowing](https://stackoverflow.com/questions/74077651/includes-method-doesnt-support-type-narrowing)

---

## returnUrl, redirectUrl

백엔드와 어떻게 소통할 것인가, 뿐만 아니라 우리가 외부 서비스에게 어떻게 제공할 것인가

서비스마다 사용하는 용어가 달라서 혼란(backUrl, cancelUrl, successUrl 등등…)

---

## fiddler, charlse

[https://stackify.com/fiddler-vs-charles/](https://stackify.com/fiddler-vs-charles/)

학교에서는 wireshark만 써봤었는데 이런 훌륭한 툴들이…!

---

## typescript satisfies

[https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html)

[https://engineering.ab180.co/stories/satisfies-safe-upcasting](https://engineering.ab180.co/stories/satisfies-safe-upcasting)

---

## bf cache

[https://web.dev/articles/bfcache?hl=ko](https://web.dev/articles/bfcache?hl=ko)

bfcache는 사용자가 다른 페이지로 이동할 때 페이지의 전체 스냅샷(자바스크립트 힙 포함)을 저장하는 메모리 내 캐시. 메모리에 전체 페이지가 있으므로 사용자가 다시 돌아오기로 하면 브라우저에서 빠르고 쉽게 페이지를 복원할 수 있다.

bfcache를 사용하면 탐색 속도가 향상될 뿐만 아니라 리소스를 다시 다운로드할 필요가 없으므로 데이터 사용량도 줄어든다

setTimeout과 같은 비동기 처리는 어떻게? ⇒ promise 실행을 일시 중지하고 페이지가 bfcache에서 복원될 때 처리 작업을 재개한다

bfcache를 관찰하는 API

- bfcache는 브라우저에서 지원하는 최적화이기 때문에 이를 관찰하기 위해서는 몇가지 이벤트를 보면 된다
- `pageshow`, `pagehide`
- chromium기반 브라우저에서는 최신 생명주기인 `freezes`, `resume`을 사용할 수 있다

`pageshow` 속성은 페이지가 처음 로드될 때 그리고 bfcache로부터 복원될때마다 load 이벤트 직후에 실행된다. `persisted`라는 속성으로 pageshow시 bfcache로부터 복원되었는지 확일할 수 있다

```tsx
window.addEventListener("pageshow", (event) => {
  if (event.persisted) {
    console.log("This page was restored from the bfcache.");
  } else {
    console.log("This page was loaded normally.");
  }
});
```

`pagehide` 이벤트는 페이지가 정상적으로 로드 해제되거나 bfcache에 넣을려고 할때 실행된다. pagehide에도 `persisted` 속성이 있는데 bfcache에 들어가면 true가 된다. 다만 이 값이 true라고 해서 페이지가 캐시된다는 보장은 없다(저장을 했다일뿐이지 사용을 한다는 보장은 하지 못한다)

테스트 방법

- application > cache > back-forward cache

---

## 짧은 회고

여기에는 적을 수 없는 인프라 관련 학습을 많이 하는 중이다(안하던거라 재미있긴함) 네트워크나 큰 그림에 대한 공부를 학교다닐때 많이 했어야했는데 네트워크 싫어병에 걸려서 안했던게 후회된다. 2월도 얼래벌래 끝나버렸다. 3월은 이사라는 아주아주아주 큰 이벤트가 나를 기다리고 있기 때문에 기대중이다. 기대된다 3월!!!


이번달은 너무 빨리 끝나버렸다

[WIL] 2024.02


![image](https://github.com/prefer2/prefer2.dev/assets/67692759/dff7b89c-84e1-4232-b0eb-2969d6c841f0)

## unwrap

[https://redux-toolkit.js.org/api/createAsyncThunk#handling-thunk-results](https://redux-toolkit.js.org/api/createAsyncThunk#handling-thunk-results)

createAsyncThunk로 생성한 thunk는 무조건 promise를 반환한다. 이렇게 반환한 promise는 unwrap 프로퍼티가 있는데 이를 통해 fullfiled된 액션의 payload를 받거나, error를 던지거나, rejected action에서 rejectWithValue로 생성한 payload를 받을 수 있다

```tsx
const onClick = () => {
  dispatch(fetchUserById(userId))
    .unwrap()
    .then((originalPromiseResult) => {
      // handle result here
    })
    .catch((rejectedValueOrSerializedError) => {
      // handle error here
    });
};
```

```tsx
const onClick = async () => {
  try {
    const originalPromiseResult = await dispatch(
      fetchUserById(userId)
    ).unwrap();
    // handle result here
  } catch (rejectedValueOrSerializedError) {
    // handle error here
  }
};
```

언제 사용할까?

action의 fullfilled, rejected 후의 행동이 각 컴포넌트 별로 다를 때(공통적으로 처리가 어려울 때)

If you need to access the error or success payload immediately after a mutation, you can chain `.unwrap()`.

```tsx
addPost({ id: 1, name: "Example" })
  .unwrap()
  .then((payload) => console.log("fulfilled", payload))
  .catch((error) => console.error("rejected", error));
```

> However, it's common to want to write logic that looks at the success or failure of the actual request that was made. Redux Toolkit adds a `.unwrap()` function to the returned `Promise`, which will return a new `Promise` that either has the actual `action.payload` value from a `fulfilled` action, or throws an error if it's the `rejected` action. This lets us handle success and failure in the component using normal `try/catch` logic. So, we'll clear out the input fields to reset the form if the post was successfully created, and log the error to the console if it failed.

---

## Node exporter

[https://github.com/prometheus/node_exporter](https://github.com/prometheus/node_exporter)

[https://prometheus.io/docs/guides/node-exporter/](https://prometheus.io/docs/guides/node-exporter/)

모니터링 데이터를 프로메테우스로 수집하고, 수집한 정보를 한 곳에 모아(통합), 그라파나로 시각화한다고 이해정도만 한 정도…

TL님이 시간 있을때 한번 공부해보면 좋을 것 같다고 추천해주셨다. 최근 새로운 프로젝트를 진행하면서 로그를 추가해줄 일이 있었는데 회사의 로깅 시스템은 정말 잘 되어있는것 같다. 쭉 보다보니 회의때 듣던 이게 무슨 단어이지 싶은 단어들이 많이 나타나는게 아주 공부할게 많은 것 같다. 물론 이미 추상화가 잘되어 있고 미들웨어로 쓱싹하면 로그가 짠하고 나타나지만 공부하면 나쁠거 없지!

[https://d2.naver.com/helloworld/1044388](https://d2.naver.com/helloworld/1044388)

옛날 글이고 지금은 무려 nelo4지만 여기에 적을 수 있는 유일한 글인것 같아 남겨놓기

---

## 브라우저 디버깅

모던리액트 deep dive 중 내용

- 소스탭 > 감시, 범위(스코프), 호출스택, 전역 리스너 등을 확인할 수 있다. 실행하는 파일을 직접 볼 수 있는 것 뿐만 아니라 어떻게 실행되는지 자세하게 알 수 있다. 심지어 감시에 변수 값을 넣어서 원하는 값으로 변경하는 기능도 가능
- 메모리탭
  - 힙 스냅샷 > 비교를 통해 useMemo, useCallback과 같은 값들이 유지되는지 확인할 수 있다 ⇒ 실제로 함수가 재생성되는지 함수명을 기명함수로 두어 확인
  - 타임라인 할당 계측 ⇒ 시간의 흐름에 따른 메모리 변화, 어떤 변수가 일으켰는지

디버깅을 브라우저로 기깔나게 하시는걸 보고… 자스에서도 console.log 디버깅이 아닌 디버깅이 가능한걸 배우고 있는 요즘이다. hover하면 해당 값이 어떤 값 들어갔는지도 잘 볼 수 있고 소스탭을 잘 사용해보자

---

## 짧은 회고

공개될려면 좀 멀었지만 신규 서비스가 하나 완성되었다. 함께 진행하신 분과 하면서 배운게 여러가지인데 코드를 이쁘게 짜는걸 보며 감동받았다. 훅 분리나 로직 분리를 보면서 대박이다라는 생각을 속으로만 계속 하는중ㅋㅋ 나는 아직 예외처리같은 부분은 많이 부족하다고 느꼈는데 불필요한 코드를 작성하는 것은 아닌가라는 생각을(이걸 더하면 지저분해지는 것이 아닐까라는 생각) 줄이고 방어코드를 잘 작성해야겠다. 내가 작성하는 코드의 영향범위를 잘 파악하고 자신감을 가지자! 팀원분들의 좋은점은 많이 배우고 싶다.

집을 구하는 중인데 덕분에 부동산 용어나 돈의 개념에 대해서 생각이 많아지는 요즘이다. 돈의 속성이라는 책이 기본서라는데 한번 읽어봐야하는가 싶다. 좋은 집을 잘 구할 수 있으면 좋겠다.

+) 매주 글작성은 너무 무리라 한달 단위로 변경할래


[WIL] 2024.01


![image](https://github.com/prefer2/algorithm/assets/67692759/6132204c-b408-4c01-8a4a-dbf5f65092e8)

## chap1. 도커란 무엇인가?

`데이터 또는 프로그램을 격리시키는 기능을 제공`하는 소프트웨어

다양한 프로그램과 데이터를 각각 독립된 환경에 격리(운영체제 비슷한 것으로 통째로)하는 기능을 제공

컨테이너를 다루는 기능을 제공하는 소프트웨어가 도커

도커 소프트웨어 본체인 도커 엔진을 설치하고, 엔진을 사용해 컨테이너를 생성하고 구동할 수 있다

컨테이너를 만들기 위해 이미지가 필요

용량이 허락하는 한 도커에서 여러개의 컨테이너를 만들 수 있다

컨테이너 내부적으로는 리눅스가 사용되고, 컨테이너에서 동작시킬 프로그램도 리눅스용 프로그램이다

### 데이터나 프로그램을 독립된 환경에 격리해야 하는 이유

여러 프로그램으로 구성되며, 다른 프로그램과 정보를 공유하기도 하기 때문

특정한 폴더나 디렉터리를 공유하거나 같은 설정 정보를 저장하는 경우

프로그램 간의 공유가 있을때도 있고, 프로그램에 따라서는 한 서버에 한 버전밖에 설치할 수 없기 때문에

컨테이너 안의 프로그램은 다른 프로그램과 격리됨

도커 컨테이너는 완전히 독립된 환경이므로 여러 컨테이너에서 같은 프로그램을 실행할 수 있다

## 서버와 도커

서버? 어떤 서비스(service)를 제공(serve)하는 것

물리적 컴퓨터로서의 서버에 여러개의 기능적 의미의 서버를 둘 수 있다

서버의 기능은 소프트웨어가 제공하는 것으로, 소프트웨어를 설치하면 서버의 기능을 갖게 된다

여러 가지의 소프트웨어를 한 컴퓨터에 설치할 수 있다 === 물리적 컴퓨터로서의 서버에 여러개의 기능적 의미의 서버를 둘 수 있다

도커를 이용하면 컨테이너를 사용해 한 서버에 여러가지 서버를 돌릴 수 있다

일반적으로 한 대의 서버 컴퓨터에는 웹 서버(아파치 한 벌)를 한벌밖에 실행 하지 못한다 ⇒ 컨테이너를 활용하면 여러 개의 웹 서버를 올릴 수 있다

물리 서버 한대에 여러개의 웹 서버를 띄워 서버수를 줄일 수 있다

컨테이너는 자유롭게 옮길 수 있다. 컨테이너를 어떤 도커 엔진에서 다른 도커 엔진으로 옮기는 것이 어렵지 않다

똑같은 상태로 튜닝한 컨테이너를 배포해 모두가 동일한 개발환경을 사용할 수 있다

도커를 이용하면 물리적 환경의 차이, 서버 구성의 차이를 무시할 수 있으므로 운영 서버와 개발 서버의 환경 차이로 인한 문제를 방지할 수 있다

```bash
💡 도커와 가상화 기술의 차이
VirtualBox나 VMware와 같은 기술은 물리적인 대상을 소프트웨어로 대체해 가상의 물리 서버를 만드는 것
도커는 운영체제의 기능 중 일부를 호스트 역할을 하는 물리 서버에게 맡겨 부담을 더는 형태
컨테이너는 운영체제의 일부 기능을 호스트에 의존하기 때문에 물리 서버에도 리눅스 기능이 필요
EC2도 가상화 기능. 각각의 인스턴스가 완전히 독립된 컴퓨터처럼 동작.
```

---

## chap2. 도커의 동작 원리

### 도커의 구조

운영체제 위에 도커 엔진이 동작하고 그 위에서 컨테이너가 동작한다

운영체제는 소프트웨어나 프로그램의 명령을 하드웨어에게 전달

운영체제는 커널과 그 외의 부분으로 이루어져 있다(system call같은 부분은 명칭하는 걸까)

컨테이너 속에는 운영체제의 주변 부분이 들어 있어 프로그램의 명령을 전달받고 ⇒ 커널에 전달하는 구조

도커는 밑바탕에서 리눅스 운영체제가 동작하는 것을 전제로 하는 구조기 때문에 기본적으로 리눅스용이다

### 도커 허브와 이미지, 그리고 컨테이너

이미지는 컨테이너를 찍어내는 빵틀과 같은 설계도 ⇒ 하나만 있어도 똑같은 형태를 만들기 쉽다

컨테이너로도 이미지를 만들 수 있는데, 덕분에 여러개의 컨테이너를 일일이 수정할 필요가 없다

도커 엔진 간에 이동이 가능하다 === 도커 엔진에 이미지를 통해 똑같은 컨테이너를 생성할 수 있다(실제로 이동하는 것은 아니지만 컨테이너를 통해 이동한 것과 같은 효과)

#### 도커 허브

도커 허브는 공개된 컨테이너 이미지가 모여있는 곳

도커 허브는 누구나 자유롭게 등록할 수 있기 때문에 안전한 이미지를 잘 선택해야 한다

### 도커 컨테이너의 생애주기와 데이터 저장

컨테이너는 쓰고 버리는 일회용품 같은 것

컨테이너는 쉽게 만들 수 있기 때문에 업데이트하기 보다는 새로운 컨테이너를 사용하는 것이 좋다

컨테이너를 폐기하면 컨테이너에 들어있던 데이터는 사라진다 ⇒ 도커가 설치된 물리적 서버(호스트)의 디스크를 마운트해 여기에 데이터를 저장한다

데이터를 외부에 저장해 다른 컨테이너와 데이터를 공유할 수도 있다

- 운영체제 부분은 컨테이너로 만들어 쓰고 버리는 것을 반복하고, 데이터는 다른 곳에 두고 같은 것을 계속 사용하는 것

### 도커의 장점과 단점

- 독립된 환경
- 이미지를 만들고 이를 쉽게 도커 허브에 배포할 수 있다
- 컨테이너에 커널을 포함시킬 필요가 없다 === 가볍다

#### 장점

- 한대의 물리 서버에 여러 대의 서버를 띄울 수 있다
  - 격리된 환경으로 안전하게 여러 서버를 제공할 수 있다
  - 물리 서버의 운영체제에 의존하기 때문에 가상화 기술에 비해 압도적으로 가볍다
- 서버 관리가 용이하다
  - 독립된 환경에 격리함으로 다른 소프트웨어에 영향을 끼치지 않는다
  - 교체나 수정이 쉬워 환경 이전도 쉽다
- 서버 고수가 아니어도 다루기 쉽다
  - 명령 한줄로 서버 구축이 끝난다

#### 단점

- 리눅스용이다
- 호스트 서버에 문제가 생기면 모든 컨테이너에 영향이 미친다

#### 도커의 주 용도

- 팀원 모두에게 동일한 개발환경 제공
- 새로운 버전의 테스트(=격리된 환경을 이용)
- 동일한 서버가 여러대 필요한 경우


하나씩 알아보자 도커! (1, 2장 정리)

그림과 실습으로 배우는 도커 & 쿠버네티스


![image](https://github.com/prefer2/prefer2.dev/assets/67692759/dd5b5098-31ff-42af-8d22-dea4ac775e58)

### on-premise

온프레미스(on-premise)는 IT 서비스를 운영하는 회사가 자체적으로 보유한 공간에 물리적으로 하드웨어 장비를 가지고 직접 운영하는 방식. on-premise는 클라우드 컴퓨팅 기술이 나오기 전까지 일반적인 기업이 사용하던 일반적인 인프라 구축 방식

---

### lease force push

> safer option that will not overwrite any work on the remote branch if more commits were added to the remote branch (by another team-member or coworker or what have you). It ensures you do not overwrite someone elses work by force pushing

브랜치에 지금까지 그 누구도 변화를 준 적이 없는지 확인하고, 변화가 있다면 강제 푸시를 못하도록 거부한다

팀원들과 협업을 할 때 보다 안전하게 force push 할 수 있도록 해준다

---

### spread operator typescript

[https://github.com/microsoft/TypeScript/issues/39998](https://github.com/microsoft/TypeScript/issues/39998)

아무 생각 없이 spread operator를 쓰는 편이었는데 type safety를 위해서는 함부로 사용하면 안될 것 같다. 내가 생각한 타이핑대로 잘 되는지 확인하면서 작업하자

---

### zod

[https://zod.dev/](https://zod.dev/)

> zod is a **TypeScript-first schema declaration** and **validation library.**

유효성 검증을 통한 타입 제공을 해주는 라이브러리. 알다시피 타입스크립트는 컴파일 타임의 타입만을 제공해주기 때문에 런타임에서의 타입 에러는 어찌 할 수 없다. 스키마라는 유효성 검증 단계를 통해서 이런 부족함을 채워준다

런타임에서의 타입 검증이 왜 필요했는데? ⇒ bff를 구성할 때 필요했다. api응답값은 런타임에 어떤 값이 내려올지 모르기 때문에 이를 검증하는 과정이 필요한데 유효성 검증과 타입 작성을 둘다 해주는건 비슷한 일을 두번 해주는 것이다. 이러저러한 사정으로 사용하지 못했지만…

---

### Langchain

[https://github.com/langchain-ai/langchain](https://github.com/langchain-ai/langchain)

[https://www.samsungsds.com/kr/insights/what-is-langchain.html](https://www.samsungsds.com/kr/insights/what-is-langchain.html)

무려 js도 지원해준다. 미래를 위해 단어라도 알아놓아야지

---

### 짧은 회고

취뽀와 야근이라는 핑계로 꽤나 오랜 시간동안 공부를 멀리했다. 노는 것도 지치기도 했고 지식의 부족함을 느끼기도 하고 시간을 정해서 공부를 해야겠다. 모리딥다 스터디와 도커&k8s 알아보기 스터디를 시작했는데 강제성이 생기니 책도 읽게 되고 좋다! 역시 강제성이 없으면 공부를 안하는 사람인 것 같다. 잔디 채울겸 일하면서 정리했던 내용들을 올려봐야지


[WIL] 12월 3주차


요번에 과제를 진행하며 기존 프로젝트 install 및 새로운 프로젝트 셋팅을 할 경험을 했습니다. 이 과정에서 가장 많이 사용했던 npm에 대해 조금 더 자세히 알아보고 과정에서 궁금했던 점들을 정리해보고자 합니다

## npm?

node package manager. Node.js에서 사용할 수 있는 **모듈들을 패키지화**하여 모아둔 저장소 역할과 패키지 설치 및 관리를 위한 CLI(Command line interface)를 제공한다. 자신이 작성한 패키지를 공개할 수도 있고 필요한 패키지를 검색하여 재사용할 수도 있다.

_npm github을 읽다 알게 되었는데 npm은 node pacakge manager의 줄임말이 아니라고 한다. 따라서 대문자 NPM이 아닌 npm으로 적어달라고ㅋㅋ_

## package.json

`package.json`은 프로젝트 정보와 의존성(dependencies)을 관리하는 문서. npm에 패키지를 배포하고 npm registry에 올리기 위해 반드시 필요한 문서이다.

- 자신의 프로젝트가 의존하는 패키지 목록
- 자신의 프로젝트 버전
- 다른 환경에서도 빌드 할 수 있게 만들어, 다른 개발자도 쉽게 사용할 수 있도록 한다

즉, npm이라는 오픈소스에 패키지를 공유하기 위한 명세이자, 프로젝트의 의존성을 관리를 위한 명세를 관리하는 문서이다.

### tilde, caret

- 틸드(~): x.y.z 중 z 범위 내에서 버전 업데이트
  - ~1.2.3: >=1.2.3 <1.3.0
- 캐럿(^): x.y.z 중 x 이하 하위호환성이 보장되는 범위 내에서 버전 업데이트
  - ^1.2.3: >=1.2.3 <2.0.0

### package-lock.json

`package-lock.json` 파일은 npm을 사용해서 `node_modules` 트리나 `package.json` 파일을 수정하게 되면 자동으로 생성되는 파일이다. 이 파일은 파일이 생성되는 시점의 의존성 트리에 대한 정확한 정보를 가지고 있다.

package.json 파일이 존재하지만 package-lock.json 파일이 필요한 이유는 무엇일까? package.json에는 위에서 설명한 틸드나 캐럿으로 특정 버전이 아닌 버전의 범위를 사용하기 때문이다. 동일한 package.json 파일로 npm install을 실행했지만 패키지의 minor, patch 버전이 배포되면 다른 버전이 설치되는 것이다. 물론 대부분의 경우에는 문제가 없지만 간혹 오류를 일으키는 경우가 있기 때문에 package-lock.json 파일은 의존성 트리에 대한 정확한 정보를 가지고 있다.

## npm ci?

저는 이전까지 주로 기존 프로젝트를 clone받아 package들을 설치할 때 `npm install`을 사용하곤 했다.

새로운 프로젝트를 clone받아 README를 읽다보니 다음과 같이 적혀있었다

![image](https://github.com/prefer2/algorithm/assets/67692759/7239ad01-a285-4530-8ee1-bc43904d32a5)

처음 사용해본 command였다. 내가 알고 있던 ci는 continuous integration의 ci밖에 없어서 찾아보니 여기서 사용되는 ci는 clean install을 뜻한다고 한다.

### npm ci VS npm install

- The project **must** have an existing `package-lock.json` or `npm-shrinkwrap.json`.
- If dependencies in the package lock do not match those in `package.json`, `npm ci` will exit with an error, instead of updating the package lock.
- `npm ci` can only install entire projects at a time: individual dependencies cannot be added with this command.
- If a `node_modules` is already present, it will be automatically removed before `npm ci` begins its install.
- It will never write to `package.json` or any of the package-locks: installs are essentially frozen.

짧게 요약하자면 npm ci는 package-lock을 기반으로 install을 하기 때문에 version range가 아닌 정확하게 동일한 버전을 설치하게 된다. npm ci를 사용하면 node_modules를 삭제하고 새로 설치한다(때문에 clean install이라는 이름을 가지게 된 것 같다)

### when to use npm ci

자동화된 환경인 테스트 플렛폼, CI, 배포를 위해 사용되거나, 혹은 (node_modules 삭제가 필요한)clean install이 필요할 때 사용하면 된다.

이전 프로젝트에서 캐싱이 필요없는 배포마다 파일들을 삭제해주고, npm install을 한 기억이 난다. 앞으로는 캐싱이 필요하지 않는 경우라면 배포 command 작성을 할 때 ci 명령어를 사용해야겠다.

[https://docs.npmjs.com/cli/v7/configuring-npm/package-json](https://docs.npmjs.com/cli/v7/configuring-npm/package-json)

[https://docs.npmjs.com/cli/v9/configuring-npm/npmrc](https://docs.npmjs.com/cli/v9/configuring-npm/npmrc)

[https://docs.npmjs.com/cli/v10/commands/npm-ci](https://docs.npmjs.com/cli/v10/commands/npm-ci)


어쩌면 나 npm 잘 모르고 있었을지도

알아보자 npm


![image](https://github.com/prefer2/prefer2.dev/assets/67692759/21c38633-0333-474e-9280-28983d5f093d)

## ACL, ACG

[https://guide.ncloud-docs.com/docs/vpc-nacl-vpc](https://guide.ncloud-docs.com/docs/vpc-nacl-vpc)

[https://www.ncloud.com/product/security/acg](https://www.ncloud.com/product/security/acg)

ACL: Access Control List

ACG: Access Control Group

NAT(Network Address Translation), pod 등등 네트워크나 인프라 단어들이 쏟아진다. 네트워크 공부 하자…!

---

## Node.js

![Untitled](https://github.com/prefer2/prefer2.dev/assets/67692759/caca259e-c297-4ca9-ab44-82c0b79dd51b)

![Untitled 1](https://github.com/prefer2/prefer2.dev/assets/67692759/48d6b9ae-38a5-4f2d-aa8d-91e6898c23eb)

브라우저와는 약간 달라서 어렵다. worker_thread, cluster 음. 사실 몰라도 프레임워크나 pm2를 사용하는데는 문제는 없을것 같으나 그래도 공부해놓아야지. 이상하게 node 관련해서는 한국어 글들을 찾아보기 어려운 것 같다(내가 구글링을 못하는 걸지도…)

[https://nodesource.com/blog/worker-threads-nodejs](https://nodesource.com/blog/worker-threads-nodejs)

[https://engineering.linecorp.com/ko/blog/pm2-nodejs](https://engineering.linecorp.com/ko/blog/pm2-nodejs)

[https://yceffort.kr/2021/04/nodejs-multithreading-worker-threads](https://yceffort.kr/2021/04/nodejs-multithreading-worker-threads)

---

## node와 typescript

node환경에서 typescript를 사용하기 위해서는 javascript로 컴파일이 필요하다

### ts-node

https://www.npmjs.com/package/ts-node

> It JIT transforms TypeScript into JavaScript, enabling you to directly execute TypeScript on Node.js without precompiling.

주로 nodemon과 함께 local 개발을 할때 쓰이는 듯 하다

### @types/node

> This package contains type definitions for Node.js (http://nodejs.org/).

---

## rollup

[https://rollupjs.org/](https://rollupjs.org/)

[https://so-so.dev/tool/rollup/rollupjs-config/](https://so-so.dev/tool/rollup/rollupjs-config/)

---

## 짧은 회고

회사 컴퓨터에서 보안 문제로 제한이 좀 있다(귀차나) icloud를 쓰던지 하는 방식으로 변경해야 될 것 같다. 요즘 네트워크나 인프라 관련해서 몰라도 너무 모른다는 생각이 든다. 어디서부터 시작을 해야 할지 모를정도로 모르는 단어가 쏟아지는 중이다. 이래서 전공을 열심히 들으라고 했던 거구나...!


공부는 했지만 정리는 하지 않았다

[WIL] 9월 1주차


![image](https://github.com/prefer2/prefer2.dev/assets/67692759/6ff326a7-514c-4f56-bcaa-c7004804f176)


## 무중단 배포

무중단 배포는 말 그대로 서비스가 중단되지 않은 상태로 새로운 버전을 사용자들에게 배포하는 것을 의미한다. 기본적으로 최소 2대의 서버가 필요하다

- 롤링(rolling) 배포
    - 트래픽을 점진적으로 구버전에서 새로운 버전으로 옮기는 방식.
    - 새로운 버전의 인스턴스를 생성하고, 로드밸런서에 이 인스턴스를 연결하고 구버전의 어플리케이션이 실행되는 인스턴스를 하나 줄인다
    - 이전 버전이 사용되는 어플리케이션에 대한 연결을 없애고 새로운 버전으로 교체한 후 다시 연결하는 방식
    - 다양한 오케스트레이션 도구에서 지원한다. 많은 서버 자원을 확보하지 않아도 무중단 배포가 가능하다는 장점이 있다. 점진적으로 새로운 버전이 사용자에게 출시되므로 배포로 인한 위험성이 줄어든다는 장점도 있다
    - 배포 도중 서비스 중인 인스턴스 수가 줄어들게 되어 각각의 서버가 부담하는 트래픽의 양이 늘어날 수 있다. 트래픽을 잘 파악해야 한다. 또 구버전과 신버전이 동시에 서비스되기 때문에 호환성 문제도 발생할 수 있다
- blue/green 배포
    - 트래픽을 한번에 구버전에서 신버전으로 옮기는 방법. 현재 운영중인 서비스의 환경을 Blue라고 부르고, 새롭게 배포할 환경을 Green이라고 한다.
    - 배포 시점에 로드 밸런서가 트래픽을 Blue에서 Green으로 일제히 전환시킨다
    - 한번에 트래픽을 모두 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다
    - 실제 운영에 필요한 서버 리소스 대비 2배의 리소스를 확보해야 한다
- 카나리(canary) 배포
    - 점진적으로 구버전에 대한 트래픽을 신버전으로 옮기는 것은 롤링 배포 방식과 비슷하지만, 새로운 버전에 대한 오류를 조기에 감지하기 위한 방식이다
    - 소수 인원에 대해서만 트래픽을 새로운 버전에 옮긴 상태에서 서비스한다. 새로운 버전에 이상이 없다라고 여겨진 경우에 모든 트래픽을 신버전으로 옮긴다. 이때 새로운 버전으로 옮기는 기준은 랜덤이다.
    - 새로운 버전으로 인한 위험을 최소화 할 수 있지만, 신/구 버전의 애플리케이션이 동시에 존재하므로 호환성 문제가 발생할 수 있다

공부해야하는 내용이라는 조금 다른 방향으로 공부했지만 이번기회에 한 번 정리해봐서 좋다

## npm install VS npm ci

우선 package.json과 package-lock.json의 차이를 알아야한다. package.json에는 version range로 의존성 목록의 버전을 관리한다(eg. “react”: “^17.0.2”) 이러한 version range로 협업하는 사람마다 서로 다른 node_modules를 생성할 수 있다(각자의 로컬 환경마다 npm, node 버전이 다를 수 있기 때문에)

package-lock.json은 package.json과 다르게 정확한 버전이 명시되어 있다. 이때문에 우리는 협업시에 package-lock.json도 형상관리를 해주는 것이다.

### npm ci(clean install)

- 쓰기 권한이 없다
- package-lock.json이 무조건 존재해야만 하고, 없으면 에러를 낸다
- package-lock.json 파일을 기반으로 의존성을 설치하고, package.json은 버전 매칭 벨리데이션 용도로 사용한다
- node_modules를 삭제한 후, 의존성을 한번에 설치한다

https://stackoverflow.com/questions/52499617/what-is-the-difference-between-npm-install-and-npm-ci

초기 install은 `npm c`i를 사용하자…!


## RTK

principle of Redux, which is that, everything that changes in your application, including the data and the UI state, is contained in a single object, we call the state or the state tree.

### configureStore

- option 객체가 named되어 있어 읽기 쉽다
- `applyMiddleware`로 미들웨어들을 배열로 전달
- 자동으로 Redux DevTools 사용

기본적으로 redux-thunk 미들웨어를 가지고 있다. 

```jsx
import { configureStore } from '@reduxjs/toolkit'
import usersReducer from './usersReducer'
import postsReducer from './postsReducer'

const store = configureStore({
  reducer: {
    users: usersReducer,
    posts: postsReducer,
  },
	middleware: ...
	enhancers: ...
})

export default store
```

### createSlice

createSlice는 reducer 함수에 기반해서 action type과 action creator를 자동으로 생성해준다.

```jsx
const postsSlice = createSlice({
  name: 'posts',
  initialState: [],
  reducers: {
    createPost(state, action) {},
    updatePost(state, action) {},
    deletePost(state, action) {},
  },
})

// Extract the action creators object and the reducer
const { actions, reducer } = postsSlice
// Extract and export each action creator by name
export const { createPost, updatePost, deletePost } = actions
// Export the reducer, either as a default or named export
export default reducer
```

- initialState
- name: 생성된 action의 prefix
- reducers
- **extraReducers**

slice의 컨셉! 각 slice reducer가 state의 slice를 가지고 있다는 점. 그리고 많은 slice reducer들이 같은 action type에 독립적으로 응답할 수 있다는 점.

extraReducers

비동기 액션에 대한 리듀서? createAsyncThunk를 통해 생성된 action을 다룰 때 주로 사용

reducer와 extraReducer가 모두 같은 action type에 동작한다면 reducer가 사용됨

builder callback

```jsx
// createReducer에서도 builder function 형식을 따라감
// createReducer는 좀 더 편하게 reducer를 만드는 방식

import { createAction, createReducer } from '@reduxjs/toolkit'

interface CounterState {
  value: number
}

const increment = createAction('counter/increment')
const decrement = createAction('counter/decrement')
const incrementByAmount = createAction<number>('counter/incrementByAmount')

const initialState = { value: 0 } as CounterState

const counterReducer = createReducer(initialState, (builder) => {
  builder
    .addCase(increment, (state, action) => {
      state.value++
    })
    .addCase(decrement, (state, action) => {
      state.value--
    })
    .addCase(incrementByAmount, (state, action) => {
      state.value += action.payload
    })
})
```

builder object

- addCase
- addMatcher
- addDefaultCase

https://redux-toolkit.js.org/api/createReducer#usage-with-the-builder-callback-notation

### createAsyncThunk

```jsx
import { createAsyncThunk, createSlice } from '@reduxjs/toolkit'
import { userAPI } from './userAPI'

// First, create the thunk
const fetchUserById = createAsyncThunk(
  'users/fetchByIdStatus',
  async (userId, thunkAPI) => {
    const response = await userAPI.fetchById(userId)
    return response.data
  }
)

// Then, handle actions in your reducers:
const usersSlice = createSlice({
  name: 'users',
  initialState: { entities: [], loading: 'idle' },
  reducers: {
    // standard reducer logic, with auto-generated action types per reducer
  },
  extraReducers: (builder) => {
    // Add reducers for additional action types here, and handle loading state as needed
    builder.addCase(fetchUserById.fulfilled, (state, action) => {
      // Add user to the state array
      state.entities.push(action.payload)
    })
  },
})

// Later, dispatch the thunk as needed in the app
dispatch(fetchUserById(123))
```

https://redux-toolkit.js.org/api/createAsyncThunk

https://blog.hwahae.co.kr/all/tech/6946


## 짧은 회고

조각조각 공부한 내용들이 아까워서 주간 회고를 하려고 한다. 얼마나 오래 갈지는 모르겠지만 한 번 시작하면 몇주라도 더 열심히 메모할테니까….! 글쓰기 습관을 들이자

공통 기술 교육이 끝나고 이제 진짜 팀 교육이 시작되었다. 지금까지 내가 경험해왔던 프론트엔드에만 집중하는 개발이 아닌 조금 더 큰 그림의 학습을 하고 있어 신기하다. 시야를 넓힐 좋은 기회라 생각한다. 새로운걸 공부해서 그런지 간만에 코딩해서 그런지 재미나다.

연수원도 갔다왔겠다 이제 진짜 공부하자 하핳


[WIL] 8월 4, 5주차


## BFF란?

Backend for Frontend, 말 그대로 프론트엔드를 위한 백엔드 서버를 의미한다. 프론트엔드를 위한 백엔드 서버라… 백엔드 서버는 모두 프론트에서 쓰이기 위해 넘겨지는 것이 아니었던 것일까??(지극히 프론트엔드적 관점이다)

BFF라는 단어를 들어보기는 했지만 회사를 들어오기 전까지는 BFF의 이유와 필요성을 알지 못했다. 프론트에서 필요한 데이터가 있다면 백엔드에게 변경사항을 알려주고 원하는 정보들을 받아왔었다. `이번에 화면 기획이 이렇게 바뀌었고 이런 정보가 필요하니 응답값을 변경해주세요~` 라는 요청을 하고는 했었다. 감사하게도 가공이 필요없는 이쁜 응답을 받도록 변경해주셨고, 프론트엔드는 정보를 받아 상태를 관리하고 화면에 뿌려주었다.

이게 가능했던 이유는 백엔트 팀과 프론트엔드 팀이 1:1로 작업을 하기 때문이었다. 서비스가 작으면 작을수록 서버와 클라이언트가 1:1 관계를 가지게 된다. 해당 API는 나만, 그 페이지만, 그 컴포넌트만 호출하기 때문에 서버가 클라이언트 맞춤형 응답을 내려줘도 괜찮다.

하지만 프로젝트가 점차 커진다면?!?!

![Untitled](https://github.com/prefer2/prefer2.dev/assets/67692759/0cc4d96d-5199-4cef-b9f4-3b7c93f2596e)

위의 e-commerce 예시처럼 회원, 주문, 장바구니, 상품 등 도메인 단위로 코드를 관리해야할 필요성이 생긴다. 각 도메인별로 나누어 독립적인 서비스로 만들수 있고 유지 관리하기 쉬워진다. 최근 이런 독립적이고 작은 서비스로 나누는 형식을 `Micro Service Architecture(MSA)`라고 칭한다.

실제로 회사의 백엔드 팀들이 MSA 형식으로 나뉘어져 있는지는 잘 모르겠다. 매우 큰 규모의, 역사가 있는 서비스의 회사이기 때문에 각 도메인별로 작게 나뉘어져 있고, 각 팀에서는 방대한 양의 데이터를 관리한다. 내가 속한 팀의 서비스는 굉장히 많은 도메인에 다양한 요청을 보내 응답을 받아 화면에 보여주어야 한다.

## Why BFF

서버를 구성하여 추가적인 게이트웨이를 만드는 것은 꽤나 공수가 많이 든다. 나뉘어져 있는 서버의 정보들을 원하는 값들을 모으는 것 말고도 BFF에는 많은 장점이 있다.

결제 시스템에서 사용하는 주문서를 예시로 들어보자. 주문서에는 주문자의 이름, 주소, 핸드폰 번호같은 개인 정보부터 주문 상품 정보, 회원 별 포인트, 사용자별 광고 등 하나의 페이지지만 다양한 정보들이 필요하다. 다양한 정보를 보여줘야 할 뿐만 아니라 해당 페이지에서 다루는 정보들은 개인 정보와 관련된 값들이 대부분이라 보안적으로 매우 중요하다.

우선 해당 페이지에서 보여줘야 하는 값들은 컴포넌트별로 요청을 보내 보여주는 것에 의미가 없다. 결제 시스템이다보니 하나의 요청에 대한 값이라도 실패하면 해당 페이지를 보여주지 않는 것이 의미있다. 또한 회원정보를 기반으로 해당 회원이 소지한 포인트, 카드정보 등을 가져와야하기 때문에 api 요청에 순서도 존재한다. 

카드 정보 요청, 포인트 요청 등과 같은 개인정보와 매우 밀접하고 보안적으로 중요한 정보들은 요청조차도 최대한 숨기는게 좋다. 네트워크 탭을 통해 어떤 요청을 보내고 있는지 알 수 있다면 해당 요청의 값을 바꿔가며 다른 사람의 소중한 정보들을 훔쳐볼 수 있게된다.

![image](https://github.com/prefer2/prefer2.dev/assets/67692759/6fda5403-5442-487b-bf74-da97bf12f55b)
_호기심이 많은 우리 개발자들은 네트워크 탭을 열어 어떤 요청들을 보내나 구경하고는 한다_

BFF라는 한단계를 추가하게 되면 클라이언트 단에서는 페이지 전체에 대한 요청 하나만을 BFF에게 요청하게 되고, 네트워크 탭에서는 해당 요청만을 확인할 수 있게 된다. 일종의 은닉화가 되는 것이다.

마지막으로 CORS 이슈를 다루기가 쉬워진다. 서버에서 바라보는 end-point는 BFF 서버 하나가 된다. 다양한 페이지에서 서버값을 사용한다면 CORS 이슈를 해결하기 위해서 이에 대한 소통을 자주 해야 한다. BFF쪽에 대한 정보만을 서버에게 알려주면 되기 때문에 해당 이슈를 해결하기 쉬워진다. 프론트의 변경사항은 BFF에서 프론트 개발자가 그때그때 해결하면 된다.


## 참고자료

[카카오페이지는 BFF(Backend For Frontend)를 어떻게 적용했을까?](https://fe-developers.kakaoent.com/2022/220310-kakaopage-bff/)

[BFF - Backend for Frontend Design Pattern with Next.js](https://dev.to/adelhamad/bff-backend-for-frontend-design-pattern-with-nextjs-3od0)

[BFF?](https://github.com/sbyeol3/articles/issues/42)


백엔드를 위한 강의인 것 같지만 왜 microservice가 필요한지 재미나게 알려주시는 강의

[[우아콘2020] 배달의민족 마이크로서비스 여행기](https://www.youtube.com/watch?v=BnS6343GTkY)

나만을 위한 서버라구...? 감동....

알아보자 BFF


![Untitled](https://user-images.githubusercontent.com/67692759/236611257-bcb158e6-26aa-42d7-8cba-00b95baba711.png)

### atom

상태(state)의 일부. atom값을 읽는 컴포넌트들은 암묵적으로 atom을 구독한다.

### selector

파생된 state를 저장함. 파생된 상태는 상태의 **변화**다.

가장 큰 특징은 멱등성. 순수함수이다.

때문에 selector를 비동기 함수로 사용하는 것

### snapshot

atom 상태 읽기 전용. snapshot은 계속 변하는 상태의 ‘한 순간’이다. snapshot은 상태가 변할 때마다 생성된다.

### useReacoilCallback

[https://recoiljs.org/docs/api-reference/core/useRecoilCallback/](https://recoiljs.org/docs/api-reference/core/useRecoilCallback/)

useCallback과 비슷하지만, Recoil 상태(state)에서 callback이 동작하도록 API를 제공한다.

- 비동기적으로 Recoil 상태를 업데이트 할때
- Recoil 상태의 snapshot에 접근할 수 있는 callback을 만들기 위해

### useCallback과는 어떤 차이?

```tsx
const log1 = useCallback(() => {
  console.log("called with ", "nothing");
});
const log2 = useRecoilCallback(({ snapshot }) => () => {
  console.log("called with ", snapshot);
});
```

useRecoilCallback에서 첫번째 인수는 스냅샷 관련 기능을 전달하기 위해 한 번 더 감싸진 ‘실행할 함수를 만드는 함수’를 사용한다. 여기서 생성된 함수의 인수로 전달되는 객체에는 gotoSnapshot 함수, set 함수, reset 함수가 포함되어 있다.

### atomFamily

[https://recoiljs.org/docs/api-reference/utils/atomFamily/](https://recoiljs.org/docs/api-reference/utils/atomFamily/)

우선 family란 비슷한 기능을 하는 별개의 atom이 필요한 경우 필요한 만큼 각각 선언하는 대신 하나의 형태를 선언해 놓고 팩토리처럼 언제든 새롭게 만들어 사용할 수 있는 기능.

But, what if your state isn’t global? What if your state is associated with a particular instance of a control, or with a particular element?

An Atom Family represents a collection of atoms. When you call `atomFamily()`
 it will return a function which provides the `RecoilState` atom based on the parameters you pass in.

대분류를 만들고 그 안의 소분류들을 사용하고 싶을때 쓰는느낌. family라는 말 그대로 하나로 묶이는 그룹을 만들어서 사용하기.

### selectorFamily

파생 상태를 id별로 다르게 하는 방식

allows you to pass parameters to the `get` and `set` callbacks of a `selector`

매개변수가 있는 쿼리를 실행할 때 사용한다. props를 기반으로 쿼리를 실행하고 싶을 때

굳이 저장하지 않아도 되는 상태값에 따라서 다른 쿼리 결과를 내고 싶을 때 사용


Recoil 맛보기


## flex

flex는 `flex-grow`, `flex-shrink`, `flex-basis`의 줄임 표현

꼭 필요한 경우가 아니라면 이를 따로 쓰는 것보다 flex로 줄여쓰는 것이 코드도 적고 알아보기 좋다.

shorthand correctly resets any unspecified components to accommodate [common uses](https://drafts.csswg.org/css-flexbox/#flex-common).

줄임 표현을 쓸 때 예상과 다를 수 있다. 이를 고려해서 줄임표현을 잘 사용해야 한다. flex: 숫자의 flex-basis값은 auto가 아니라 0이다.

[https://drafts.csswg.org/css-flexbox/#flex-common](https://drafts.csswg.org/css-flexbox/#flex-common)

### flex-grow

공간이 넘칠 때 어떻게 비율을 가져갈 것인지

`flex-item` 요소가, `flex-container` 요소 내부에서 할당 가능한 공간의 정도를 선언한다.

보통 flex-shrink, flex-basis 속성을 함께 사용한다. 일반적으로 모든 값이 설정되었음을 보장하기 위해 flex 속성을 이용해 축약형으로 사용한다. 기본값은 0이다.

### flex-shrink

공간이 부족할 때 어떻게 비율을 가져갈 것인지

`flex-item` 요소의 크기가 `flex-container` 요소의 크기보다 클 때 flex-shrink 속성을 사용하는데, 설정된 숫자값에 따라 `flex-container` 요소 내부에서 `flex-item` 요소의 크기가 **축소**된다.

### flex-basis

초기 값 설정. 이 기본값으로부터 grow, shrink하는 것

[https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Controlling_Ratios_of_Flex_Items_Along_the_Main_Ax](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Controlling_Ratios_of_Flex_Items_Along_the_Main_Ax)

[https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Mastering_Wrapping_of_Flex_Items](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Mastering_Wrapping_of_Flex_Items)

🐸 flex를 연습할 수 있는 귀여운 사이트

[https://github.com/thomaspark/flexboxfroggy/](https://github.com/thomaspark/flexboxfroggy/)

---

## overflow

요소의 콘텐츠가 너무 커서 요소의 블록 서식 맥락에 맞출 수 없을 때의 처리법을 지정

넘치는 요소를 잘라내기, 스크롤바로 보여주기, 그대로 노출 옵션이 있다.

overflow가 효력을 가지기 위해서는 반드시 height를 설정하거나, white-space를 nowrap으로 설정해야 한다.

This property specifies whether to clip content or to add scrollbars when an element's content is too big to fit in a specified area.

overflow의 첫번째 값은 overflow-x, 두번째 값은 overflow-y다. 축약해서 표현도 가능하다.

기본 값은 visible

### options

- visible: 콘텐츠를 자르지 않으며 안쪽 여백 상자 밖에도 그릴 수 있다
- hidden: 넘친 곳을 잘라낸다
- scroll: 잘라내고 넘치는 부분을 스크롤바로 확인 가능하다
- auto: 사용자 에이전트(브라우저)가 결정

---

## 어떻게 레이아웃을 잡을까

반응형으로 잘 대응하기 위해서는 크기를 지정하는 것이 아니라 flex로 잡아두는 것이 편하다

고정 위치와 스크롤 될 부분을 분리하여 영역을 잡는다

flex로 위치를 잡고, 넘칠 것을 overflow로 조절해주기

때로는 그냥 absolute로 위치를 잡는 것이 편할지두


그 어떤 레이아웃이라도 잘 잡을 수 있어...!

flex & overflow로 레이아웃 잡기


![http 완벽 가이드 표지](https://user-images.githubusercontent.com/67692759/211473613-0531c7c1-578d-4c68-993a-138e17e7ce3e.png)

HTTP 완벽 가이드의 `2. HTTP 아키텍처`를 읽고 정리한 내용입니다.

---

# 7장: 캐시

웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다. 웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면, 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다. 캐시는 다음과 같은 혜택을 준다

- 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다
- 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러올 수 있게 해준다
- 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다
- 페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다

## 적중과 부적중

캐시에 요청이 도착했을 때, 만약 대응하는 사본이 있다면 이를 사용해 요청이 처리된다. 이를 `캐시 적중(cache hit)`이라고 부른다. 대응하는 사본이 없다면 원 서버로 요청이 전달된다. 이를 `캐시 부적중(cache miss)`라고 부른다.

### 재검사(revalidation)

사본이 최신인지 서버를 통해 점검해야 하는데 이러한 신선도 검사를 HTTP 재검사라고 부른다. 캐시는 원한다면 스스로 사본을 재검사 할 수 있다. 대부분의 캐시는 클라이언트가 사본을 요청하였으며 그 사본이 검사를 할 필요가 있을 정도로 충분히 오래된 경우에만 재검사를 한다.

콘텐츠가 변경되지 않았다면, 서버는 `304 Not Modified` 응답을 보낸다. 캐시는 사본이 신선하다고 임시로 다시 표시한 뒤 그 사본을 클라이언트에 제공한다. 이를 재검사 적중 혹은 느린 정중이라고 부른다. 이는 원 서버와 검사가 필요하기 때문에 순수 캐시 적중보다는 느리고, 서버로부터 객체 데이터를 받아올 필요가 없기 때문에 캐시 부적중보다는 빠르다.

HTTP는 캐시된 객체를 재확인하기 위해 If-Modified-Since 헤더를 자주 사용한다. 이는 캐시된 시간 이후에 변경된 경우에만 사본을 보내달라는 의미이다.

- 재검사 부적중: 서버 객체가 캐시된 사본과 다르다면, 서버는 컨텐츠 전체와 함께 HTTP 200 OK 응답을 클라이언트에게 보낸다.
- 객체 삭제: 만약 서버 객체가 삭제되었다면, 서버는 404 Not Found 응답을 돌려보내며, 캐시는 사본을 삭제한다.

### 적중률

캐시가 요청을 처리하는 비율을 캐시 적중률 또는 문서 적중률이라고 부른다. 적중률 40%면 웹 캐시로 괜찮은 편이다.

바이트 단위 적중률은 캐시를 통해 제공된 모든 바이트의 비율을 표현한다.

문서 적중률을 개선하면 전체 대기 시간이 줄어들고, 바이트 단위 적중률의 개선은 대역폭 절약을 최적화한다.

클라이언트가 응답이 캐시에서 왔는지 알아내는 방법은 Date 헤더를 이용하는 것이다. 응답의 생성일이 현재 시각보다 오래되었다면 클라이언트는 응답이 캐시된 것임을 알 수 있다. 다른 방법은 응답이 얼마나 오래되었는지를 말해주는 Age 헤더를 사용하는 것이다.

## 캐시 토폴로지

한 명에게만 할당된 캐시를 개인 전용 캐시(private cache), 공유된 캐시를 공용 캐시(public cache)라고 부른다. 웹 브라우저는 개인 전용 캐시를 내장하고 있다. 공용 캐시는 프락시 캐시로, 로컬 캐시에서 문서를 제공하거나, 사용자 입장에서 서버에 접근한다. 공용 캐시는 불필요한 트래픽을 줄일 수 있는 기회가 많다.

## 캐시 처리 단계

1. 요청 받기
2. 파싱: 메시지를 파싱하여 URL과 헤더를 추출한다
3. 검색: 로컬 복사본이 있는지 검사하고, 사본이 없다면 사본을 받아와 로컬에 저장한다
4. 신선도 검사: 사본이 충분히 신선한지 검사하고, 신선하지 않다면 변경사항이 있는지 서버에게 물어본다
5. 응답 생성: 새로운 헤더와 캐시된 본문으로 응답 메시지를 만든다
6. 발송: 네트워크를 통해 응답을 클라이언트에게 돌려준다
7. 로깅: 선택적으로 캐시는 트랜잭션에 대해 서술한 로그를 남긴다

## 사본을 신선하게 유지하기

HTTP는 `Cache-Control`과 `Expries`라는 특별한 헤더들을 이용해 원 서버가 각 문서에 유효기간을 붙일 수 있게 해준다.

캐시는 필요하다면 서버와의 접촉 없이 사본을 제공할 수 있다. 캐시 문서가 만료되면, 캐시는 반드시 서버와 문서에 변경된 것이 있는지 검사해야 하며, 만약 변경이 있다면 신선한 사본을 새 유효기간과 함께 얻어 와야 한다.

캐시된 문서가 만료되었다는 것은, 그 문서가 원 서버에 존재하는 것과 실제로 다르다는 것을 의미하지는 않으며, 이제 검사할 시간이 되었음을 뜻한다. 캐시는 문서의 신선도를 매 요청마다 검증할 필요 없이 문서가 만료되었을 때 한 번만 서버와 재검사하면 된다.

### 조건부 메서드와 재검사

조건부 메서드는 재검사를 효율적으로 만들어준다. `If-Modified-Since`와 `If-None-Match`가 있다.

- If-Modified-Since: <date> : 만약 문서가 주어진 날짜 이후로 수정되었다면 요청 메서드를 처리한다.만약 변경되지 않았다면 304 Not Modified 응답 메시지를 클라이언트에게 돌려준다.
- If-None-Match: <tags> : 캐시된 태그가 서버에 있는 문서의 태그와 다를 때만 요청을 처리한다.

## 캐시 제어(Cache-Control)

HTTP 문서가 만료되기 전까지 얼마나 오랫동안 캐시될 수 있게 할 것인지 서버가 설정할 수 있는 방법.

- no-store: 캐시가 그 응답의 사본을 만드는 것을 금지한다.
- no-cache: 로컬 캐시 저장소에 저장된다. 다만 먼저 서버와 재검사를 하지 않고서는 캐시에서 클라이언트로 제공될 수 없다.
- max-age: 신선하다고 간주되었던 문서가 서버로부터 온 이후로 흐른 시간을 명시한다. s-maxage는 공용 캐시에만 적용 가능하다
- expires: 실제 만료 날짜를 명시한다.
- must-revalidate: 캐시가 만료 정보를 엄격하게 따르길 원할 때. 캐시가 이 객체의 신선하지 않은 사본을 원 서버와의 최초의 검사 없이는 제공해서는 안됨을 의미한다. must-revalidate로 신선도 검사를 했을 때 원 서버를 사용할 수 없다면 504 Gateway Timeout error를 반환한다.

### 휴리스틱 만료

만약 응답이 Cache-Control: max-age헤더나 Expires 헤더 중 어느 것도 포함하지 않고 있다면, 캐시는 경험적인 방법으로(heuristic) max age를 계산한다.

---

# 8장: 통합점: 게이트웨이, 터널, 릴레이

## 게이트웨이

게이트웨이는 리소스와 애플리케이션을 연결하는 역할을 한다.게이트웨이는 요청을 받고 응답을 보내는 포털같이 동작하는데, 동적인 콘텐츠를 생성하거나 데이터베이스에 질의를 보낼 수 있다.

웹 게이트웨이는 클라이언트 측 프로토콜과 서버 측 프로토콜을 / 으로 구별하여 기술한다.

### 프로토콜 게이트웨이

![Untitled](https://github.com/prefer2/algorithm/assets/67692759/95db67cd-c2e5-4423-aa28-bd057b6db3b1)

- HTTP/\*: 서버 측 웹 게이트웨이. 게이트웨이는 응답을 HTTP 응답에 실어서 클라이언트에 전송한다
- HTTP/HTTPS: 서버 측 보안 게이트웨이. 기업 내부의 요청을 암호화하여 개인 정보와 보안을 제공. 사용자의 모든 세션을 암호화함
- HTTPS/HTTP: 클라이언트 측 보안 가속 게이트웨이. 보안 HTTPS 트래픽을 받아서 복호화하고, 웹 서버로 보낼 일반 HTTP 요청을 만든다.

### 리소스 게이트웨이

게이트웨이의 가장 일반적인 형태인 애플리케이션 서버는 목적지 서버와 게이트웨이를 한 개의 서버로 결합한다.애플리케이션 게이트웨이에서 유명했던 최초의 API는 공용 게이트웨이 인터페이스(CGI)였다. CGI가 내부에서 어떤 처리를 하는지는 사용자에게 보이지 않는다.

![Untitled 1](https://github.com/prefer2/algorithm/assets/67692759/ba3dc177-c49e-4153-8db1-28b4c31a4ed6)

## 터널

웹 터널은 HTTP 프로토콜을 지원하지 않는 애플리케이션에 HTTP 애플리케이션을 사용해 접근하는 방법을 제공한다. HTTP 커넥션 안에 HTTP가 아닌 트래픽을 얹어, 웹 트래픽만을 허락하는 방화벽이 있더라도 HTTP가 아닌 트래픽을 전송할 수 있다.

![Untitled 2](https://github.com/prefer2/algorithm/assets/67692759/2f9ca6e3-6020-4622-a282-cce9cafff3cd)

### SSL 터널링

웹 터널은 원래 방화벽을 통해서 암호화된 SSL 트래픽을 전달하려고 개발되었다. 터널을 사용하면 SSL 트래픽을 HTTP 커넥션으로 전송하여 80 포트의 HTTP만을 허용하는 방화벽을 통과시킬 수 있다.


다람쥐 책을 읽자 2. HTTP 아키텍처

HTTP 완벽 가이드(2)


## You Don’t Need Next.js (and SSR)

[You Don’t Need Next.js (and SSR). Next is an amazing framework but there… | by Harshal Patil | webf](https://blog.webf.zone/you-dont-need-next-js-and-ssr-7c6bd27e78d8)

자극적인 제목과 강려크한 내용.

---

## css

### typewind

[GitHub - ben-rogerson/twin.macro: 🦹‍♂️ Twin blends the magic of Tailwind with the flexibility of css-in-js (emotion, styled-components, stitches and goober) at build time.](https://github.com/ben-rogerson/twin.macro)

오 신기해. tailwind에 타입 시스템을 적용하는 방식. 신박하다.
[Typewind – Typesafe Tailwind](https://typewind.vercel.app/)

---

## 타입스크립트로 에러 처리하기

[번역 타입스크립트에서 전문가처럼 에러 처리하기. 원문… | by Jisu Yuk | Feb, 2023 | Medium](https://medium.com/@yujso66/%EB%B2%88%EC%97%AD-%ED%83%80%EC%9E%85%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8%EC%97%90%EC%84%9C-%EC%A0%84%EB%AC%B8%EA%B0%80%EC%B2%98%EB%9F%BC-%EC%97%90%EB%9F%AC-%EC%B2%98%EB%A6%AC%ED%95%98%EA%B8%B0-39d14f5cc6a2)
언제나 에러 처리는 어렵다. 특히 타입스크립트에서의 에러 처리는 조심해야 할 점들이 많다. 에러를 받아서 자연스럽게 error.message같은 값들을 사용하게 되지만, 타입스크립트에서 error 객체는 unknown타입이기 때문에 적절한 타이핑이 필요하다. 타입스크립트가 알아먹을 수 있는 에러를 정의하여 사용하고, 적절한 타입을 선언하여 중복을 피하자.

---

## 성능 성능

[DogGae](https://codingmoondoll.tistory.com/)

### 이미지

![can i use webp](https://user-images.githubusercontent.com/67692759/221886429-412253d7-0cbc-4ecf-8111-9eb01f6a23e2.png)

[YouTube](https://www.youtube.com/watch?v=Z_28syzkv-0)
[(번역) HTML 이미지 최적화](https://velog.io/@lky5697/fast-images)

fetchPriority: 이미지 fetch 속성을 경정할 수 있음 [HTMLImageElement.fetchPriority - Web APIs | MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/fetchPriority)
[Optimizing resource loading with Priority Hints](https://web.dev/priority-hints/)

Next.js의 Image는 어떤식으로 최적화를 진행했을까?

### 웹폰트

[YouTube](https://www.youtube.com/watch?v=4YCBBoSg2fk)

### 브라우저 렌더링 최적화

[YouTube](https://www.youtube.com/watch?v=yJo9lZAEqb0&list=PLAwxTw4SYaPl09X4Rljhy7dZinRCzbHz6)

[CSS GPU Animation: Doing It Right — Smashing Magazine](https://www.smashingmagazine.com/2016/12/gpu-animation-doing-it-right/)
[(번역) 빠른 페이지 로드를 위한 자바스크립트 최적화의 궁극적인 가이드](https://velog.io/@sehyunny/js-optimization-for-quick-page-load)

---

## custom hook in react

[YouTube](https://www.youtube.com/watch?v=J-g9ZJha8FE)

프론트엔드에서의 패턴. 어떻게 컴포넌트를 나누고 훅 분리를 할 것인지.
Layer를 나눠야 하는 이유

- 관심사 분리
- 코드의 중복 제거
- 테스트에 용이
  [번역 잘 알려진 UI 패턴을 사용하여 리액트 애플리케이션 모듈화하기](https://velog.io/@eunbinn/modularizing-react-apps)
  [PresentationDomainDataLayering](https://martinfowler.com/bliki/PresentationDomainDataLayering.html)

![refactoring adding function](https://user-images.githubusercontent.com/67692759/221886686-2871b200-c040-451d-9f2c-d69c4ace4483.png)

---

## preload, prefetch, preconnect

- link tag
  - preload: 현재 화면에 필요한 리소스=
  - prefetch: 현재 화면에 필요한 것❌, 이후 페이지에 필요한 리소스
  - preconnect: 같은 도메인에 여러개의 리소스를 요청할 때

[되돌아보는 index.html - Part 1 | SOSOLOG](https://so-so.dev/web/index-html-1/)

---

## 모듈 번들러

vite에 대해서 알아봐야 할지두?
[(번역) 이제는 웹팩과 작별할 때일까?](https://velog.io/@sehyunny/is-it-time-to-say-goodbye-to-webpack)

---

## SSR

react로 ssr
[How to Enable Server-Side Rendering for a React App | DigitalOcean](https://www.digitalocean.com/community/tutorials/react-server-side-rendering)
[React로 Next.js 처럼 Server-side-rendering 구현하기 | by DylanJu | Medium](https://minoo.medium.com/next-js-%EC%B2%98%EB%9F%BC-server-side-rendering-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0-7608e82a0ab1)
프레임워크 없이 만드는 SSR
[프레임워크 없이 만드는 SSR | 개발자 황준일](https://junilhwang.github.io/TIL/Javascript/Design/Vanilla-JS-Server-Side-Rendering/)

---

## 짧은 회고

2월이 어떻게 지나갔는지 모르겠다. 어버버하고 지내다 보니 2월이 끝난 기분이다. 거의 매일 코딩테스트나 면접을 보느라 개인 공부를 못했다. 그래도 면접 질문 답변을 정리하다보니 관련 내용들은 스스로 정리가 된 기분이다 (근데 면접에서는 안물어봐줌ㅠ) 코테 연습은 어려운 문제를 잘 푸는 것도 중요하지만 쉬운 문제를 빠르고 정확하게 푸는 연습을 더 해야할 것 같다.


이월은 이런 것들을 봤구나 2열~

2월의 조각 모음


## 태그별 모아보기

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2023-02-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_4 59 26](https://user-images.githubusercontent.com/67692759/218408045-87a82f59-184c-4026-b502-ab29f5a53e2f.png)

![%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2023-02-13_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_4 59 40](https://user-images.githubusercontent.com/67692759/218408147-c00a8fae-5d47-4c2d-b4a5-2f0f0be1c728.png)

글에 작성했던 tag별로 모아볼 수 있는 페이지를 구현하였다. 태그별 모아보기, 시간 순으로 모아보기를 구현하고 싶었기 때문에 archives페이지에서 전체 글을 가져와 태그별, 날짜별로 정렬해주었다.

태그별 모아보기 페이지는 포스트 페이지와 동일하게 동적 라우팅으로 구현하였다. 이제 어떤 곳에서든 태그를 누르면 해당 태그 모아보기 페이지로 이동한다.

---

## sitemap & RSS

사실 크기가 작은 사이트에는 sitemap이 불필요하다. 하지만 나의 블로그는 앞으로 매우 커질 것이기 때문에 sitemap을 추가했다. 빌드시마다 sitemap과 robot.txt를 빠르게 생성해주는 [next-sitemap](https://www.npmjs.com/package/next-sitemap)을 사용하여 추가했다.

대부분의 블로그에는 구독 기능인 RSS(Really Simple Syndication)가 있다. 또한 구글의 search console에서 sitemap과 함께 rss를 제출하기를 권장하고 있다(이는 크롤링에 도움이 된다고 한다) RSS를 쉽게 생성해주는 패키지가 있어 이를 사용하여 추가해주었다. 관련 설정은 아래 글을 참고했다.

[https://j471n.in/blogs/rss-feed-for-nextjs](https://j471n.in/blogs/rss-feed-for-nextjs)

---

## 이것저것 추가

날짜 포맷팅을 이쁘게 해주기 위해서 date-fns를 추가했다.

framer-motion 맛보기. 아직은 메인 페이지에서 글을 가져올 때만 애니메이션을 넣어주었는데 조금 더 공부해서 다양한 곳에 애니메이션을 추가해보고 싶다.

네이버 서치 콘솔에 등록했다. 이제 네이버에 검색해도 내 블로그가 보인다 크크(그나저나 구글은 왜 이리 오래걸리는지 모르겠다. 어여 등록해주라우)

![네이버 검색](https://user-images.githubusercontent.com/67692759/218408281-54d491c6-fff7-44a4-bdca-239f8ef22c32.png)

### +) 구글 등록 완료

![구글 서치 콘솔 등록](https://user-images.githubusercontent.com/67692759/220804499-8ebf8dcf-c484-4b46-9932-9816a7e72741.png)

![image](https://user-images.githubusercontent.com/67692759/220804770-c90ba60a-2636-480e-b3c1-c9ec898bcdf9.png)

구글 서치 콘솔에도 등록이 되었다는 메일이 왔다. 등록까지는 약 1달 반 정도가 걸렸다.

---

## 수정해야 할 사항

글 제목으로 검색 했을 시 글 제목과 설명이 아닌 메인 페이지가 나오고 있는데 내가 SEO 관련 설정을 잘못한 것인지 아니면 아직 반영이 안된 것인지는 조금 더 알아봐야겠다.

![네이버 검색 by 제목](https://user-images.githubusercontent.com/67692759/218408287-6b02f12c-0bc5-4578-868b-89263f69919e.png)

media-zoom 얹어서 사진 확대하기 기능을 추가하려고 하니 아래와 같은 오류가 생기고 있다. 뭔가 mount 되기 전에 utterance를 얹을려고 해서 그런 것 같은데 흠.

![스크린샷 2023-02-14 오후 5.01.17.png](https://user-images.githubusercontent.com/67692759/218753955-e2c41da5-423f-4570-9532-8b9f1d6f045e.png)


블로그 발전기 - 2편


이것저것 읽고 여기저기 적어놓기만 해서 아쉬웠던 학습 기록들을 모아볼려고 한다. 어디에라도 올린다고 생각하고 작성하다보면 정리도 더 잘하지 않을까 싶다. 1월은 얼마 못 모았지만 2월은 더 열심히 모아보도록 하자! 모아놓으면 나중에 또 볼 수도 있고 좋겠지?

---

## webpack prefetch preload

Webpack 4.6부터는 prefetch와 preload가 지원된다.
동적 import문의 경로 앞에 `/* webpackPrefetch: true */`를 추가하면 된다.
HomePage 컴포넌트에서 LoginButton 컴포넌트를 렌더링하고, 이 컴포넌트를 클릭하면 LoginModal 컴포넌트를 요청하여 로드하는 경우

```
import (/* webpackPrefetch: true */ './path/to/LoginModal.js')
```

### 언제 preload, 언제 prefetch

- preload: 현재 페이지에서 무조건 사용되는 리소스일때. Web font, hero image 등
- prefetch: navigate를 하다보면 나중에 언젠가 쓰일 리소스

둘 다 HTTP 캐시에 저장된다.
크롬 네트워크에서 Priority 행을 추가하여 우선순위가 어떻게 되는지를 확인할 수 있다.

### preload, prefetch 관련 좋은 글

[Preload, Prefetch And Priorities in Chrome | by Addy Osmani | reloading | Medium](https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf)

---

## 성능 면에서 SSR, CSR

![image-7](https://user-images.githubusercontent.com/67692759/216808691-7f4a6796-a9e9-4546-96d9-8f24100c17e1.png)

---

## 성능 측정하는 도구들

Dev

- lighthouse
- webpageTest -> 다양한 환경에서 성능을 측정할 수 있음

Field(실제 사용자 모니터링)

- Google Analytics
- Web vitals

### web vitals

실제 유저들이 사용하는 성능을 측정하는?

[web vitals github](https://github.com/GoogleChrome/web-vitals)

[web.dev web vitals](https://web.dev/vitals/)

[Measuring Performance | Create React App](https://create-react-app.dev/docs/measuring-performance/)

---

## useState, useReducer

[번역 useState 지옥에서 벗어나기](https://velog.io/@eunbinn/a-cure-for-react-useState-hell)
이 글을 읽으며 어떻게하면 useReducer를 잘 쓸지 생각해보았다. 최근에는 useReducer를 사용한 경험이 많이 없는 것 같다(redux스럽다고 생각해서인지… useCallback, useMemo쓰기 싫어서인지… 세트로 돌아가는 상태를 다루지 않아서인지…) 글 중간에 React 공식 문서에서 알려주는 useReducer 예시가 나오는데 오호 싶다.
[Hooks FAQ – React](https://reactjs.org/docs/hooks-faq.html#how-to-avoid-passing-callbacks-down)

### 상태 관리

Kent 형님의 context 관련 영상. 다시보니 또 새롭네. Back to basic!
[YouTube](https://www.youtube.com/watch?v=zpUMRsAO6-Y)

이 책을 읽어보고 싶으다. 한글 번역이 없어서 큰맘먹고 사야한다. [Micro State Management with React Hooks | Kato, Daishi - 교보문고](https://product.kyobobook.co.kr/detail/S000061587593)

---

## Korean FE Article Team

여러 프론트엔드 글들을 번역하는 팀이다. 메일로 구독해서 보고있는중. 좋은 글들을 잘 뽑아서 번역도 깔끔하게 해서 올려준다. 올라오는 주기도 짧은듯? 나도 나중에 기회가 되면 참여해보고 싶다.

[Korean FE Article Team](https://kofearticle.substack.com/)


1월의 기록들을 모아봤어, 연진아

1월의 조각 모음


> tkdodo의 블로그 글 [Inside React Query](https://tkdodo.eu/blog/inside-react-query)를 번역한 글입니다.

최근 React Query가 내부적으로 어떻게 동작하는지 질문을 많이 받았다. 언제 re-render해야하는지 어떻게 아는 건가요? 어떻게 중복을 제거하는 건가요? 어떻게 프레임워크에 구애받지 않는 건가요?

좋은 질문들이다. 우리가 사랑하는 비동기 상태 관리 라이브러리의 내부에 대해 알아보고 `useQuery`를 실행할 때 어떤 일이 실제로 일어나는지 분석해보자.

## QueryClient

![queryClient.png](https://tkdodo.eu/blog/static/e514494caad7fe0d01955461672a6808/d0a5a/queryClient.png)

모든 것은 `QueryClient`로부터 시작한다. 어플리케이션을 시작할때 만들고 `QueryClientProvider`를 통해 어디서나 사용 가능하다.

```js
import { QueryClient, QueryClientProvider } from "@tanstack/react-query";

// ⬇️ this creates the client
const queryClient = new QueryClient();

function App() {
  return (
    // ⬇️ this distributes the client
    <QueryClientProvider client={queryClient}>
      <RestOfYourApp />
    </QueryClientProvider>
  );
}
```

`QueryClientProvider`는 React Context를 사용하여 `QueryClient`를 전체 어플리케이션에 분배한다. client 자체는 안정적인 값이다. 한 번만 생성됨으로(무심코 너무 자주 재성성되지 않도록 조심하자) Context를 사용하기 완벽한 곳이다.

QueryClientProvider는 앱을 re-render하지 않고, `useQueryClient`를 통해 client에 접근할 수 있도록 해준다.

### 캐시를 담는 그릇

잘 알려지지 않았을 수 있지만, `QueryClient `자체는 많은 일을 하지 않는다. `New QueryClient`를 만들면 자동으로 생성되는 `QueryCache`와 `MutationCache`의 컨테이너이다.

또한 모든 query 및 mutation에 대해 설정할 수 있는 몇 가지 기본값을 가지고 있으며 캐시 작업을 위한 편리한 method를 제공한다. 우리는 대부분의 경우 캐시와 직접 상호작용하지 않고 QueryClient를 통해 캐시에 접근한다.

## QueryCache

좋다, client가 캐시를 사용할 수 있게 해주었다. 그럼 캐시가 무엇인가?
![queryCache.png](https://tkdodo.eu/blog/static/9d5efa2aaebfecdf87f37209cda9268c/88b03/queryCache.png)

간단히 말해서 `QueryCache`는 키가 안정적이게 직렬화된 queryKeys의 버전(queryKeyHash라고 한다)이고, 값이 `Query` 클래스의 인스턴스인 in-memory object이다.

React Query는 기본적으로 in-memory에만 데이터를 저장하고 다른 곳에는 저장하지 않는다는 것을 이해하는 것이 중요하다고 생각한다. 브라우저 페이지를 새로고침하면 캐시는 사라진다. localstorage와 같은 외부 저장소에 캐시를 쓰려면 [persisters](https://tanstack.com/query/v4/docs/plugins/persistQueryClient) 를 봐라.

## Query

![query.png](https://tkdodo.eu/blog/static/eccccf6c9a523fa4e407b873c8ac273f/88b03/query.png)

캐시에는 쿼리들이 있으며, `Query`에서 대부분의 로직이 실행된다. 여기에는 쿼리에 대한 모든 정보(데이터, 상태 필드 또는 마지막 fetching이 언제 발생했는지와 같은 메타 정보)가 포함될 뿐만 아니라 쿼리 함수를 실행하고 재시도, 취소 및 중복 제거 로직이 포함된다.
Query에는 우리가 불가능한 상태에 빠지지 않도록 하는 내부 상태 머신이 있다. 예를 들어 이미 fetching을 수행하는 동안 쿼리 함수를 실행해야 하는 경우 해당 fetch는 중복 제거될 수 있다. 쿼리가 취소되면 이전 상태로 돌아간다.

가장 중요한 것은, 쿼리가 누가 쿼리 데이터에 관심있는지를 알고 해당 `관찰자`에게 모든 변경 사항을 알릴 수 있다는 것이다.

## QueryObserver

![queryObserver.png](https://tkdodo.eu/blog/static/6ae82e26feffaff59ef521fef095c2d8/88b03/queryObserver.png)
Observer는 쿼리와 이를 사용하려는 컴포넌트 사이의 접착제이다. Observer는 `useQuery`를 호출할 때 생성되며 항상 정확히 하나의 쿼리를 구독한다. 그렇기 때문에 `useQuery`에 `queryKey`를 전달해야 한다. 😉

`Observer`는 조금 더 많은 작업을 수행한다. Observer는 대부분의 최적화가 이루어지는 곳이다. `Observer`는 컴포넌트가 사용 중인 `Query`의 속성을 알고 있어, 관련 없는 변경 사항은 알릴 필요가 없다. 예를 들어 데이터 필드만 사용하는 경우 백그라운드 refetch에서 *isFetching*이 변경되는 경우 컴포넌트를 다시 렌더링할 필요가 없다.

추가로 각 `Observer`는 _select_ 옵션을 가질 수 있으며 여기에서 데이터 필드의 어떤 부분에 관심이 있는지를 결정할 수 있다. 이전에 [#2: React Query Data Transformations](https://tkdodo.eu/blog/react-query-data-transformations#3-using-the-select-option) 에서 이 최적화에 대해 쓴 적이 있다. `staleTime`또는 interval fetching과 같은 대부분의 타이머는 observer-level에서도 발생한다.

## Active and inactive Queries

`Observer`가 없는 `Query`를 비활성 쿼리라고 한다. 여전히 캐시에 있지만 어떤 컴포넌트에서도 사용되지 않는다. React Query Devtools를 살펴보면 비활성 쿼리가 회색으로 표시되는 것을 볼 수 있다. 왼쪽의 숫자는 쿼리를 구독하는 `Observer`의 수를 나타낸다.

## The complete picture

![architecture.png](https://tkdodo.eu/blog/static/b8f21f7ad3c33c99c4970eb2b8daf26c/88b03/architecture.png)
모두 합치면 대부분의 로직이 프레임워크에 구애받지 않는 Query Core(`QueryClient`, `QueryCache`, `Query`, `QueryObserver`) 내부에 있음을 알 수 있다.

새 프레임워크용 어댑터를 만드는 것이 매우 간단한 이유이다. 기본적으로 `Observer`를 생성하고, 구독하고, `Observer`가 알림을 받으면 컴포넌트를 re-render하는 방법이 필요하다. [react](https://github.com/TanStack/query/blob/9d9aea5fb12eb89dec54c619845b3d226b53cf2b/packages/react-query/src/useBaseQuery.ts#L33-L115) 및 [solid](https://github.com/TanStack/query/blob/9579dd893656d0a4a7ac0207a204d4b3735c329d/packages/solid-query/src/createBaseQuery.ts#L33-L131) 용 useQuery 어댑터에는 각각 약 100줄의 코드만 있다.

## From a component perspective

마지막으로 다른 시각에서 흐름을 살펴보자 - 컴포넌트로부터 시작하는
![flow.png](https://tkdodo.eu/blog/static/6a91dda0ac51a22b42200d979276354a/88b03/flow.png)

- 컴포넌트가 마운트되면 `Observer`를 생성하는 `useQuery`를 호출한다.
- `Observer`는 `QueryCache`에 있는 `Query`를 구독한다.
- 해당 구독은 `Query` 생성을 트리거하거나(아직 존재하지 않는 경우) 데이터가 stale하다고 간주되는 경우 백그라운드 refetch을 트리거할 수 있다.
- fetch를 시작하면 `Query`의 상태가 변경되므로, `Observer`에게 이에 대한 정보가 제공된다.
- `Observer`는 몇 가지 최적화를 실행하고 잠재적으로 컴포넌트에게 업데이트를 알리면, 새 상태를 render 할 수 있다.
- `Query` 실행이 끝나면, `Observer`에게도 이 사실을 알린다.

이것은 많은 잠재적 흐름 중 하나일 뿐이라는 점에 유의해라. 이상적으로는 컴포넌트가 마운트될 때 데이터가 이미 캐시에 있을 것이다. 이에 대한 내용은 [#17: Seeding the Query Cache](https://tkdodo.eu/blog/seeding-the-query-cache) 에서 읽을 수 있다.
모든 흐름에 대해 동일한 점은 대부분의 로직이 React(또는 Solid 또는 Vue) 외부에서 발생하고 상태 시스템의 모든 업데이트가 컴포넌트에 알려야 하는지 여부를 결정하는 `Observer`로 전파된다는 것이다.


React Query는 어떻게 동작하나요?

Inside React Query


체감상 점점 많은 기업들이 프론트엔드 코테의 경우 javascript로만 문제 풀이 언어를 제한하는 것 같다. 몇년 전까지만 하더라도 코테 언어로 javascript를 지원하는 회사들이 정말 유명한 회사 몇곳을 제외하고는 없었는데 플랫폼의 발전과 프론트엔드 분야의 성장(?)으로 대부분 javascript를 지원하고 있다. 물론 프로그래머스로만으로도 충분히 코딩테스트 대비를 할 수 있지만 압도적으로 많은 문제 수와 특이한 형식의 입출력에 익숙해지려면 백준으로의 연습도 필요하다고 생각한다(실제로 몇몇 기업의 경우 javascript지만 백준 형식으로 node.js형식 압출력을 받는다)

개인적으로는 코테를 보며 때려 맞추는 형식을 많이 취한다는 느낌이 들었다. 프로그래머스의 경우 모든 입력값들을 보여주지는 않지만 그래도 몇개의 테스트케이스가 맞았는지는 보여진다. 백준은 이와 달리 맞았는지 틀렸는지만 보여지기 때문에 때려 맞추는 습관을 없애기 위해서 백준으로서의 연습이 필요하다고 느꼈다.
처음에 거부감이 들 수 있지만 한 번 템플릿을 만들어 놓고 써먹으면 되기 때문에 백준으로도 javascript 문제 푸는 방법을 소개하고자 한다.

## Local 환경

폴더를 하나 만들고 안에 input.txt, solution.js 파일을 만든다. 앞으로 입력값은 input.txt에 정답 코드는 solution.js에 작성하면 된다. 이렇게 받은 입력값은 모두 문자열 형식임을 주의하면서 문제를 풀자.

```js
const fs = require("fs");
const input = fs.readFileSync("./input.txt").toString().trim().split("\n");

const solution = () => {
  // 답안 작성
};

solution();
```

실행은 터미널에서 `node solution.js`로 한다.

## 백준 제출

입력값을 가져오는 부분만 수정해주면 된다.

```js
const fs = require("fs");
const input = fs.readFileSync("/dev/stdin").toString().trim().split("\n"); // 입력 부분 수정

const solution = () => {
  // 답안 작성
};

solution();
```

## javascript로 풀 때 주의할 점

분명 알고리즘은 맞는 것 같은데 시간초과가 빈번하게 일어난다. 이럴때는 역시 입출력이 문제일 확률이 높다. console.log는 매우 느린 작업이다(IO 작업) for문을 돌며 그때 그때 답을 출력하면 시간초과가 날 확률이 높다. answer 배열을 만들어서 마지막에 `answer.join(‘\n’)` 형식으로 출력하자.


우리 자스도 백준 풀 줄 알아요

Javascript로 백준 풀기


배열의 일부 구간의 합을 빠르게 구할 수 있게 해주는 알고리즘이다. N개의 원소가 주어졌을 때 반복문을 통해 일정 구간의 합을 구하고자 하면 O(N)의 시간 복잡도가 걸리지만 부분합 알고리즘을 사용하면 O(1) 시간 복잡도로 문제를 해결할 수 있다.

아래와 같은 배열이 있다고 하자
![image:77259C36-C1BC-41E9-A943-F7074D374468-26818-000013F1CD9D50E6/IMG_2438.jpg](https://user-images.githubusercontent.com/67692759/213374978-a4c745a9-62de-478a-adc7-934c9b1c3b76.jpg)

배열의 누적합을 구하면 다음과 같다. O(1)로 이를 구할 수 있다.
![IMG_2440](https://user-images.githubusercontent.com/67692759/213375069-1799fa35-603f-4681-9e88-032adeee157c.jpg)

만약 1~3까지의 부분합을 구하고자 한다면 아래와 같이 구할 수 있다. 어떤 구간을 구하고자 하더라도 뺄셈을 통해 빠르게 구할 수 있게 된다.

![IMG_05176FEEC7D5-1](https://user-images.githubusercontent.com/67692759/213375142-89456c22-cd9b-4ecb-aa59-a4550c50820f.jpeg)

## 1차원 누적합

이 아이디어를 활용해서 어떤 구간에 값을 더하고자 할때 이를 빠르게 구하는 방법에 대해 알아보자. 매번 구간에 값을 더하게 되면 O(N)의 복잡도를 가지게 된다. 부분합 알고리즘을 통해 복잡도를 줄일 수 있다.
여기서부터 여기까지 값을 더할거야 라고 표시를 해놓는 것이 아이디어이다. 예시를 통해 살펴보자

만약 2~5까지 3을 더하고자 한다면 다음과 같이 표시해 둔다.
![8F6C04D2-0857-4734-8215-9488C11C4249](https://user-images.githubusercontent.com/67692759/213375168-74ffae55-9cb3-419f-bade-222d52e77548.png)

이후 구간합을 구한다. 원하는 결과가 나오는 것을 알 수 있다.
![7C399FCA-BF4B-4D96-891E-39781D707373](https://user-images.githubusercontent.com/67692759/213375221-c83b92cd-81d4-4d42-b1a8-23935868ca96.png)

이는 여러 구간에 값을 더하고자 할 때 효력이 나타난다.
[2, 5] 에 3을 더하고
[0, 3] 에 2를 빼고
[4, 7] 에 4를 더한다고 하자

아래와 같이 표시를 할 수 있다. 구현의 편의를 위해 배열의 길이보다 1길게 만들어서 표시하면 더 편하다.
![420994CD-0C1A-4665-BA87-EEE756C929F3](https://user-images.githubusercontent.com/67692759/213375238-497fdfc7-fdc0-45ba-86a5-49b92d64e100.png)

마지막에 누적합을 구하면 원하는 결과가 나온다.
![70DEF483-1FA7-47A7-8963-7DFF28DA9246](https://user-images.githubusercontent.com/67692759/213375292-8c6a4039-edf1-416b-a7f7-67ab91c33c25.png)

## 2차원 누적합

1차원의 아이디어를 넓혀서 2차원에도 적용이 가능하다. 아래 순서로 2차원 배열의 누적합도 쉽게 구할 수 있다.
![28CDA855-569A-42E6-8A4D-F1683F3A7DF5](https://user-images.githubusercontent.com/67692759/213436240-576b9098-241c-4a13-a100-ba840fd79653.jpeg)

### 관련 문제

[11659번: 구간 합 구하기 4](https://www.acmicpc.net/problem/11659)

[11660번: 구간 합 구하기 5](https://www.acmicpc.net/problem/11660)

[[2022 카카오 블라인드] 파괴되지 않는 건물](https://school.programmers.co.kr/learn/courses/30/lessons/92344)

앞으로 연속되는 구간의 합을 구하고자 할 일이 있다면 누적합 알고리즘을 생각하자.


누적합,구간합 알고리즘(Prefix Sum)


## 댓글 기능 추가

어떤 기능이 더 들어가면 좋을까 고민하다 댓글 기능을 추가하기로 했다. Github issue를 기반으로 동작하는 [utteranc](https://utteranc.es/)를 사용해보자.

### react에서 쓸 수 있도록 컴포넌트화

utteranc의 사용방법은 매우 간단하다. 홈페이지에서 제안하는대로 따라가면 된다. 원하는 레포에 utteranc를 다운받고, 원하는 형식을 선택하고 해당 script를 사용하면 된다. page pathname보다는 page title을 issue tittle로 하는 것이 보기 좋을 것 같아 page title을 선택하였다. 내 블로그는 react를 기반으로 만들어졌기 때문에 해당 script를 컴포넌트화 하여 컴포넌트 형식으로 사용할 수 있도록 하자.

```tsx
import useThemeMode from "hooks/useThemeMode";

const Comment = () => {
  const { themeMode } = useThemeMode();

  return (
    <section
      ref={(elem) => {
        if (!elem) {
          return;
        }
        const scriptElem = document.createElement("script");
        scriptElem.src = "https://utteranc.es/client.js";
        scriptElem.async = true;
        scriptElem.setAttribute("repo", "prefer2/prefer2.dev");
        scriptElem.setAttribute("issue-term", "title");
        scriptElem.setAttribute("theme", `github-${themeMode}`);
        scriptElem.crossOrigin = "anonymous";
        elem.replaceChildren(scriptElem);
      }}
    />
  );
};

export default Comment;
```

### 😱 Github 로그인 시 redirect가 이상한 페이지로 이동?!?!

![utteranc 오류](https://user-images.githubusercontent.com/67692759/212606818-3490371c-3386-4146-89e3-3b2c0671fa11.png)

issue를 찾아보니 redirect시 link의 cannoical를 사용한다고 한다. 덕분에 잘못된 cannoical을 설정해주고 있었음을 확인할 수 있었다. 오타를 고쳐주니 정상적으로 동작했다. 혹시 나처럼 redirect가 이상한 곳으로 가서 404 에러가 발생한다면 cannonical값을 다시 한 번 확인해보자.

[https://github.com/utterance/utterances/issues/474](https://github.com/utterance/utterances/issues/474)

---

## Recoil 얹기

댓글을 추가하고 나니 댓글의 테마도 모드에 따라 변경되게 하고 싶었다. 기존에 알아보고 싶었던 recoil도 학습할 겸 recoil를 사용해보았다.

recoil 개념에 대해 알아보기 좋은 동영상

[https://www.youtube.com/watch?v=\_ISAA_Jt9kI](https://www.youtube.com/watch?v=_ISAA_Jt9kI)

### next.js + recoil

쉽게 적용이 가능했으나 hot module replacement를 사용할때마다 에러가 발생하였다. 해결방법을 찾다보니 해당 이슈가 꽤나 핫한 것을 확인할 수 있다.

![next.js + recoil 에러 메시지](https://user-images.githubusercontent.com/67692759/212606920-636dccf7-c73e-4a61-b951-2208daa1b64a.png)

https://github.com/facebookexperimental/Recoil/issues/733

recoil도 해당 문제점을 알고 해결 방법을 최근에 추가하였다. [https://recoiljs.org/ko/blog/2022/10/11/recoil-0.7.6-release](https://recoiljs.org/ko/blog/2022/10/11/recoil-0.7.6-release)

블로그에서 제안하듯이 `RecoilEnv.RECOIL_DUPLICATE_ATOM_KEY_CHECKING_ENABLED = false`

로 환경 설정값을 지정해주면 된다.

[https://nextjs.org/docs/messages/react-hydration-error](https://nextjs.org/docs/messages/react-hydration-error)

사실 단순히 테마 값 하나만을 위해서 recoil을 추가한 건 좀 많이 과하다. 그래도 처음으로 recoil을 사용해보고 어떤 식으로 동작하는지 공부해볼 수 있었다.

---

## Scroll Progress Bar 추가

사용자가 전체 글의 어느 위치에 있는지 보여주기 위해 scroll progress bar를 추가하였다. 페이지가 그려지고 나서야 전체 페이지의 높이를 알 수 있기 때문에 `useEffect`를 사용하여 이를 구했다. (rAF 기반 throttle을 걸어 주었는데 의문점이 생겨서 관련 내용은 따로 정리해볼 예정이다)

페이지 전환 시에는 스크롤의 위치가 0으로 되게 하기 위해서 아래와 같은 코드를 추가해주었다

```tsx
Router.events.on("routeChangeComplete", (): void => setScrollPercentage(0));
```

---

## 이전글, 다음글

포스팅 마다 이전글, 다음글을 보여주는 컴포넌트를 추가하였다. 포스팅 페이지 렌더링 시 slug 값을 가져오는 형식이다. 로직은 아래와 같이 작성했는데 조금 더 좋은 방법이 없을지 고민이다.

```tsx
export const getPrevNextPosts = (slug: string) => {
  const slugs = getPostSlugs();

  let slugIndex = 0;
  const posts = slugs
    .map((slug) => getPostBySlug(slug))
    .sort(
      (post1, post2) =>
        Number(new Date(post2.date)) - Number(new Date(post1.date))
    )
    .map((post, idx) => {
      if (post.slug === slug) slugIndex = idx;
      return { title: post.title, slug: post.slug };
    });

  if (slugIndex === 0) return { prev: posts[slugIndex + 1] };
  if (slugIndex === slugs.length - 1) return { next: posts[slugIndex - 1] };

  const nextPost = posts[slugIndex - 1];
  const prevPost = posts[slugIndex + 1];

  return { prev: prevPost, next: nextPost };
};
```

slug과 제목을 넘겨주어 포스팅 하단에서 제목을 확인할 수 있고, 이를 클릭하면 해당 글로 이동하게 된다.

![이전글, 다음글 기능](https://user-images.githubusercontent.com/67692759/212607324-0ee77646-ad0c-4b99-8779-252a613f9378.png)

2편에는 어떤 기능들을 추가해야할지 흠흠


댓글기능 추가, recoil, scroll progress bar, 이전글 다음글

블로그 발전기 - 1편


![http 완벽 가이드 표지](https://user-images.githubusercontent.com/67692759/211473613-0531c7c1-578d-4c68-993a-138e17e7ce3e.png)

HTTP 완벽 가이드의 `1. HTTP: 웹의 기초`를 읽고 정리한 내용입니다.

---

# 2장: URL과 리소스

URL은 브라우저가 정보를 찾는데 필요한 리소스의 위치를 가리키며, URL을 이용해 사람과 애플리케이션이 인터넷사의 수섭억 개의 리소스를 찾고 사용하며 공유할 수 있다.

`URI`는 `URL`과 `URN`으로 이루어져있다. URN은 현재 리소스가 어디에 존재하든 상관없이 그 이름만으로 리소스를 식별하고, URL은 리소스가 어디 있는지 설명해서 리소스를 식별한다. URN은 유일무이한 이름 역할을 한다. 즉 리소스를 다른 곳으로 옮기더라도 동일한 URN으로 사용이 가능하다. 하지만 URN은 아직 채택되지 않아 접할 기회가 많지 않다.

## URL 구조

![Untitled](https://user-images.githubusercontent.com/67692759/211474642-3449b10f-1257-45f6-86c8-fcfb7ec6bb2b.png)

- 스킴(프로토콜): 리소스에 어떻게 접근하는지 알려준다.
- 도메인: 서버의 위치. 웹 클라이언트의 리소스가 어디에 호스팅 되어 있는지 알려준다.
- 포트: 리소스를 호스팅하는 서버가 열어놓은 포트번호. 많은 스킴이 기본 포트를 가지고 있다.
- 리소스 경로: 요청받은 리소스가 무엇인지 알려준다.
- 파라미터: 애플리케이션이 서버에 정확한 요청을 하기 위해 필요한 입력 파라미터들을 받는다. 이름/값 쌍의 리스트로 이루어진다.
  - 질의 문자열(Query String): 요청받을 리소스 형식의 범위를 좁히기 위해서 사용할 수 있다. 대부분 ‘&’로 나뉜 ‘이름=값’ 쌍 형식의 질의 문자열을 사용한다.
- 프래그먼트(앵커): 리소스의 특정 부분을 가리킬 수 있도록 프래그먼트 컴포넌트를 제공한다.

## 안전하지 않은 문자

이스케이프라는 기능으로 안전하지 않은 문자를 안전한 문자로 인코딩 할 수 있다. 이스케이프 문자열은 US-ASCII에서 사용이 금지된 문자들로, 특정 문자나 데이터를 인코딩할 수 있게 하여 이동성과 완성도를 높인다.

안전하지 않은 문자를 퍼센티지 기호(%)로 시작해, ASCII 코드로 표현되는 두 개의 16진수 숫자로 이루어진 이스케이프 문자로 바꾼다.

입력받은 URL에서 어떤 문자를 인코딩해야 하는지 결정하는 데는 브라우저와 같이 사용자로부터 최초로 URL을 입력받는 애플리케이션에서 하는 것이 가장 적절하다

---

# 3장: HTTP 메시지

## 메시지의 흐름

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다. 메시지가 서버로 향하는 것은 `인바운드`이고, 모든 처리가 끝난 뒤에 사용자에게 돌아오는 것은 `아웃바운드`이다.

모든 메시지는 다운스트림으로 흐른다. 메시지의 발송자는 수신자의 업스트림이다.

## 메시지의 구조

HTTP 메시지는 `시작줄`, `헤더`, `본문` 세 부분으로 이루어진다. 시작줄과 헤더는 줄 단위로 분리된 아스키 문자열이며, 본문은 데이터 덩어리이다.

![Untitled](https://user-images.githubusercontent.com/67692759/211474771-67cec665-fada-408b-93f0-e75bbb54605c.png)

### 시작줄

요청 메시지의 시작줄은 무엇을 해야하는지 말해주고, 응답 메시지의 시작줄은 무슨 일이 있었는지 말해준다.

요청줄에는 메서드와 그 동작에 대한 대상을 지칭하는 URL이 있다. 또한 클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에게 알려주는 HTTP 버전도 포함한다.

응답줄에는 응답 메시지에서 쓰인 HTTP 버전, 숫자로 된 상태고드, 수행 상태에 대해 설명해주는 텍스트로 된 사유 구절이 들어있다.

### 헤더

헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다. Content-length, ContentType 등이 들어간다.

### 엔티티 본문

HTTP 메시지의 화물이다. 이것을 수송하도록 HTTP가 설계된 것이다. 여러 종류의 데이터를 실어 나를 수 있다.

더 자세한 내용은 아래 링크에서 확인 가능하다

[https://developer.mozilla.org/ko/docs/Web/HTTP/Messages](https://developer.mozilla.org/ko/docs/Web/HTTP/Messages)

[https://developer.mozilla.org/ko/docs/Web/HTTP/Methods](https://developer.mozilla.org/ko/docs/Web/HTTP/Methods)

[https://developer.mozilla.org/ko/docs/Web/HTTP/Status](https://developer.mozilla.org/ko/docs/Web/HTTP/Status)

[https://developer.mozilla.org/ko/docs/Web/HTTP/Headers](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers)

---

# 4장: 커넥션 관리

## TCP 커넥션

TCP 커넥션은 인터넷을 안정적으로 연결해준다. TCP는 HTTP에게 신뢰할 만한 통신 방식을 제공한다. TCP 커넥션의 한쪽에 있는 바이트들은 반대쪽으로 순서에 맞게 정확하게 전달된다.

![Untitled](https://user-images.githubusercontent.com/67692759/211474818-62f09f4f-67f4-41f4-bd78-fb09a5d7e3da.png)

TCP는 IP 패킷(IP 데이터그램)이라고 불리는 작은 조각을 통해 데이터를 전송한다. TCP는 세그먼트라는 단위로 데이터 스트림을 잘게 나누고, 세그먼트를 IP 패킷이라고 불리는 봉투에 담아서 인터넷을 통해 데이터를 전달한다.

컴퓨터는 TCP 커넥션을 여러개 가지고 있다. TCP는 포트 번호를 통해서 이런 여러 개의 커넥션을 유지한다. TCP 커넥션은 발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트 네 가지 값으로 식별한다. 이 네 가지 커넥션 구성요소를 모두 똑같이 가리키고 있는 커넥션은 있을 수 없다.

### TCP 소켓프로그래밍

운영체제에서TCP 커넥션의 생성과 관련된 여러 기능을 제공한다. 소켓 API를 사용하면 종단 데이터 구조를 생성하고, 원격 서버의 TCP 종단에 그 종단 데이터 구조를 연결하여 데이터 스트림을 읽고 쓸 수 있다. TCP API는, 기본적인 네트워크 프로토콜의 핸드셰이킹, TCP 데이터 스트림과 IP 패킷 간의 분할 및 재조립에 대한 모든 세부사항을 숨긴다.

## TCP의 성능에 대한 고려

HTTP는 TCP 바로 위에 있는 계층이기 때문에 HTTP 트랙잭션의 성능은 그 아래 계층인 TCP 성능에 영향을 받는다. 클라이언트 서버가 너무 많은 데이터를 내려받거나 복잡하고 동적인 자원들을 실행하지 않는 한, 대부분의 HTTP 지연은 TCP 네트워크 지연 때문에 발생한다.

## 지속 커넥션

HTTP/1.1을 지원하는 기기는 처리가 완료된 후에도 TCP 커넥션을 유지하여 앞으로 있을 HTTP 요청에 재사용할 수 있다. 오늘날 많은 웹 애플리케이션은 적은 수의 병렬 커넥션만을 맺고 그것을 유지한다.

### keep-alive

keep-alive 커넥션을 구현한 클라이언트는 커넥션을 유지하기 위해서 요청에 Connection: Keep-Alive 헤더를 포함시킨다. 이 요청을 받은 서버는 그 다음 요청도 이 커넥션을 통해 받고자 한다면, 응답 메시지에 같은 헤더를 포함시켜 응답한다. 다만 이 요청을 받았다고 해서 무조건 그것을 따를 필요는 없다.

### HTTP/1.1의 지속 커넥션

HTTP/1.1의 지속 커넥션은 기본으로 활성화되어 있다. 응답에 Connection: close 헤더가 없으면 응답 후에도 커넥션을 계속 유지하는 것으로 추정한다.


다람쥐 책을 읽자 1. HTTP: 웹의 기초

HTTP 완벽 가이드(1)


> props이 변경되지 않았을 경우 리렌더링 되지 않도록 해준다

```jsx
const MemoizedComponent = memo(SomeComponent, arePropsEqual?)
```

부모가 리렌더링되더라도 props이 변경되지 않는다면 리렌더링하지 않는다. 성능 최적화를 위한 방법일 뿐 무조건 리렌더링 안된다는 보장은 없다.

```jsx
const Greeting = memo(function Greeting({ name }) {
  return <h1>Hello, {name}!</h1>;
});

export default Greeting;
```

## 언제 memo를 사용해야 할까

대부분 불필요. 같은 prop으로 리렌더링이 많이 일어날 때 사용한다. prop이 항상 변경된다면 불필요하다. 객체나 함수를 넘기는 경우라면 useMemo, useCallback을 같이 사용해야할 일이 있을것이다. 물론 내부의 state가 변경되거나 context가 변경되거나 props이 변경된다면 이 컴포넌트도 리렌더링된다.

아래 규칙들을 따르다보면 memo를 사용할 일이 별로 없다.

- 컴포넌트가 다른 컴포넌트를 감싸고 있는 형식이라면 children 사용하기. 겉의 컴포넌트가 리렌더링 되더라도 React는 children이 리렌더링이 필요하지 않다는 것을 알고 있다.
- 가능하다면 state를 올리기보다는 local state 사용하기.
- 렌더링 로직을 순수하게 유지하기. 리렌더링이 문제를 일으킨다면 컴포넌트를 잘못짜고 있는걸지도 모른다! memoization을 추가하기 보다 이런 오류를 수정하자
- state를 업데이트하는 불필요한 effect를 피하기. 대부분의 성능 문제는 effect로 인해 업데이트되는 체이닝때문에 렌더링이 반복해서 일어날 때 일어난다.
- effect의 불필요한 의존성 배열 없애기.

응답이 느린것처럼 보인다면 [profiler](https://beta.reactjs.org/blog/2018/09/10/introducing-the-react-profiler)를 사용해서 어떤 컴포넌트를 memorization하면 가장 좋을지 찾아보자. [일반적인 memorization은 자동으로 일어날 수 있도록](https://www.youtube.com/watch?v=lGEMwh32soc) 연구하고 있다(React Forget 컴파일러 신기방기. 어떤 식으로 memo를 관리해야할지 살펴보기 좋은 영상인듯)

## props 변경 최소화하기

memo를 사용하면 props가 얕은 비교시 동일하지 않으면 리렌더링한다. [Object.is](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is) 비교를 통해 prop을 비교함을 뜻한다. `Object.is(3, 3)`은 `true`지만 `Object.is({ }, { })`는 `fasle`임에 주목하자.

memo를 최대한으로 잘 사용하려면, props가 변경되는 것을 최소화해야한다. 만약 props가 객체 형식이라면 `useMemo`를 사용하여 객체가 항상 새로 생성되는 것을 막자. 함수 형식이라면 `useCallback`을 사용하자.

```jsx
function Page() {
  const [name, setName] = useState("Taylor");
  const [age, setAge] = useState(42);

  const person = useMemo(() => ({ name, age }), [name, age]);

  return <Profile person={person} />;
}

const Profile = memo(function Profile({ person }) {
  // ...
});
```

더 좋은 방법은 prop으로 최대한 적은 정보를 받는 것이다. 전체 정보를 받기보다 개별의 정보를 받을 수 있게 변경할 수 있다

```jsx
function Page() {
  const [name, setName] = useState("Taylor");
  const [age, setAge] = useState(42);
  return <Profile name={name} age={age} />;
}

const Profile = memo(function Profile({ name, age }) {
  // ...
});
```

## useMemo VS useCallback

두 훅 모두 어떤 것을 기억하고자(memoize) 할 때 사용한다. 두 훅의 차이는 어떤 것을 캐싱하고자 하는지에 있다.

- useMemo: 함수의 호출 결과를 캐싱한다
- useCallback: 함수 자체를 캐싱한다. 넘겨지는 함수를 호출하지 않고 이 자체를 캐싱한다.

```jsx
// Simplified implementation (inside React)
function useCallback(fn, dependencies) {
  return useMemo(() => fn, dependencies);
}
```

## 언제 useMemo와 useCallback을 사용해야 할까

![kent 형님의 useCallback관련 트위터.png](https://user-images.githubusercontent.com/67692759/210934059-9ab4cc52-a400-4de6-9304-8458f2ae2eae.png)

의존성 배열이 있다면 React가 이전 함수들에게 참조를 가지고 있을 수 있다. 왜냐하면 memorization은 이전과 동일한 의존성이 주어진다면, 가지고 있던 옛 버전의 복사본을 return하는 것을 뜻하기 때문이다. 이것은 React가 의존성 배열도 동일성 체크를 위해 가지고 있음을 뜻한다(물론 클로저에 의해서 일어나는 일이니 당연한 말이다)

그렇다면 성능상으로 꼭 이점이 되지 않을지도 모르는 두 훅을 언제 사용해야 할까? 두 훅이 React에 내장되어 있는 이유는 아래와 같다.

1. 참조 동일성 (Referential equality)
2. 계산적으로 비용이 많이 드는 계산 (Computationally expensive calculations)

### 참조 동일성

```jsx
function Foo({ bar, baz }) {
  const options = { bar, baz };
  React.useEffect(() => {
    buzz(options);
  }, [options]); // we want this to re-run if bar or baz change
  return <div>foobar</div>;
}
function Blub() {
  return <Foo bar="bar value" baz={3} />;
}
```

useEffect의 의존성 배열을 체크하고, 자바스크립트의 특성 때문에 매 렌더링마다 option은 새로운 값이 된다. 즉 bar, baz가 변경될때만 불러지는 것이 아니라 매 렌더링마다 불러지게 되는 것이다.

이를 아래와 같이 변경하여 원하는 형식으로 동작하도록 할 수 있다.

```jsx
function Foo({ bar, baz }) {
  React.useEffect(() => {
    const options = { bar, baz };
    buzz(options);
  }, [bar, baz]);
  return <div>foobar</div>;
}
function Blub() {
  const bar = React.useCallback(() => {}, []);
  const baz = React.useMemo(() => [1, 2, 3], []);
  return <Foo bar={bar} baz={baz} />;
}
```

### 계산적으로 비용이 많이 드는 계산

예를 들어 동기적으로 계산을 해야하는 복잡한 함수를 생각해보자.

```jsx
function RenderPrimes({ iterations, multiplier }) {
  const primes = calculatePrimes(iterations, multiplier);
  return <div>Primes! {primes}</div>;
}
```

iterations와 multiplier는 매우 느릴 수 있다. 같은 결과값을 두번 계산할 필요 없이 useMemo를 사용하여 기존의 값을 사용할 수 있다.

```jsx
function RenderPrimes({ iterations, multiplier }) {
  const primes = React.useMemo(
    () => calculatePrimes(iterations, multiplier),
    [iterations, multiplier]
  );
  return <div>Primes! {primes}</div>;
}
```

![Untitled](https://user-images.githubusercontent.com/67692759/210934131-cbf3a1d9-6955-4e73-a59e-d521daeb2768.png)

kent 형님께서 추상화/최적화가 나에게 고쳐달라고 소리칠 때 까지 기다리라고 하셨다. 기다리자.

[https://beta.reactjs.org/reference/react/memo](https://beta.reactjs.org/reference/react/memo)

[https://overreacted.io/ko/before-you-memo/](https://overreacted.io/ko/before-you-memo/)

[https://dkrnfls.tistory.com/413](https://dkrnfls.tistory.com/413)

[https://kentcdodds.com/blog/usememo-and-usecallback](https://kentcdodds.com/blog/usememo-and-usecallback)


React.memo 톺아보기


기술 블로그를 tistory를 통해 운영하고 있지만, 학습을 위해 가장 좋은 방법이라고 생각이 되어 나만의 블로그 만들기를 시작했다. 블로그를 만들게 된 이유는 아래와 같다.

- SSR, SEO 학습
- 백엔드 없이 정적으로 진행 가능
- 나만의 커스터마이징이 가능
- 간지

기술 스택은 아래와 같이 선택했다.

- Next.js
- Typescript
- Tailwind
- Vercel

스타일링의 경우 기존에 사용하던 css-in-js가 아닌 tailwind를 선택했다. 스타일을 위한 불필요한 컴포넌트가 줄어들었고, 일관성 있는 디자인으로 개발할 수 있는 것 같다. 옛날 옛적에 접했던 bootstrap의 기억이 새록새록 났다.

[Next.js 공식 문서](https://nextjs.org/learn/foundations/about-nextjs?utm_source=next-site&utm_medium=homepage-cta&utm_campaign=next-website)와 Next에서 제공하는 [블로그 예시](https://github.com/vercel/next.js/tree/canary/examples/blog-starter)를 보면서 만들어보았다. Next.js 공식 문서가 굉장히 잘 작성되어있고 Next관련 내용뿐만아니라 웹 전반의 내용을 잘 설명해주고 있어서 추천한다.

정적 블로그를 만들기 때문에 사용하는 SSG가 무엇인지 간단하게 알아보자.

> 💡 Static Site Generation  
> With Static Site Generation, the HTML is generated on the server, but unlike server-side rendering, there is no server at runtime. Instead, content is generated once, at build time, when the application is deployed, and the HTML is stored in a CDN and re-used for each request.

빌드 타임에 HTML이 생성되고, 이 생성된 HTML 파일은 CDN에 저장되어 사용된다. 많은 컨텐츠가 미리 렌더링되고 정적인 컨텐츠라는 특징 덕분에 페이지 로드 시간이 빠르다.

---

## 기본 설정

```bash
yarn create next-app --typescript
```

이후 [tailwind 공식 문서](https://tailwindcss.com/docs/guides/nextjs)에서 설명하는 대로 설정을 추가하였다. 절대 경로 설정을 위해 tsconfig 경로 설정을 추가하였다.

---

## Dynamic Routes

next는 규칙에 따라 pages 폴더에 파일을 생성하면 파일명에 맞게 라우팅을 해준다. 블로그의 경우 인덱스, 파일명 등의 정보가 url에 나타나야하기 때문에 dynamic routes가 필요하다.

![dynamic routes image](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbZ2vOU%2FbtrVk5eeZ16%2FnTkRpOAWuU5gXCYq0eKQ5K%2Fimg.png)

posts/\[slug\] 형태를 가지고자 하기 때문에 pages/posts 폴더안에 \[slug\].tsx 파일을 만들어 블로그 글 페이지를 만든다. getStaticProps로 글의 내용을 가져오고(\[slug\].md 파일을 통해) 페이지는 getStaticProps가 리턴한 값을 props로 가지게 된다. getStaticPath로 이동 가능한 경로들을 정의하여 dynamic routing이 가능하도록 한다.

```tsx
export async function getStaticProps({ params }: Params) {
  const post = getPostBySlug(params.slug);

  return {
    props: {
      post,
    },
  };
}

export async function getStaticPaths() {
  const posts = getAllPosts();

  return {
    paths: posts.map((post) => {
      return {
        params: {
          slug: post.slug,
        },
      };
    }),
    fallback: false,
  };
}
```

---

## 글 내용 보여주기

markdown을 사용하기 때문에 이를 HTML로 변환해서 코드로 넘겨주어야한다. remark를 통해 markdown을 HTML로 변환하고, 이를 rehype로 처리할 수 있다. 이렇게 HTML로 변환한 코드는 일반 HTML이기 때문에 리액트에게 넘겨서 넣어줄 때 dangerouslySetInnerHTML로 넣어준다. innerHTML을 해주기 싫어서 찾다보니 [react-markdown](https://github.com/remarkjs/react-markdown)이라는 패키지가 있어서 이를 사용해 글 내용을 보여주었다 (react-markdown을 사용하면 DOM을 다시 그리지 않고 변경된 부분만 바꿔준다).

코드 하이라이팅을 위한 rehype-highlight와 수식을 처리하기 위한 remark-math, rehype-katex 플러그인을 추가해주었다.

```tsx
const Post = ({ post }: PostProps) => {
  return (
    <article className="prose lg:prose-xl">
      <PostHeader title={post.title} date={post.date} />
      <ReactMarkdown
        remarkPlugins={[remarkMath]}
        rehypePlugins={[rehypeHighlight, rehypeKatex]}
      >
        {post.content}
      </ReactMarkdown>
    </article>
  );
};
```

스타일링을 직접 할 수도 있겠지만 tailwind에서 제공하는 [@tailwindcss/typography](https://tailwindcss.com/docs/typography-plugin) 플러그인을 사용하였다.

---

## SEO 향상하기

next의 head를 사용해서도 쉽게 SEO를 향상시킬 수 있지만 조금 더 편하게 구현하기 위해 [next-seo](https://github.com/garmeeh/next-seo)를 사용했다. 페이지별 seo를 위해서 PageSEO 컴포넌트를 만들어 넣어주었다. favicon같은 기본 default 값을 위해서는 next-seo의 DefaultSeo를 사용하였다.

```tsx
import { NextSeo } from "next-seo";
import SEO from "seo.config";

interface PageSEOProps {
  title: string;
  description: string;
  slug: string;
}

const PageSEO = ({ title, description, slug }: PageSEOProps) => {
  return (
    <NextSeo
      title={title}
      description={description}
      canonical={`${SEO.url}/${slug}`}
      openGraph={{
        url: `${SEO.url}/${slug}`,
        title,
        description,
      }}
    />
  );
};

export default PageSEO;
```

![og image](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FcdWcYi%2FbtrVqgG12m5%2F75mydwsbG9syc1Q6v4r6V0%2Fimg.png)

og를 통해 카카오톡 미리보기까지 이쁘게 변경된 것을 확인할 수 있다. 차후에 글이 더 많아지면 sitemap도 추가해볼 예정이다.

---

## 테마 설정하기

![light mode](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbQx3Df%2FbtrVqIQU52R%2F5mF56bvB9hK4kSxZOTNTjK%2Fimg.png)
![dark mode](https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FebYlLM%2FbtrVtG56Mwu%2FR38UkgpKcsML4Cf4RX7uA0%2Fimg.png)

라이트모드, 다크모드를 만들어보았다. tailwind에서 제안한대로 [dark 클래스를 추가](https://tailwindcss.com/docs/dark-mode)해서 다크모드를 쉽게 구현할 수 있다.

새로고침 시에도 사용자가 정한 모드가 유지될 수 있도록 선택된 모드를 localstorage에 저장하였다. 초기 상태를 localstorage에서 가져오고자 했는데 server rendering이 먼저 일어나기 때문에 브라우저 환경이 아니라 localstorage를 찾을 수 없었다. 페이지가 클라이언트에 로딩된 이후에 접근할 수 있도록 useEffect로 저장된 값을 가져오도록 하였다. 만약 localstorage에 저장된 값이 없다면, 사용자의 브라우저에서 선호되는 모드를 가져와 이를 초기 값으로 사용하도록 하였다.

```tsx
const { themeMode, changeThemeToDark, changeThemeToLight } = useTheme();

const handleThemeToggle: React.MouseEventHandler = () => {
  if (themeMode === THEME.LIGHT) {
    changeThemeToDark();
  } else {
    changeThemeToLight();
  }
};

useEffect(() => {
  const mode =
    localStorage.getItem(THEME_KEY) ??
    (window.matchMedia("(prefers-color-scheme:dark)").matches
      ? THEME.DARK
      : THEME.LIGHT);
  if (mode === THEME.DARK) {
    changeThemeToDark();
  } else {
    changeThemeToLight();
  }
}, []);
```

typography를 통해 스타일링한 post부분은 [tailwind.config](https://github.com/prefer2/prefer2.dev/blob/main/tailwind.config.js)에 다크모드 관련 설정을 추가해주었다.

블로그가 워낙 여러개라 새로운 블로그는 어떤 용도로 사용할지는 모르겠다. 앞으로 tag별로 모아보기, 페이지네이션, 스크롤 위치 보여주기 기능, 검색 등을 추가하고 싶다.

### GitHub 코드 확인하기

[https://github.com/prefer2/prefer2.dev](https://github.com/prefer2/prefer2.dev)


내 입맛에 맞는 나만의 블로그 만들기 대작전