0️⃣ 로컬 환경과 배포된 서비스 간의 성능 차이가 발생하는 이유

Lighthouse로 성능을 체크해보면 로컬 환경과 배포된 서비스에서 성능 차이가 꽤 많이 발생한다.

보통은 배포 서비스에서 성능이 더 좋게 나오는데 그 이유는 번들러가 코드를 최적화하기 때문이다. 번들링 과정에서 코드 압축, Tree Shaking 같은 최적화 작업이 일어난다. 이를 통해 불필요한 코드가 제거되고, 번들 크기가 줄어들며, 브라우저가 더 효율적으로 로딩되도록 환경이 개선된다.

반면 로컬 환경에서는 디버깅 편의성을 위해 코드 최적화가 생략되거나 제한적으로 적용되기 때문에, 같은 코드로 구현되어 있더라도 로컬 환경과 배포 서비스 사이에 성능 차이가 발생할 수 있다.

1️⃣ FCP / LCP

✏️ 측정 시점

• FCP (First Contentful Paint) : 브라우저가 요청을 보낸 시점부터 DOM의 첫 번째 콘텐츠가 화면에 렌더링되는 시점

• LCP (Largest Contentful Paint) : 브라우저가 요청을 보낸 시점부터 가장 큰 콘텐츠 요소가 화면에 렌더링되는 시점

✏️ FCP가 줄어들면 LCP가 줄어들까 ?

DOM의 첫 번째 콘텐츠가 화면에 렌더링되는 시점(FCP)이 개선된다면 가장 큰 콘텐츠 요소가 화면에 렌더링되는 시점(LCP) 자체를 개선하지 않더라도, 초반 렌더링 속도가 개선됨에 따라 가장 큰 콘텐츠 요소가 렌더링되는 시점에도 영향을 미칠 것이다.

아래 그림을 보면 이해하기 쉽다.

핵심은 FCP와 LCP를 따로 생각하는 것이 아니라, 아래와 같이 연결되어 있는 모습으로 생각해보자.

FCP가 줄면, LCP가 줄어들 수 밖에 없다.

그럼에도 예외는 있다. FCP와 관계없이 LCP 자체에만 문제가 있는 경우라면, FCP를 최적화해도 LCP에 큰 영향을 미치지는 않을 것이다. (그렇지만 이런 경우는 많지 않다고 생각한다.)

2️⃣ TBT

✏️ 측정 시점

• TBT (Total Blocking Time) : 마우스 클릭, 화면 탭, 또는 키보드 누르기와 같은 사용자 입력에 페이지가 응답하지 못하는 총 시간 : DOM의 첫 번째 콘텐츠가 화면에 렌더링되는 시점(FCP)부터 상호작용 시작 시점(TTI/ Time To Interective)

3️⃣ React와 Next.js 프로젝트의 성능 지표 차이

✏️ React와 Next.js의 FCP/LCP와 TBT 비교

• React로 구현한 프로젝트는 FCP, LCP가 느리고 TBT가 빠르다.
• Next.js로 구현한 프로젝트는 FCP, LCP가 빠르고 TBT가 느리다.

위와 같은 현상이 나타나는 이유가 뭘까?

React와 Next.js의 초기 렌더링 방식에 대해 생각해보자. React는 CSR 방식, Next.js는 SSR 방식으로 초기 렌더링이 진행된다.

✏️ CSR vs SSR

▶️ CSR (Client Side Rendering)

: 첫 화면 렌더링 시, 클라이언트 단에서 모든 JS 번들을 받아오고 이를 처리하기 전까지 아무런 화면도 보여주지 않는다.

=> 초기 렌더링까지 비교적 오랜 시간이 걸리며, FCP와 LCP가 느리다. => 하지만 초기에 모든 JS 번들을 불러오기 때문에, TBT는 빠르다.

▶️ SSR (Server Side Rendering)

: JS 번들을 처리하기 전에, 첫 화면에 필요한 HTML을 먼저 화면에 띄워준다. 이 시점에서 HTML은 웹 화면을 보여주는 HTML일 뿐, 이벤트 리스너를 포함하고 있지 않다. 이후, 하이드레이션 과정을 통해 JS(이벤트 리스너 포함)를 연결하여 HTML을 상호작용 가능한 상태로 전환한다.

=> 초기 렌더링까지 비교적 시간이 적게 걸리며, FCP와 LCP가 빠르다. => 하지만 초기에 모든 JS 번들을 불러오지 않기 때문에, TBT와 화면 간 이동 속도가 느리다.

✏️ Next.js TBT 개선

Next.js에서는 동적인 화면을 만들기 위해 실행되는 하이드레이션 시간이 TBT 시간이 된다. 결국, TBT를 개선하기 위해서는 하이드레이션 시간을 줄이면 된다.

정적인 화면에서는 하이드레이션 과정이 불필요하기 때문에 모든 컴포넌트에서 하이드레이션이 수행될 필요는 없다. 이를 위해 하이드레이션을 수행하지 않는 서버 컴포넌트가 등장했다. 인터랙티브한 화면을 구현해야 한다면 use client를 활용하여 클라이언트 컴포넌트로 만들어주면 된다.

빠른 초기 렌더링이라는 강점은 살리면서, 서버 컴포넌트를 적극적으로 활용하여 페이지 간 이동이 자연스럽고 TBT와 같은 성능 저하가 느껴지지 않는다면 Next.js를 효과적으로 활용했다고 할 수 있다.

▶️ 인터렉션이 많은 서비스라면 Next.js를 사용하는게 큰 의미가 있을까?

인터랙션이 많다는 것은 클라이언트 컴포넌트의 비중이 높아지고 하이드레이션이 빈번하게 발생한다는 뜻이다. 이러한 경우, 무거운 React를 사용하는 것과 큰 차이가 없어진다.

▶️ 인터렉션을 구현하려면 클라이언트 컴포넌트가 필요한 이유

이벤트 핸들러는 윈도우 객체에 속한다. 이 때 윈도우 객체는 브라우저에만 있기 때문에, 서버에서 처리할 수 없다. 따라서 인터렉션을 구현하기 위해서는 클라이언트 컴포넌트가 필요하다.

리렌더링 최적화를 하기 위해서는 먼저 리렌더링이 발생하는 조건을 알아야 한다.

1️⃣ 리렌더링 발생 조건

1. state가 정의된 컴포넌트에서 state가 변경되었을 때

• 값이 변화했을 때 리렌더링을 발생시키기 위해 state를 사용하는 것이기 때문에, 이는 너무나 당연한 이야기이다.
• 만약 리렌더링을 의도하지 않았다면, useRef를 사용하면 된다.

2. 컴포넌트에서 받는 props의 값이 변경되었을 때

• props로 받는 값을 항상 최신 상태로 유지해야 하기 때문에, 이 또한 너무나도 당연한 이야기이다.

3. 컴포넌트에서 받는 props의 부모 컴포넌트가 렌더링되었을 때

• 이 상황에서도 당연하게 리렌더링이 발생한다고 할 수 있을까?

2️⃣ 메모이제이션

• 계산 결과를 메모리에 저장해두고 동일한 계산이 요청될 때, 계산을 다시 요청하지 않고 저장된 값을 반환하는 최적화 기법이다.

• 메모이제이션을 하는 대상에 따라 크게 3가지 방법으로 나눌 수 있다.

  • React.memo: 컴포넌트를 메모이제이션
  • useMemo: 연산의 결과 값을 메모이제이션
  • useCallback: 연산을 수행하는 함수를 메모이제이션

✏️ React.memo

• 컴포넌트를 메모이제이션하는 고차 함수

• React에서 제공하는 고차 컴포넌트(HOC)로, 컴포넌트 렌더링 결과를 메모이징하여 성능을 최적화한다.

• 해당 컴포넌트가 받는 props가 동일한지 얕은 비교를 통해 검사를 진행한다.

  • props 값이 이전 props 값과 동일하다면 > 부모 컴포넌트가 리렌더링 되어도 자식 컴포넌트는 리렌더링되지 않는다.
  • props 값이 이전 props 값과 다르다면 > 부모 컴포넌트가 리렌더링 되면, 자식 컴포넌트도 리렌더링 된다. (이 때, 부모 컴포넌트에서 관리하는 state 값이 변경되어도 리렌더링이 발생한다.)

    const SomeComponent = React.memo(function
     SomeComponent(props) {
        // …
     });

• 두 번째 인자로 커스텀 비교 함수를 받아 깊은 비교를 통해 검사를 진행할 수 있다.
  • 이전 props(prevProps)와 새로운 props(nextProps)를 인자로 받는다.
  • 비교 함수가 true를 반환할 경우 > 리렌더링이 발생한다.
  • 비교 함수가 false를 반환할 경우 > 리렌더링이 발생하지 않는다.

    function areEqual(prevProps, nextProps) {
    /*
     nextProp가 prevProps와 동일한 값을 가지면 true를 반환하고, 그렇지 않다면 false를 반환
    */
    }
    export default React.memo(MyComponent, areEqual);

🚀 주의 사항 (참조 동일성 유지의 필요성)

• 컴포넌트의 props가 이전 props 값과 동일한지 얕은 비교를 통해 검사하기 때문에, 객체나 배열, 함수 같은 참조 타입의 props를 검사할 때 문제가 발생할 수 있다.
• 예를 들어, 객체와 함수를 props로 받는 경우 객체와 함수는 참조 타입이기 때문에, 매 리렌더링마다 내용은 같지만 참조가 달라져 props가 변경되었다고 판단 > 리렌더링이 발생한다.

✏️ useMemo

• 연산의 결과 값을 메모이제이션하여 성능을 최적화하기 위한 훅

• useMemo 사용 시, 값의 참조 동일성을 유지할 수 있다.

• 첫 번째 인자로 메모이제이션할 연산, 두 번째 인자로 의존성 배열을 받는다. 의존성 배열에 포함된 값이 변경되지 않으면 이전 결과 값을 재사용한다. (useEffect와 유사한 구조)

   function School (props) {
      const name = useMemo(() ⇒ {
         return {
            lastname: ‘서’,
            firstname: ‘아름’
         };
   }. []);

• useMemo를 활용하여 값을 할당하면 의존성 배열에 포함된 값이 변경될 경우에만 재할당이 일어나기 때문에, 값의 참조 동일성을 보장한다.

• 의존성 배열이 비어있는 경우, 초기 렌더링 시에만 첫 번째 인자에 해당하는 연산을 수행한다.

✏️ useCallback

• 함수를 메모이제이션하여 성능을 최적화하기 위한 훅

• useCallbck 사용 시, 함수의 참조 동일성을 유지할 수 있다.

• 첫 번째 인자로 메모이제이션할 연산, 두 번째 인자로 의존성 배열을 받는다. 의존성 배열에 포함된 값이 변경되지 않으면 이전 함수를 재사용한다. (useMemo와 동일한 구조)

🚀 흔한 오해

• useCallback으로 메모이제이션한 함수는 의존성 배열에 포함된 값이 변하지 않을 경우, 리렌더링 시 새롭게 생성되지 않는다고 생각하기 쉽다.

• 정말 그럴까?? ❌❌

• useCallback의 인자로 넘겨주는 함수는 매 렌더링마다 반드시 다시 생성된다.

• 이후, 의존성 배열을 검사하여 이전 함수와 새롭게 생성된 함수가 다르다면 생성한 함수를 리턴해주고, 변하지 않았다면 기존에 메모이징했던 함수를 재사용한다 !!

❓ useMemo, useCallback은 React.memo 없이는 렌더링 최적화에 아무런 효과가 없을까 ?

React.memo로 컴포넌트 리렌더링을 최적화한 뒤, 내부적으로 useCallback과 useMemo를 활용하여 연산된 값이나 함수를 메모이징할 수 있다. 여기서 React.memo만 제거해보자.

기존에 리렌더링 최적화를 해둔 부분에서 다시 리렌더링이 발생하는 것을 확인할 수 있다. 그렇다면 useMemo, useCallback은 React.memo 없이는 렌더링 최적화에 아무런 효과가 없는걸까?

• React.memo는 컴포넌트 메모이제이션을 수행한다. 이러한 역할이 사라지니 더이상 컴포넌트가 메모이제이션 되지 않아 기존에 최적화해두었던 부분에서 모두 다시 리렌더링이 발생하는 것이다.

• 해당 질문에 대한 답은 React의 리렌더링 과정을 이해하면 알 수 있다.

✏️ React의 리렌더링 과정

▶️ Render Phase

• 재조정 과정을 거쳐 Virtual DOM과 Real DOM을 비교, 변경이 필요한 부분을 확인한다.

▶️ Commit Phase

• Render Phase에서 체크해뒀던 변경이 필요한 부분들을 Real DOM에 반영하는 단계이다.

• 변경이 필요한 부분이 없다면, Commit Phase는 스킵한다.

▶️ useMemo, useCallback은 유지/ React.memo를 삭제한 후, React의 리렌더링 과정

1. 부모 컴포넌트가 리렌더링 되고, 이후 자식 컴포넌트도 리렌더링 되면서 각각의 Render Phase가 실행된다.

2. useMemo와 useCallback을 통해 자식 컴포넌트들의 props 값(참조)을 이전 props 값(참조)와 동일하게 유지한다.

3. Rendar Phase내의 재조정 과정에서 Real DOM에 변경이 필요한 부분이 없다고 판단한다. 따라서, Commit Phase는 실행되지 않는다.

4. Commit Phase는 막았지만 Render Phase가 여전히 실행된다.

5. 최적화를 하긴 했는데, 눈으로 보기에는 최적화를 진행하기 전과 거의 동일하게 동작한다. 😱

▶️ 결론: Render Phase까지 막기 위해 사용하는 것이 React.memo이다 !!

❓ useMemo, useCallback, React.memo를 많이 사용하면 좋을까?

• React.memo는 컴포넌트 변경 여부를 검사하기 위해 매 렌더링마다 얕은 비교를 수행한다.

• useMemo, useCallback 역시 매 렌더링 Phase마다 의존성 배열 검사 및 캐시 관리를 수행한다.

• 이런 모든 것들이 비용이기 때문에, 리렌더링을 최적화한 효과보다 다른 부분에서 오히려 성능 저하를 일으킬 수 있다.

• 결국.. 참조 동일성을 반드시 유지해야 하는 상황이더라도, 메모이제이션을 적용하는 것이 항상 정답이라고 말할 수는 없다.

3️⃣ 마무리

최적화에는 정답이 없다 ..! 최적화 기준을 잘 세우는 것, 그리고 단면만 보지 말고 전체적인 성능을 고려하여 최적의 선택을 하는 것이 중요하다.

어디선가, 아래와 같은 말을 들은 적이 있다. 정말 띵언

"최적화를 언제 하면 좋을까요??"

1. 하면 좋을 것 같아요. > 하지 마세요.
2. 쓰읍.. 해야할 것 같은데 .. > 한 번 더 생각해보세요.
3. 진짜 진짜 진짜 무조건 해야된다 !!! > 프로파일링(측정)부터 진행해보세요.

항상 모든 것에는 trade-off가 있기 때문에, 최적화를 해서 특정 시간을 줄였다면 결국 어떤 것 (메모리, 코드의 양, 개발자의 시간 등등)을 희생했다는 이야기가 된다.

결국 어떤 것을 희생할지 잘 생각해보고, 최적화로 인해 발생하는 불필요한 비용을 최소화하는 것이 중요하다.

📚 참고자료

메모이제이션을 활용한 리렌더링 최적화 [React] React.memo로 Rendering 최적화2 (feat.예제1,2)

Refused to apply style from '~.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled. 로컬에선 잘만 돌아가던 코드가 배포 사이트에서 에러를 뱉기 시작 . .

언젠가 다시 발생할 수도 있는 에러이기에 또 이런 에러를 만났을 미래의 나를 위한.. 이런 에러와 싸우고 있을 누군가를 위한.. 트러블 슈팅 🔥

💬 혹시 깃허브 로그인이 문제 ?

우리 서비스에는 깃허브 로그인 기능이 구현되어있는데, 깃허브 보안때문에 배포 사이트에서 문제가 생기는 건가 의심을 했다. 현재 서비스 배포가 Cloudflare로 이뤄지고 있었기 때문에 정확한 문제 확인을 위해 서비스 레포를 포그 떠서 개인 레포로 가져온 뒤, 버셀로 배포를 해서 버셀 배포본으로 서비스에 접근해보았다.

그러나 여전히 같은 에러 발생 ..!!! 🤬

🧐 에러 메시지로 다시 돌아가보자

Refused to apply style from '~~~.css' because its MIME type ('text/html') is not a supported stylesheet MIME type, and strict MIME checking is enabled.

메시지를 보면 어떤 파일을 못 찾고 있다고 하는데.. 이걸 자세히 보면! 번들 파일인 걸 알 수 있다

➡️ 에러 메시지에 찾을 수 없다고 나온 파일 명이 dist > asset > js, css 파일 명과 동일 ➡️ js 번들 파일 하나, css 번들 파일 하나 ➡️ 아..! 지금 번들 파일을 못 찾고 있는 것이구나 !! (깨달음)

💥 문제를 찾은 것만 같다 ..!

앞서 적은 것처럼 로컬에선 잘 동작하던 코드가 배포본에서만 제대로 동작하지 않는 이유에 대해 궁금했었는데, 번들러 관련 에러라면 설명이 가능했다 !

로컬에선 빌드를 하지 않기 때문에 오류가 발생하지 않았고, 배포 환경에선 빌드 후 번들링 과정을 수행하기 때문에 오류가 발생할 수 밖에 없던 것이다..!!

dist를 기준으로 배포를 하니까 번들 파일 경로는 dist를 root로 생각한다. 정상적인 하위 주소는 /asset/번들파일이 되고, 번들 파일 요청은 배포주소/asset/번들파일로 들어가야 정상적으로 파일을 찾을 수 있다.

👀 그렇다면 왜 특정 주소에서만 에러가 발생했을까 !?

우리의 배포 사이트 기준, 홈 화면에서는 위에서 말한 정상적인 주소(배포주소/asset/번들파일)로 접근하여 번들 파일을 잘 불러오고 있었다.

그러나 특정 주소로 넘어갔을 경우에는 'RequestURL: 배포주소 + 특정 주소/asset/번들파일'에 접근하여 번들 파일을 요청했다.

결국, 비정상적인 경로에서 번들 파일을 찾으려고 해서 에러가 발생했던 것 ..!!! 🌟🌟

🫵 이런 사단이 난 이유 !

➡️ vite.cofig.js의 base 필드를 주목하자 🌟

vite.cofig.js의 base 필드를 지정하면 상대 경로로 번들 위치를 잡게 되는데, 홈으로 접근했을 때는 서브주소가 없기 때문에 "배포주소 + /"를 루트로 보고 정상적인 번들러 위치에 접근한다.

하지만, 서브 주소로 리다이렉트 된 경우에는 "배포주소 + /서브 주소"를 루트로 보고 해당 주소를 기준으로 번들을 찾으려고 하기 때문에, 에러가 발생한 것이다.

😻 해결 방법

➡️ vite.cofig.js의 base 필드 자체를 지워버리기 !

base 필드를 지우면 무조건 루트 경로를 절대 경로로 생각하고 번들 위치를 잡기 때문에, 오류를 해결할 수 있다 !! (루트 경로를 절대 경로로 생각하고 번들 위치를 잡게 되면, 어떠한 서브 URL에 접근하더라도 항상 동일한 위치에 번들이 있음을 보장 가능 🌟🌟)

• 기존 REST API 한계점을 극복하기 위해 Meta(전 facebok)가 고안한 쿼리 언어

☑️ REST API와 차이점

▶️ Overfetching

• REST API

  • 일부 속성만 필요한 경우에도 전체 데이터를 불러온다.
  • 서비스 크기가 커질수록 다루는 양의 크기가 커질 경우 서버 부하, 데이터 전송 속도 및 크기 등 Overfetching으로 인한 이슈가 발생할 수 있다. (클라이언트 입장에서는 필요한 데이터만 골라서 사용하면 되긴 하지만)

• Graph QL

  • 필요한 필드만을 명시적으로 요청하여 필요한 정보들만 선택하여 받아올 수 있다.

      query {
          teams {
              id
              manager
              mascot
          }
      }

  • 전체 데이터를 받아오지 않고 필요에 따라 원하는 데이터만 받아오기 때문에, 데이터 전송량이 감소한다. 이로써 REST API에서 언급했던 Overfetching 이슈를 해결할 수 있다.

▶️ Underfetching

• REST API

  • 특정 데이터를 받아오기 위해 여러 개의 endpoint를 사용해야 한다. 하나의 데이터를 가져오기 위해 n개의 endpoint를 거치기도 한다. 이는 서버 부하, 네트워크 오버헤드 등을 유발할 수 있다.

• Graph QL

  • 중첩된 필드를통해 여러 객체와 관련된 데이터를 한 번에 요청할 수 있다. 이를 통해 하나의 endpoint에서 여러 계층의 정보들을 한 번에 받아올 수 있다.

      query {
          team(id: 2) {
              id
              manager
              mascot
              members {
                  first_name
                  last_name
              }
          }
    
          rolse {
              id
              requirement
          }
      }

  • 하나의 endpoint에서 모든 요청을 해결할 수 있기 때문에, 요청 횟수가 감소한다. 즉, 여러 번 네트워크를 호출할 필요가 없기 때문에 REST API의 Underfetching 이슈를 해결할 수 있다.

📌GraphQL 구조

☑️ 쿼리/ 뮤테이션(Query/ Mutation)

▶️ Query

: 정보를 읽어오기 위해 사용하는 메소드 - CRUD의 R

• 쿼리문 (요청): 원하는 정보를 쿼리로 요청

    query {
        user {
            name
        }
    }

• 응답: 쿼리문에 대한 응답이 데이터로 반환

    {
        "data" : {
            "user" : {
                "name" : "abcde"
            }
        }
    }
  

▶️ Mutation

: 받아온 정보를 변형하기 위해 사용하는 메서드 - CRUD의 CUD

• 요청 예시 - addMovie라는 뮤테이션에 새로운 영화 이름을 추가하는 예시

    mutation {
        addMovie(name:"Rocks"){
            name
        }
    }

▶️ Subscription

: 실시간으로 변경된 데이터를 가져오기 위한 요청 방식

웹 소켓을 통해 소켓 통신을 열어두고, 데이터 업데이트 시 알리는 방식으로 이뤄진다.

▶️ 스키마와 타입시스템

: GraphQL 타입 시스템과 데이터를 표현하는 방법

📌 Query에 대해 더 자세히 알아보자

☑️ Aliases

• 필드의 결과를 원하는 이름으로 변경할 수 있다. 중복된 필드를 다른 이름으로 받아올 때 사용할 수 있다.

☑️ Fragments

• 반복되는 필드의 집합을 하나의 요소로 정의하여 이를 재사용할 수 있다.
• 같은 필드를 순서대로 요청한다고 가정해보자. 필드를 최소 2번은 반복해야 하기 때문에, 중복되는 코드의 양이 늘어나고 쿼리가 복잡해진다. 이러한 경우 fragment를 사용하면 필드셋을 구성한 다음 필요한 쿼리에 포함시킬 수 있다.

• fragment는 복잡한 응용 프로그램 내에서 데이터 요구사항을 작은 단위로 분할하는데 사용된다.
• 특히, 청크가 다른 여러 UI 구성 요소를 하나의 초기 데이터 fetch로 통합해야 하는 경우 많이 사용한다.

☑️ Operation name

• Operation type: Query(읽기), Mutation(데이터를 변경하고 가져옴), Subscription(실시간으로 변경된 데이터를 가져옴)

• Operation name: 의미있고 명시적인 이름으로 하는 것이, 디버깅이나 서버측에서 로깅하는데 유용하다.

    # Operation type: query
    # Opertation name: HeroNameAndFriends
    query HeroNameAndFriends {
      hero {
        name
        friends {
          name
        }
      }
    }

📌  Instrospection

• API 명세서 대신 사용할 수 있는 GraphQL 기능
• 서버 자체에서 현재 서버에 정의된 스키마의 실시간 정보를 공유할 수 있다.
• 인트로스펙션용 쿼리가 따로 존재하며, 일반 gql문을 작성하듯이 작성하면 된다. 다만, 대부분 서버용 gql 라이브러리에는 쿼리용 IDE를 제공하기 때문에, 실제로는 스키마 인트로스펙션을 위해 ql 쿼리 문을 작성할 필요는 없다.

🔗 React.memo

• 함수 컴포넌트의 결과를 Memoization하는 메소드
  • Memoization
    • 비용이 많이 드는 함수 호출의 결과를 저장
    • 동일한 입력 발생 시, 재사용 → 성능 향상에 사용됨.
• props가 변경되지 않은 경우에만 재사용하는 고차 컴포넌트

// 최적화 전
function My(props) {
    return (
        <div>
            {props.data}
        </div>
    )
}
function App() {
    const [state, setState] = useState(0)
    return (
        <>
            <button onClick={()=> setState(0)}>Click</button>
            <My data={state} />
        </>
    )
}

• 버튼을 계속 누를 경우, state 값이 동일함에도 불구하고 My 컴포넌트는 계속해서 리렌더링 됨.
  • 만약 App과 My 컴포넌트 하위로 수천개의 컴포넌트들이 존재한다면 …? → 엄청난 성능이슈 발생 ; ;
• 리렌더링을 줄이기 위해 React.memo(My 컴포넌트를 memoization된 버전으로 리턴)를 활용해보자.

// React.memo()를 활용한 최적화 코드
function My(props) {
    return (
        <div>
            {props.data}
        </div>
    )
}

// React.memo() 활용
const MemoedMy = React.memo(My)
function App() {
    const [state, setState] = useState(0)
    return (
        <>
            <button onClick={()=> setState(0)}>Click</button>
            <MemeodMy data={state} />
        </>
    )
}

• 버튼을 연속적으로 클릭하더라도 My 컴포넌트는 한 번만 렌더링된 후, 다시 렌더링 ❌!
  • React.memo()가 props 값을 memoization한 후, 캐싱된 결과를 리턴하기 때문에 동일한 입력 값에 대해 My 컴포넌트를 실행하지 않음.

🔗 useMemo

• React에서 CPU 소모가 심한 함수들을 캐싱하기 위해 사용됨.
• 계산 비용이 많이 드는 작업에 유용함.

// 최적화 전
function App() {
    const [count, setCount] = useState(0)

    const expFunc = (count)=> {
        waitSync(3000);
        return count * 90;
    }
    const resCount = expFunc(count)
    return (
        <>
            Count: {resCount}
            <input type="text" onChange={(e)=> setCount(e.target.value)} placeholder="Set Count" />
        </>
    )
}

• 어떠한 입력값이 들어올 때마다 컴포넌트가 다시 렌더링되어 expFunc이 호출됨.
  • 대규모 성능 병목 현상 유발
    • 병목 현상: 전체 시스템의 성능이나 용량이 하나의 구성요소로 인해 제한받는 현상

// useMemo()를 활용한 최적화 코드
function App() {
    const [count, setCount] = useState(0)

    const expFunc = (count)=> {
        waitSync(3000);
        return count * 90;
    }

    // useMemo() 활용
    const resCount = useMemo(()=> {
        return expFunc(count)
    }, [count])
    return (
        <>
            Count: {resCount}
            <input type="text" onChange={(e)=> setCount(e.target.value)} placeholder="Set Count" />
        </>
    )
}

• expFunc은 입력값 캐싱
  • 동일한 입력 발생 시, useMemo는 expFunc를 호출하지 않고 입력된 값에 대해 캐싱된 결과 값을 리턴함!

🔗 useCallback

• useMemo와 비슷하지만, 함수 선언 자체를 memoization하는데 사용된다는 차이가 있음.

function App() {
    const check = 90
    const [count, setCount] = useState(0)

    // useCallback() 활용
    const clickHndlr = useCallback(()=> { setCount(check) }, [check]);
    return (
        <>
            <button onClick={()=> setCount(count + 1)}>Set Count</button>
            <TestComp func={clickHndlr} />
        </>
    )
}

• clickHndlr는 dependenccy인 check의 값이 변하지 않는 한, App 컴포넌트가 리렌더링 되어도 새로 생성되지 않음.
  • 즉, setCount 버튼을 반복해서 클릭하더라도 TestComp는 리렌더링 되지 않음.
• useCallbacck이 check 값을 확인
  • 이전 값과 다른 경우: 새로운 함수를 리턴 + 새로운 참조가 되었으므로 리렌더링됨.
  • 이전 값과 동일한 경우: 아무 것도 리턴 ❌ + 함수 참조가 이전과 같다고 판단하여 리렌더링 ❌

🧶 React 내장 성능 기능 활용

🔗 Lazy Loading

• 부하를 단축하기 위해 자주 사용되는 최적화 기법

• React에서는 컴포넌트의 Lazy Lodading을 위해 React.lazy()를 사용함.

  • React.lazy()
    • React v16.6에 새로 추가된 기능으로, React.lazy()를 사용하면 동적 import를 사용하여 컴포넌트를 렌더링 할 수 있음.
    • 즉, React.lazy()를 사용하면 동적 가져오기를 통해 구성 요소 수준에서 React 애플리케이션을 쉽게 코드 분할할 수 있음.

• 사용하는 이유!

  • 일반적으로 규모가 큰 React 애플리케이션은 많은 요소, 라이브러리 등으로 구성됨.

  • 애플리케이션의 다른 부분을 로드하려고 노력하지 않을 경우, 사용자가 첫 페이지를 로드하는 즉시 대규모 단일 Javascript 번들이 사용자에게 전송됨 → 페이지 성능에 상당한 영향을 미침.

  • React.lazy()를 통해 손쉽게 개별 Javascript 청크로 분리해보자!

    
    

1. `React.lazy()`

    ```jsx
    const About = React.lazy(() => import('./About'));
    ```

    - import() 구문을 반환하는 콜백 함수를 인자로 받음.
    - 동적으로 불러오는 컴포넌트 파일은 두 가지 규칙을 지켜야 함!
        - React 컴포넌트를 포함해야 함.
        - default export를 가진 컴포넌트여야 함.

 2. `<Suspense />`

```jsx
<Suspense fallback={<div>Loading...</div>}>
  <Routes>
    <Route path="/" element=<About/>} />
  </Routes>
</Suspense>
```

- 컴포넌트가 로드될 때까지 fallback() props에 있는 React 엘리먼트를 띄워줌.
- 비동기 데이터 가져오기와 코드 분할을 더 간단하게 처리하고, 사용자 경험을 개선하기 위한 목적으로 도입된 기능
- React v16.6 이상부터 사용 가능
- 사용 목적
    - `비동기 데이터 가져오기`
    Suspense 사용 시, 컴포넌트에서 비동기 작업을 수행하거나 외부 데이터를 가져오는 동안 화면에 로딩 상태를 표시하여 사용자 경험을 향상시킬 수 있음.
    - `코드 분할`

        Suspense를 사용하면 코드 분할과 함께 앱 번들의 크기를 줄이고 초기 로딩시간을 최적화할 수 있음. 필요한 컴포넌트만 로드하고 사용자가 해당 컴포넌트를 요청할 때까지 다른 컴포넌트를 로드하지 않도록 해야 함.

3. `React Router와 함께 사용`

```jsx
return (
   <Router>
    <Suspense fallback={<div>Loading...</div>}>
      <Routes>
        <Route path="/" element=<About/>} />
      </Routes>
    </Suspense>
  </Router>
);
```

- React 공식문서에 따르면,  Router 바로 아래 Suspense를 위치시키고 React.lazy()는Route로 보여줄 컴포넌트를 불러오는 것을 권장하고 있음.

🧶 이외에도 ..!

🔗 List 가상화

• React 공식문서를 참고하면, 애플리케이션에서 거대한 List(수백 또는 수천 행)를 렌더링하는 경우 windowing이라는 기법을 사용하는 것을 추천한다고 함.
  • windowing
    • 거대한 List 렌더링 시, 브라우저의 viewport에 보여지는 부분만 렌더링하고 나머지는 스크롤할 때 보여지도록 하는 기법
    • 이를 활용하면 컴포넌트를 리렌더링하는데 걸리는 시간과 생성된 DOM 노드의 수를 크게 줄일 수 있음.
    • 대표적인 windowing 라이브러리: react-window, react-virtualized

🔗 불변성의 중요성

• 불변성을 지킬 수 있는 가장 간단한 방법은 props와 state로 사용 중인 값을 변경하지 않는 것

• concat, spread 문법(shallow copy) 등 활용하기

  • concat()

      handleClick() {
        this.setState(state => ({
          words: state.words.concat(['marklar'])
        }));
      }

  • spread syntax

      handleClick() {
        this.setState(state => ({
          words: [...state.words, 'marklar'],
        }));
      };

  • Object.assign(), object spread properties

      // 불변성을 지키지 않은 코드
      function updateColorMap(colormap) {
        colormap.right = 'blue';
      }

    • 이런 코드를 작성하고 싶다면, 위와 같이 객체 원본을 변경시키지 말고 Object.assign()이나 object spread properties를 활용해보자 !

      // Object.assign() 활용 코드
      function updateColorMap(colormap) {
      return Object.assign({}, colormap, {right: 'blue'});
      }

      // object spread properties 활용 코드
      function updateColorMap(colormap) {
      return {...colormap, right: 'blue'};
      }

• 깊게 중첩된 객체를 처리할 때, 불변성을 지키는 방식(얕은 복사)으로 객체를 업데이트하다 보면 굉장히 복잡하고 헷갈린다고 느낄 수 있음.

• 이런 경우, immer를 활용하면 불변성이 가져다주는 이득을 잃지 않고 가독성있는 코드를 작성할 수 있음.

  • immer: 상태를 업데이트할 때, 불변성을 관리해주는 라이브러리

🧶 마무리

• 앞서 정리한 방법 외에도 다양한 최적화 방법이 있음.
• 기능구현 단계에서부터 최적화를 미리 수행하기 보다, 프로젝트를 모두 개발한 후 필요한 곳에 최적화를 적용시키는 것이 중요함 !

• 데이터 fetching, 캐싱, 동기화 , 데이터 업데이트를 보다 쉽게 다룰 수 있도록 하는 상태관리 라이브러리
• Redux나 MobX와 같은 라이브러이에 비해 러닝커브가 상당히 낮고 보일러플레이트가 적어 편하게 사용 가능함.
• react-query를 사용함으로써 클라이언트와 서버 데이터를 명확히 분리할 수 있음.

🪵 react-query 왜 사용할까?

1. 간편한 데이터 관리

   • react 애플리케이션에서 서버의 상태를 불러오고, 캐싱하고, 지속적으로 동기화 및 업데이트를 간편하게 처리할 수 있도록 도와줌.

2. 간단하고 직관적으로 API 사용 가능

   • 복잡하고 장황한 코드가 필요한 다른 데이터 패칭 방식과 달리, react component 내부에서 간단하고 직관적으로 API를 사용할 수 있음.

3. 핵심로직 에 집중 가능

   • Redux에는 기본 원칙이 존재하기 때문에, 이 원칙을 충족하기 위해 장황한 양의 보일러플레이트 코드가 요구됨.

     • 간단한 로직을 짜는데도 갖춰야 할 코드의 양이 너무 많아 핵심 로직에 집중하기 힘듦.

       (실제로 보면 그 양이 정말… 어마무시 …)

   • 캐싱, Window Focus Refetching 등 다양한 기능을 제공함.

     • 이를 활용하여 API 요청과 관련된 번잡한 작업없이 핵심로직 자체에 집중할 수 있음.

🪵 react-query 알아보기

1️⃣ 간단한 코드로 비교해보기

🌱 react-query를 사용하지 않은 기존 데이터 패칭 코드

• 하나의 데이터를 패칭할 뿐인데 꽤 많은 양의 코드를 작성해야 함.
• useEffect를 사용하기 때문에, 이로 인해 side effect 발생 → 코드 흐름 파악이 어려워질 수 있음.

// 1. 데이터 패칭 코드 작성
const getNikaData = async () => {
  const data = await fetch("https://musma.net/user/nika")
        .then((response) => response.json());
  return data;
};

// 2. 데이터를 담을 상태 생성
const [nika, setNika] = useState();

// 3. useEffecct를 이용하여 컴포넌트 마운트 시, 데이터 패칭 후 상태 저장
useEffect(() => {
    getNikaData()
      .then((res) => setState(res))
      .catch((err) => {
                console.log(err.response.data)
            });
  }, []);

🌱 react-query를 사용한 코드

• 라이브러리를 사용하기 전보다 훨씬 코드의 양이 적어짐.
  • 여기서 데이터 패칭 로직까지 분리하게 된다면, 컴포넌트에 포함된 코드의 양은 더 적어지게 됨.
• useEffect를 사용하지 않으면서 코드 흐름을 파악하기 비교적 쉬워짐.

// 1. 데이터 패칭 코드 작성
const getNikaData = async () => {
  const data = await fetch("https://musma.net/user/nika")
        .then((response) => response.json());
  return data;
};

// 데이터 패칭 및 상태 저장
const { data } = useQuery(["nika"], getNikaData);

2️⃣ Query & Mutation

• react-query는 API 요청을 Query와 Mutation으로 처리함.

🌱 Query - useQuery

• query 요청은 useQuery 훅으로 진행됨.
• query 함수를 사용해서 데이터를 가져오고 캐싱할 수 있음.
  • query 함수는 대부분 데이터 패칭용으로 사용되며, GET으로 받아올 때 주로 useQuery 사용.
• HTTP Method GET 요청과 같이 서버에 저장되어 있는 상태 를 불러와 사용할 때 용이
• useQuery는 비동기로 작동함.
  • 하나의 컴포넌트에 여러 개의 useQuery 존재 → 두 개의 useQuery가 동시에 실행 !
    • 하나가 끝날 때까지 기다렸다가 다음 useQuery가 실행되는 것 ❌!!
  • enabled 옵션을 사용할 경우, 동기적으로 사용 가능
    • useQuery에 3번째 인자로 enabled 옵션을 넣어줄 경우, enabled 값이 true일 때 해당 useQuery를 실행 → 동기적으로 함수 실행 가능

// 가장 기본적인 형태의 React Query useQuery Hook 사용 예시
const { data } = useQuery(
  queryKey, // 이 Query 요청에 대한 응답 데이터를 캐시할 때 사용할 Unique Key (required)
  fetchFn, // 이 Query 요청을 수행하기 위한 Promise를 Return 하는 함수 (required)
  options, // useQuery에서 사용되는 Option 객체 (optional)
);

• 요청마다 구분되는 Unique Key 를 반드시 필요로 함.
• Unique Key로 api response를 로컬에 캐시하고 관리함.

function Users() {
  const user = useQuery(
    ['userInfo'], // 'userInfo'를 Key로 사용하여 데이터 캐싱
    // 다른 컴포넌트에서 'userInfo'를 QueryKey로 사용한 useQuery Hook이 있다면 캐시된 데이터를 우선 사용
    () => axios.get('/users').then(({ data }) => data),
  );

  if (user.isLoading) return <div> 로딩중... </div>;
  // 이렇게 해두면, n번의 로딩 반복 → 에러 상태로 변함
  // 에러 상태로 변하기 전, 로딩이 반복될 때 isError를 찍어보면 false로 나옴.
  if (user.isError) return <div> 에러: {user.error.message} </div>;

  return (
    <div>
      {' '}
      {data?.map(({ id, name }) => (
        <span key={id}> {name} </span>
      ))}{' '}
    </div>
  );
}

function UserInfo({ userId }) {
  const userDetail = useQuery(
    // 'userInfo', userId를 Key로 사용하여 데이터 캐싱
    ['userInfo', userId],
    () => axios.get(`/users/${userId}`)
  );

  if (userDetail.isLoading) return <div> 로딩중... </div>;
  if (userDetail.isError) return <div> 에러: {userDetail.error.message} </div>;
  return <div> {...} </div>;
}

🌱 Mutation - useMutation

• mutation 요청은 useMutation 훅으로 진행됨.
• 서버에 side effect를 발생시켜 서버 상태를 변경시킬 때 사용
  • HTTP Method POST, PUT, DELETE 등에 활용
  • 즉, 값을 바꿀 때 사용하는 훅 !

// 가장 기본적인 형태의 React Query useMutation Hook 사용 예시
const { mutate } = useMutation(
  mutationFn, // 해당 Mutation 요청을 수행하기 위해 Promise를 반환하는 함수 (required)
  options, // useMutation에서 사용되는 Option 객체 (optional)
);

• useMutation의 첫 번째 파라미터는 useMutation의 return 값 중 mutate(또는 mutateAsync) 함수를 호출하여 서버에 side effect 발생시킬 수 있음.
  • useMutation의 첫 번째 파라미터: Mutation 요청을 수행하기 위한 Promise를 반환하는 함수

function NotificationSwitch({ value }) {
  // mutate 함수를 호출하여 mutationFn 실행
  const { mutate, isLoading } = useMutation(
    (value) => axios.post(URL, { value }), // mutationFn
  );

  return (
    <Switch
      checked={value}
      disabled={isLoading}
      onChange={(checked) => {
        // mutationFn의 파라미터 'value'로 checked 값 전달
        mutate(checked);
      }}
    />
  );
}

🪵 recoil에 대해 가볍게 알아보기

1️⃣ recoil

• react에 최적화된 전역상태 관리 라이브러리

2️⃣ atom

• 하나의 상태로, 컴포넌트가 구독할 수 있는 react state

• atom 변경 시, 이를 구독하고 있는 컴포넌트들이 모두 다시 렌더링됨.

• atom 생성을 위해서는 어플리케이션의 고유한 키, 디폴트 값을 설정해야 함.

    import { atom } from "recoil";
  
    export const aroomingInfo = atom({
      key: "aroomingInfo",
      default: '',
    });

3️⃣ selector

• 여러 상태(atom)를 조합한 새로운 상태

  • get, set 메소드 사용 가능
  • 즉, 다른 atom에 의존하는 동적인 데이터를 만들 수 있게 해줌!

• recoil의 selector 사용 시, 동일한 API 요청에 대해 값 캐싱 가능 → 불필요한 API 요청을 줄일 수 있음!

    // selector 생성
    import { selector } from "recoil";
    import { aroomingInfo } from "../atom/AroomingInfo";
  
    export const aroomingMessage = selector({
      key: "aroomingMessage/get",
    // ✨ 메세지 목록만 가져오기
      get: ({ get }) => {
        return get(aroomingInfo).messageList;
      },
    // ✨ 메세지 목록 업데이트
      set: ({ get, set }, newMessage) => {
        const newAroomingInfo = {
          ...get(aroomingInfo),
          messageList: [...get(aroomingInfo).messageList, newMessage],
        };
        set(aroomingInfo, newAroomingInfo);
      },
    });

    // selector를 컴포넌트에서 활용하는 코드
    import { aroomingeMessage } from "../selector/AroomingInfo";
    import { useRecoilState } from "recoil";
    import styled from "styled-components";
    import { useRef } from "react";
  
    const AtomArooming = () => {
      const [aroomingInfo, setAroomingInfo] = useRecoilState(aroomingMessage);
      const inputRef = useRef();
  
      return (
        <>
          <St.MessageWrapper>
            // ✅ 메세지 보여주기
            {aroomingInfo.map((message) => (
              <div key={message}>{message}</div>
            ))}
          </St.MessageWrapper>
          <St.InputWrapper>
            <input type="text" ref={inputRef} />
            // ✅ 메세지 추가 
            <button onClick={() => setAroomingInfo(inputRef.current.value)}>
              메세지 추가
            </button>
          </St.InputWrapper>
        </>
      );
    };
  
    export default AtomArooming;

4️⃣ selectorFamily (options)

• 매개변수를 넘겨주면서 selector를 사용하고 싶을 때 사용

    export const aroomingSelecteMessage = selectorFamily({
      key: "aroomingSelecteMessage/get",
      get:
        (selectIdx) =>
        ({ get }) => {
          return get(aroomignInfo).messageList.filter(
            (_, idx) => idx === selectIdx
          )[0];
        },
    });
  
  

const aroomingLastMessage = useRecoilValue(aroomingSelecteMessage(1));
```

🪵 asynchronous recoil

• 아까 위에서 정의한 selector 함수를 그대로 가져와보자.
• 똑같은 코드에 단순히 async만 붙여주면 비동기로 사용할 수 있다 !
• 단, selector는 비동기 set을 지원하지 않는다 !
  • 만약 비동기로 데이터를 가져와서 그 값을 기준으로 값을 세팅해야 하는 경우에는?!
    → custom hook을 활용할 수 있음. (중간에 custom hook을 배치하여 hook 내부에 비동기 작업을 수행하고 그 값을 set 함수에 넘기는 방법)

```jsx
// 기존의 selector 코드에 async-await 추가
import { selector } from "recoil";
import { aroomingInfo } from "../atom/AroomingInfo";

export const aroomingMessage = selector({
  key: "aroomingMessage/get",
// ✨ async-await 추가
  get: async({ get }) => {
    return await get(aroomingInfo).messageList;
  },
  set: ({ get, set }, newMessage) => {
    const newAroomingInfo = {
      ...get(aroomingInfo),
      messageList: [...get(aroomingInfo).messageList, newMessage],
    };
    set(aroomingInfo, newAroomingInfo);
  },
});
```

• 이때 비동기 recoil state를 사용하게 되면 Suspense를 사용하라는 오류를 볼 수 있음.

1️⃣ Suspense

• 컴포넌트가 읽어 들이고 있는 데이터가 아직 준비되지 않았다고 React에 알려주는 일종의 메커니즘

• 데이터 호출 로직에서 호출 완료 여부 인지 → 데이터 불러오기를 완료할 때까지 fallback 속성 값으로 넣어준 컴포넌트를 표시해줌.

  • 아래 코드처럼 fallback 함수로 Loading 문구를 반환하게 해줬다면, 데이터가 불러와지기 전까지 Loading…을 띄워줌!

    // App.tsx
    function App() {
    return (
      <RecoilRoot>
        {/* 여기 */}
        <React.Suspense fallback={<div>Loading...</div>}>
          <CurrentUserInfo />
        </React.Suspense>
      </RecoilRoot>
    );
    }

2️⃣ Error Handling (에러 처리)

• Recoil selector가 발생할 에러에 대해 던져주면 React 로 잡을 수 있음.

// App.tsx
function App() {
  return (
    <RecoilRoot>
      {/* 여기 */}
      <ErrorBoundary>
        <React.Suspense fallback={<div>Loading...</div>}>
          <CurrentUserInfo />
        </React.Suspense>
      </ErrorBoundary>
    </RecoilRoot>
  );
}

3️⃣ recoil과 선언적 프로그래밍

• recoil을 통해 비동기 데이터를 처리하는 방식은 recoil 없이 사용했던 방식과 차이가 있음.

🌱 기존 코드

• loading일 때는 <Spinner />를, error 발생 시에는 <ErrorMessage />를, 그게 아니라면 <DataView />를 보여주는 …! UI를 어떻게 보여줄지에 집중한 명령형 프로그래밍 방식으로 처리

// 기본 App.tsx
function App() {
    const {loading, data, error} = useSelector(somethingSelector);

if (loading) {
    return <Spinner/>
}

if (error) {
    return <ErrorMessage error={error}/>
}

return <DataView data={data}/>;
}

🌱 recoil 활용 코드

• <Suspense />와 <ErrorBoundary />를 사용하여 무엇 보여줄지에 집중한 선언형 프로그래밍 방식으로 처리

function App() {
    const data = useRecoilValue(somethingSelector)
  return (
      <ErrorBoundary FallbackComponent={ErrorMessage}>
        <Suspense fallback={Spinner}>
           <DataView data={data}/>
        </Suspense>
      </ErrorBoundary>
  );
}

• 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방식.

컴퓨터공학에서의 로드 밸런싱

• 부하분산 또는 로드 밸런싱(Load balancing)은 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋 이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것을 의미한다. 이로써 가용성 및 답 시간을 최적화시킬 수 있다.

👀 서버 부하 분산(Server Load Balancing)

• 외부의 사용자로부터 들어오는 다수의 요청을 서버들에 적절히 배분하여 각각의 서버들이 요청을 처리하게 하는 것.
• 즉, 서버가 처리해야 할 업무 혹은 요청(load)을 여러 대의 서버로 나눠(balancing) 처리하는 것을 의미함.
• 한 대의 서버로 부하가 집중되지 않도록 트래픽 관리 → 각각의 서버가 최적의 성능을 내게 하는 목적 !

Load Balancer: cloud 상에서 서버 부하 분산을 담당하는 Network Switch를 부르는 말. LB, Load Balancing: 현업에서 서버 부하 분산을 칭하는 말.

👀 서버 부하 분산 방법(Load Balancing Method)

: 서버의 능력을 고려하여 분배해야 서버가 죽지 않기 때문에, 서버의 상황에 맞춰 적절한 방법을 선택해야 함.

🥽 Round Robin

• 로드 밸런서가 다수의 서버에게 순서대로 요청을 할당하는 방법.
• 가장 단순한 방법으로, 서버군에 차례대로 요청을 할당하여 분산함.

🥽 Least Connection

• 로드 밸런서가 서버에게 요청을 전달한 뒤, 사용자와 서버가 정상적인 연결을 맺으면 connection 생성
• 로드 밸런서 또한 중간자로서 connection 정보를 갖고 있음
• connection 수 정보를 기반으로 서버에게 요청 전달.
• 이때, connection이 가장 적은 서버 === 부하가 가장 덜한 서버를 의미, 부하가 가장 덜한 서버에 요청을 전달함 !

🥽 Ratio(가중치)

• 서버의 처리 능력을 고려하여 할당 가능한 connection 비율을 미리 정해둠.
• 서버 부하 분산 비율이 100%라고 가정했을 때, 성능이 가장 떨어지는 서버에게 10%를 나머지 서버에게 각각 30%를 할당함.

🥽 Fastest(Response Time)

• 응답속도가 가장 빠른 서버에게 우선적으로 할당하는 방식.
  • 서버에 할당된 connection이 5개, 서버의 response도 5개인 경우
    • connection에 대해 모두 응답 → 성능이 충분하다고 판단 → 서버에 추가 요청 보냄.
  • 서버에 할당된 connection이 10개, 서버의 response는 5개인 경우
    • 현재 성능이 충분하지 않아 제대로 답변하지 못한다고 판단 → 서버에 추가 요청 보내지 않음.

• Hyper Text Transfer Protocol

• 서버/ 클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜

• 인터넷에서 하이퍼텍스트를 교환하기 위한 통신규약, 80번 포트 사용

  하이퍼텍스트(Hypertext): 참조(하이퍼링크)를 통해 독자가 한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트

• HTTP 서버 → 80번 포트에서 요청 기다림 → 클라이언트 → 80번 포트로 요청 보냄.

📐 HTTP 구조

• HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동함.
• 상태를 가지고 있지 않는 stateless 프로토콜
• Method, Path, Version, Headers, Body 등으로 구성
• 암호화되지 않은 평문 데이터를 전송하는 프로토콜이기 때문에, HTTP로 비밀번호나 주민등록번호 등을 주고 받을 시, 제 3자가 정보 조회를 할 수 있었음 → 보안 취약성
  • 이를 개선하기 위해 등장한게 HTTPS !

📌 HTTPS

• Hyper Text Transfer Protocol **Secure**
• HTTP + 데이터 암호화 → HTTP 요청 및 응답을 SSL/ TLS 기술에 결합함.
• 443번 포트 사용
• 네트워크 상에서 중간에 제 3자가 정보를 조회할 수 없도록 암호화 지원

📐 HTTPS 동작 방식

1. 사용자 브라우저의 주소 표시줄에 https:// URL 형식을 입력하여 HTTPS 웹 사이트를 방문.
2. 브라우저: 서버의 SSL 인증서를 요청 → 사이트의 신뢰성을 검증하려고 시도.
3. 서버: 공개 키가 포함된 SSL 인증서를 회신으로 전송.
4. 웹 사이트의 SSL 인증서 → 서버 아이덴티티 증명.
   • 브라우저에서 인증 성공 시, 브라우저: 퍼블릭 키를 사용 → 비밀 세션 키가 포함된 메시지를 암호화 → 전송.
5. 웹 서버: 개인 키를 사용 → 메시지를 해독, 세션 키를 검색 → 암호화 → 브라우저에 승인 메시지 전송.
6. 브라우저와 웹 서버 모두 동일한 세션 키를 사용 → 메시지를 안전하게 교환하도록 전환.

🙋‍♀️ HTTP/2, HTTP/3, HTTPS의 차이점

• HTTP/1.1: 출시된 최초의 HTTP 버전
• HTTP/2, HTTP/3: 프로토콜 자체를 업데이트한 버전
  • 데이터 전송 시스템 수정 → 효율성 개선

🔍 HTTP/2

• 텍스트 형식 대신, 바이너리로 데이터 교환

  바이너리(Binary):1과 0만을 사용하여 수를 나타내는 진법(2진법)/ 컴퓨터 언어

• 서버가 새 HTTP 요청을 기다리는 대신, 클라이언트 캐시에 응답을 사전에 전송 가능

🔍 HTTP/3

• 비교적 최신에 나온 버전
• HTTP/2를 한 단계 더 발전시킨 버전
• 실시간 스트리밍 및 기타 최신 데이터 전송 요구 사항을 보다 효율적으로 지원하는 것을 목표로 함.

🔍 HTTPS

• HTTP의 보안 문제를 우선시 함.
• 최신 시스템에서는 SSL/ TLS 와 함께 HTTP/2를 HTTPS로 사용.
• HTTP/3이 발전하면 브라우저 및 서버 기술도 HTTPS에 통합될 예정.

🙋‍♀️ HTTP보다 HTTPS를 선택하는 이유

🔍 보안

• HTTP 메시지는 일반 텍스트이기 때문에 권한이 없는 당사자가 인터넷을 통해 쉽게 엑세스하고 읽을 수 있음.
• HTTPS는 모든 데이터를 암호화된 데이터 형태로 전송함.
  • 사용자의 민감한 데이터를 제 3자가 네트워크를 통해 가로챌 수 없음.
  • 신용카드 세부정보, 고객 개인 정보 등 잠재적으로 민감한 정보를 보호하려면 HTTPS를 선택하는 것이 좋음.

🔍 인증

• HTTP의 신뢰성이 더 낮기 때문에, 검색 엔진은 HTTPS 웹 페이지보다 웹 사이트 컨텐츠 순위를 낮게 지정함.
• 브라우저는 주소 표시줄에서 웹 사이트 URL 옆에 있는 자물쇠 아이콘 배치 → 사용자에게 HTTPS 연결을 표시
  • 추가 보안 및 신뢰 요소 때문에 사용자 역시 HTTPS 웹 사이트 및 애플리케이션을 선호 !

🔍 성능 및 분석

• HTTPS 웹 애플리케이션은 HTTP 애플리케이션보다 로드 속도가 더 빠름.

• HTTPS는 참조 링크 역시 더 잘 추적함.

• 따라서, 분석 소프트웨어가 신뢰할 수 있는 트래픽 소스를 정확하게 식별하게 하려면 HTTPS를 활성화하는 것이 좋음 !

  트래픽 소스(Traffic Source)

  • 웹 사이트나 애플리케이션에 방문하는 사용자가 어떤 경로나 출처로부터 왔는지 나타내는 정보
  • 웹 분석에서 중요한 역할을 함.
  • 트래픽 소스 분석 시, 웹 사이트/ 애플리케이션의 성과를 이해하고 개선하기 위한 인사이트를 얻을 수 있음.

🧩 결론

• 전송 계층 보안으로, 인터넷 상의 커뮤니케이션을 위한 개인 정보와 데이터 보안을 용이하게 하기 위해 설계된 보안 프로토콜
• 네트워크 상에서 보안을 제공하는 암호화 프로토콜을 사용해 네트워크에 보안을 제공함으로써, 개인정보 보호를 보장하는 클라이언트/ 서버 프로토콜
• 전송 중인 정보를 보호함으로써 안전하지 않은 인프라를 통해 통신을 보호함.
  • 웹 사이트를 로드하는 웹 브라우저와 같이 웹 응용 프로그램과 서버 간의 커뮤니케이션을 암호화에 사용됨.
  • 이메일, 메시지, 보이스오버 IP(VoIP) 등 다른 커뮤니케이션을 암호화하기 위해 사용
• TLS 버전 1.3은 최근에 활발히 사용되는 암호화 프로토콜 버전으로, 이제는 사용하지 않는 SSL 버전 3.0 프로토콜보다 향상된 보안 기능과 성능을 다수 제공함.

🌟 TLS 프로토콜 역할

• TLS 프로토콜은 주로 암호화, 인증, 무결성이라는 세 가지 역할을 수행함.
  • 암호화: 제 3자로부터 전송되는 데이터를 숨김.
  • 인증: 정보를 교환하는 당사자가 요청된 당사자임을 보장함.
  • 무결성: 데이터가 위조되거나 변조되지 않았는지 확인함.
• 서버와 클라이언트가 TLS로 통신을 할 때, 어떠한 제 3자도 메시지를 변형하거나 감청할 수 없도록 함.

💻 SSL (Secure Sockets Layer)

• 클라이언트와 서버 간의 안전한 링크를 통해 송수신되는 모든 데이터를 안전하게 보장하는 과거의 보안 표준 기술이었음.
• 보안 취약점으로 인해 현재는 사용하지 않는 암호화 프로토콜

🌟 SSL 프로토콜 역할

• SSL이 적용되지 않은 통신의 경우, 평문(plain-text)이 그대로 전송됨.
  • 만약 제 3자가 통신 패킷을 탈취할 경우, 그 내용을 쉽게 확인할 수 있음.
• SSL을 적용한다면 요청을 암호화해서 보내기 때문에, 통신 패킷이 탈취되어도 복호화 키가 없으면 원래 내용을 알 수 없게되어 평문이 노출되는 문제를 기술적으로 해결 가능함.

💻 TLS/SSL HandShake

handshake: 클라이언트와 서버 간의 요청/ 응답을 반복하며 통신에 필요한 사전 작업을 하는게 마치 악수 같아 이러한 용어가 붙여졌다고 한다.

HTTPS에서 클라이언트와 서버 간 통신 전, SSL 인증서로 신뢰성 여부를 판단하기 위해 연결하는 방식

1. ClientHello 요청

   • 클라이언트가 특정 주소에 접근하면, 해당하는 서버에 요청을 보냄.
     • ex. NAVER에 접근 시, 네이버 서버에 요청 전송
   • 클라이언트의 주요 정보를 서버에 전송.
     • 난수 데이터
     • 암호화 프로토콜 정보
     • 클라이언트가 사용 가능한 암호화 기법
     • 세션 ID
     • 기타 확장 정보
   • 해당 클라이언트를 식별, 어떤 암호화를 사용할 수 있는지 등의 정보를 서버가 인지하도록 함.

2. ServerHello 응답

   • 서버가 ClientHello 요청을 받으면, 아래의 정보를 담아 클라이언트에게 응답을 보냄.
     • 난수 데이터(ClientHello의 난수 데이터와 다름)
     • 서버가 사용할 암호화 기법
     • 인증서
       • CA, 도메인, 공개 키
   • 클라이언트에서 사용 가능한 암호화 기법 중 서버에서 활용할 암호화 기법을 전달하여 동일한 암호화 기법으로 송수신할 수 있도록 선언.
   • 인증서 정보와 함께, 서버와의 암호화 통신을 위한 서버 공개키가 전달됨.
   • 서버의 공개키로 데이터를 암호화 → 서버는 개인 키로 복호화 → 요청 분석

3. 인증서 검토

   • 서버가 전달한 인증서가 실제 해당 서버의 인증서인지, 신뢰할 수 있는 CA에서 발급된 것인지, 실제 해당 CA에서 발급받았는지 등 인증서 검토
     • 인증서에 이상이 없다면, 연결이 안전하다는 창을 볼 수 있음.
     • 인증서에 문제가 있다면, 비공개 연결이 아닙니다. 와 같은 경고문을 볼 수 있음.
       • 이는 브라우저가 사용자에게 보내는 경고문으로, 해당 사이트의 인증서가 올바르지 않음을 의미.

4. Premaster Secret 송수신

   • ClientHello, ServerHello에서 송수신한 난수 데이터를 조합하여 Premaster Secret 생성.
   • Premaster Secret을 ServerHello에서 전달받았던 공개 키로 암호화.
   • 해당 데이터는 서버가 가진 개인 키로만 복호화 가능 → 데이터 탈취 시에도 내용 보호 가능.
   • 서버: 수신된 데이터 복호화 → 클라이언트와 동일한 Premaster Secret 저장 가능.

5. 통신 키 생성

   • 보유한 Premaster Secret을 기반으로 Master Secret, Session Key 생성.
   • 이를 통해, 클라이언트와 서버가 동일한 키를 보유하게됨.
   • 클-서 암호화 통신 가능.

6. 데이터 송수신

   • 저장된 Session Key를 통한 대칭 키 암호화 방식으로 암/복호화하여 통신.

7. 세션 종료

   • 클라이언트와의 연결이 끝났을 경우, Session Key 폐기.

• 암호화와 복호화에 같은 암호 키(대칭 키)를 사용하는 알고리즘
• 해당 키를 아는 사람만 문서를 복호화할 수 있음.
• Session Key, Secret Key, Shared Key, 대칭키, 단용키라고도 함
• 대표적인 알고리즘: DES, 3DES, AES, SEED, ARIA, 최근 주목받고 있는 암호인 ChaCha20
• 장점: 기밀성 제공, 공개 키 암호화 방식에 비해 속도가 빠름.
• 단점: 무결성/ 인증/ 부인방지를 보장하지 않음.
  • 부인방지: 메시지의 송수신이나 교환 후, 또는 통신이나 처리가 실행된 후에 그 사실을 사후에 증명함으로써 사실 부인을 방지하는 보안기술
  • 키 교환 중 탈취 문제 발생 가능성
  • 사람마다 키 교환을 따로 해야하기 때문에, 사람의 수 증가 → 관리해야 할 키의 수가 방대해짐

🔐 대칭 키 암호

• 하나의 비밀키를 client와 server가 함께 사용
• 암호화 키 === 복호화 키
• 공개 키와 비밀 키를 별도로 가지는 것에 비하면 계산 속도가 빠름.
• 비밀 키 하나만 알아내면 암호화된 내용을 해독 가능 → 해커로부터 안전하지 않음.
• 대칭 키 암호는 암호화하는 단위에 따라 스트림 암호와 블록 암호로 나눌 수 있음.
  • 스트림 암호: 연속적인 비트/ 바이트를 계속해서 입력받아서, 그에 대응하는 암호화 비트/ 바이트를 생성하는 방식.
  • 블록 암호: 정해진 한 단위(블록)을 입력받아 그에 대응하는 암호화 블록을 생성하는 방식

🔑 공개 키(Public Key)/ 비대칭 키(Asymmetric Key)

• 암호화와 복호화에 사용하는 암호키를 분리한 알고리즘

• 대칭키의 키 교환 문제를 해결하기 위해 등장

  • 키가 공개되어 있기 때문에, 키 교환 필요성이 사라짐.
  • 대칭키의 경우, 송수신자의 키를 알아야하기 때문에 분배가 어렵고 복잡하지만, 공개 키와 비밀 키로 분리할 경우 남들이 알아도 되는 공개 키만 공개하면 됨.

• 대표적인 알고리즘: Diffie Hellman, RSA, DSA, ECC

  • Diffie Hellman : 최초의 공개키 알고리즘, 위조에 취약
  • RSA : 대표적 공개키 알고리즘
  • DSA : 전자서명 알고리즘 표준
  • ECC : 짧은 키로 높은 암호 강도, 빠른 구현 가능 PDA, 스마트폰등에 사용

• 장점: 키 분배 필요 X, 기밀성/ 인증/ 부인방지 기능 제공

• 단점: 느린 속도

  • 긴 문서를 암호화하는데 사용하기 보단, 대칭 키 알고리즘의 키 값에 대한 암호에 사용됨.

• 방식

  • 암호모드: 송신자 공개 키로 암호화 → 송신자 사설 키로 복호화

    소량의 메시지 암호화 목적, 주로 키 교환의 용도로 사용

  • 인증모드: 송신자 사설 키로 암호화 → 송신자 공개키로 복호화

    메시지를 인증 부인방지하는 것이 목적

🔐 공개 키 암호

• 암호화와 복호화에 사용하는 키가 다름.
  • 공개 키: 모든 사람이 접근 가능한 키/ 암호화에 사용하는 키
  • 비밀 키: 사용자만 가지고 있는 키/ 복호화에 사용하는 키
• 공개 키는 누구나 알 수 있지만, 비밀 키는 키의 소유자만이 알 수 있음.
  • 특정 비밀키를 가지는 사용자만 내용을 열어볼 수 있음.
  • 안전한 메시지 전달 가능
• 공개 키 암호화 방식은 우체통에 비유할 수 있음.
  • 우체통의 투입구 공개 키를 통해 누구나 편지를 넣을 수 있음.
  • 편지함은 열쇠 비밀 키를 가진 사람만 열 수 있음.

• 공개 키 암호화/ 복호화 방식
  • A: B의 공개 키로 암호화한 데이터를 B에 보냄.
  • B: 본인의 비밀 키로 복호화한 평문 확인 → A의 공개키로 응답을 암호화 → A에 보냄.
  • A: 자신의 비밀 키로 암호화된 응답문 복호화
  • 따라서, B의 공개 키에 대응되는 비밀 키를 가지고 있는 B만 해당 데이터를 볼 수 있게 됨.
• 단, 대칭 키에 비해 암호화/ 복호화 과정이 매우 복잡함.
  • 암호화/ 복호화하는 키가 서로 다르기 때문!

들어가며, 리액트의 생명 주기에 대해 아주 간단히 알아보도록 하자 !

• Mount: 컴포넌트가 최초 실행될 때
• Render
  • 컴포넌트 내의 엘리먼트 요소들(HTML, React 사용자 정의 태그 등)을 화면 상에 그리는 동작
  • 컴포넌트가 마운트된 후, 컴포넌트가 호출될 때
• re-Render: 렌더링 동작을 다시 수행하는것
• UnMount: 컴포넌트가 사라질 때

즉, 컴포넌트가 처음 나타날 때를 마운트, 그 이후 값이 변경되어 컴포넌트가 변경된 상태에서 호출될 때를 렌더링 이라고 부른다.

🔰 Class Component 생명주기

👀 Mount (마운트)

: 컴포넌트가 생성 시, 발생하는 생명주기

✔︎ constructor

• 컴포넌트 생성자 메서드, 컴포넌트가 생성되면 가장 먼저 실행되는 메소드

✔︎ getDerivedStateFromProps

• props로부터 파생된 state를 가져오는 메소드

✔︎ render

• 컴포넌트를 렌더링하는 메소드

✔︎ componentDidMount

• 컴포넌트가 마운트되면 호출되는 메소드

👀 Updating (업데이트)

: 컴포넌트 업데이트 시점에 호출되는 메소드

✔︎ getDerivedStateFromProps

• 컴포넌트의 props나 state 변경 시 호출되는 메소드

✔︎ shouldComponentUpdate

• 컴포넌트의 리렌더링 여부를 결정하는 메소드
  • React.memo와 유사
  • boolean 반환

✔︎ componentDidUpdate

• 컴포넌트 업데이트 후 발생하는 메소드
  • 의존성 배열이 변할 때만 useEffect가 실행되는 것과 같은 맥락 !

👀 UnMount (언마운트)

: 컴포넌트가 화면에서 사라지는 것과 관련된 메소드

✔︎ componentWillUnmount

• 컴포넌트 생성자 메서드, 컴포넌트가 생성되면 가장 먼저 실행되는 메소드

📑 useEffect()

• 컴포넌트가 렌더링될 때 특정 작업(side effect)을 실행할 수 있도록 하는 Hook
  • side effect: 컴포넌트가 렌더링 된 이후, 비동기로 처리되어야 하는 부수적인 효과
    • ex. 함수 내부에서 함수 외부의 변수를 변하게 하는 액션
• componentDidMount와 componentDidUpdate, componentWillUnmount가 합쳐진 것 !

🔰 useEffect, 언제 작업을 처리하는가!

1. component가 mount 됐을 때
2. component가 unmount 됐을 때
3. component가 update 됐을 때

⇒ 즉, 클래스형 컴포넌트에서 사용할 수 있었던 생명주기 메소드(componentDidMount, componentDidUpdate, componentWillUnmount)를 함수형 컴포넌트에서도 사용 가능해짐!

🔰 useEffect 구조

useEffect (function, deps)

• function: 수행하고자 하는 작업

  • 리액트는 이 함수를 기억했다가, DOM 업데이트 이후 불러냄
  • function이 함수(a)를 return할 경우, 컴포넌트 unmount 시 함수(a) 다시 실행

• deps : 의존성, 이 값에 의존하여 function 실행

  • 배열 형태/ 검사하고자하는 특정 값이나 빈 배열이 들어감.
  • 특정 값이 들어가는 경우: 컴포넌트가 mount될 때, 지정한 값이 업데이트될 때 useEffect 실행
  • 빈 배열이 들어가는 경우: 따로 의존성을 갖지 않게 되어, 컴포넌트 mount 시 한 번만 실행됨.

🔰 cleanup 함수

👀 기본 형태

useEffect(() => {
    ... // 실행할 내용

    return () => {
        ... // clenup
    }
}

• cleanup 함수: 컴포넌트 unmount 시, 실행되는 함수
  • 컴포넌트가 사라질 때 호출되는 함수
  • 메모리 누수를 방지하여 메모리를 관리하거나 컴포넌트가 사라질 때, 수행할 작업들을 추가하기 위해 사용
  • 단, react 18 버전부터는 메모리 누수에 대한 경고가 사라짐

👀 예제

useEffect(() => {
    // 실행 함수
  const timer = setTimeout(() => {
  }, 3000);

    // clean-up 함수
  return () => { lock = true };

}, []);

• 리렌더링 시, useEffect의 return 함수 실행
• 실행된 함수가 useEffect의 내부 기능의 작동을 막음
• setState나 setTimeout, API 요청과 같은 비동기 함수가 작동할 때 조건문을 걸어 unmount되지 않았을때만 실행할 수 있도록 함

🔰 effect 타이밍

• useEffect로 전달된 함수는 컴포넌트 렌더링 - 화면 업데이트 - useEffect 실행 순서로 실행됨.
  • 즉, useEffect 실행은 최초 렌더링 이후에 일어남!!
• 만약 화면을 다 그리기 전에 동기화를 시키고 싶은 경우?
  • useLayoutEffect()를 활용하자!
  • useLayoutEffect로 전달된 함수는 컴포넌트 렌더링 - useLayoutEffect 실행 - 화면 업데이트 순서로 실행되기 때문에, 화면 업데이트 전 동기화가 가능해짐.

📑 useLayoutEffect()

• 사실상 useEffect()와 거의 동일한 역할을 하는 훅
• 아래에 명시한 useLayoutEffect()의 선언/ 정의 방식 역시, useEffect()와 거의 동일한 모습을 확인할 수 있다.

🔰 useLayoutEffect 구조

useLayoutEffect (function, deps)

useLayoutEffect(() => {
    ... // 실행할 내용

    return () => {
        ... // clean-up
    }
}

• 수행하고자 하는 작업인 function과 함수 실행 시점에 영향을 미치는 의존성 배열인 deps 를 매개 변수로 가짐.
• clean-up 함수 활용 가능.

🔰 useLayoutEffect() vs useEffect()

👀 이벤트 호출 시기

🐝 useEffect: 컴포넌트 마운트 실행 → 브라우저가 화면에 DOM 그리기(화면 업데이트) → effect 함수가 실행됨

🐿️ useLayoutEffect: 컴포넌트 마운트실행 → effect 함수 실행 → 브라우저 화면에 DOM 그리기(화면 업데이트)

👀 화면 깜빡임

🐝 useEffect: 컴포넌트들이 render, paint된 후 실행되기 때문에, 비동기적으로 실행이 이루어짐

• 함수 내부 DOM에 영향을 주는 코드가 있을 경우, 화면 깜빡임 발생 ⭕️ !
  • paint: 실제 스크린에 Layout을 표시하고 업데이트하는 과정

🐿️ useLayoutEffect: 컴포넌트들이 render된 후 실행되고, 후에 pain가 되기 때문에 동기적으로 실행이 이루어짐

• 함수 내부 DOM을 조작하는 코드가 존재하더라도, 화면 깜빡임 발생 ❌ !

👀 결론

• useLayoutEffect()는 동기적으로 실행되며, 내부 코드가 모두 실행된 후 painting 작업을 거치기 때문에 로직이 복잡할 경우 사용자가 레이아웃을 보기까지 오랜 시간이 걸린다.
• data fetch, event handler, state reset 등 **기본적인 작업 시에는 useEffect()를 사용**하는 것이 좋다.
• 단, DOM을 조작하거나 state들이 조건에 따라 첫 painting 시 다르게 렌더링되어야 하는 경우에는 useLayoutEffect()를 사용하는 것이 좋다.
  • useEffect 사용 시, re-rendering으로 인해 화면 깜빡임 발생

📑 useMemo()

• 리액트에서 컴포넌트 성능을 최적화하는데 사용되는 훅
  • 부모 컴포넌트의 값이 변했을 때, 자식 컴포넌트에 발생할 불필요한 리렌더링을 방지
• useMemo에서 ‘memo’는 memoization을 의미
  • ‘메모리에 넣는다’는 의미
  • 컴퓨터 프로그램이 동일한 계산을 반복해야할 때, 이전에 계산한 값을 메모리에 저장함으로써 동일한 계산의 반복 수행을 제거하여 프로그램 실행 속도를 빠르게 하는 기술

즉, 동일한 값을 반환하는 함수를 반복적으로 호출해야 한다면, 처음 값을 계산할 때 해당 값을 메모리에 저장하여 필요할 때마다 다시 계산하지 않고 메모리에서 꺼내서 사용

🔰 useMemo 구조

useMemo(calculateValue, dependencies)

• calculateValue: 캐시하려는 값을 계산하는 함수
  • 인수를 취하지 않는 순수 함수여야 함!
• dependencies: 의존성 배열
  • 특정 값이 들어가는 경우: 콜백 함수 재 호출 → memoization된 값 업데이트 → 다시 memoization 실행
  • 빈 배열이 들어가는 경우: 따로 의존성을 갖지 않게 되어, 컴포넌트 mount 시 한 번만 값 계산 → 이후 항상 memoization된 값 꺼내와서 사용

🔰 useMemo 주의사항

• useMemo()를 활용하여 값을 캐싱하려면 구성 요소의 최상위 레벨에서 호출해야 함!
• restrict mode에서는 계산 함수를 2번 호출 함
  • 이는 개발 전용 동작이며, 프로덕션에는 영향을 주지 않음!
  • 계산 함수가 순수함수로 잘 구현되어 있다면, 프로덕션에 영향을 주지 않고 호출 중 하나의 결과는 무시됨.
• 값을 재활용하기 위해 메모리를 써서 값을 저장하는 훅이기 때문에, 불필요하게 모든 값을 memoization 해버리면 성능 저하가 발생하게 됨
• 따라서, 꼭 필요한 경우에만 사용할 것을 권장한다 !

🚨 useMemo vs React.memo

🎃 React.memo

const MyComponent = React.memo((props) => {
    return (/*컴포넌트 렌더링 코드*/)}
);

• Higher-Order Components(HOC)
  • 컴포넌트를 인자로 받아 새로운 컴포넌트를 다시 return 해주는 함수.
  • 인자로 받은 컴포넌트로 새로운 별도의 컴포넌트를 만듦.
• 불필요한 컴포넌트 렌더링 방지.
  • 컴포넌트가 같은 props를 받고 같은 결과를 렌더링하는 경우, React.memo를 활용하여 불필요한 컴포넌트 렌더링 방지.
• 오직 props 변경 여부만을 체크.
  • 함수 내부에서 useState와 같은 훅을 사용하고있다면, state가 변경될 때마다 렌더링 발생.
  • props로 들어온 값 비교. (num, str → 실제 값이 동일한지 비교, object → 참조 reference 여부 비교)
• 메모이제이션을 하고자 하는 컴포넌트 자체를 React.memo로 감싸줌.
• 상위 컴포넌트가 리렌더링되더라도 React.memo로 감싸준 컴포넌트는 리렌더링되지 않음.

🎃 useMemo

• 복잡한 결과 값을 memoization 해서 최척화하기 위한 Hook.
• Hook이기 때문에 함수형 컴포넌트 내에서만 사용 가능.
• 값을 계산하는 과정을 최적화 → 값 반환.

🎃 결론

공통점

• props가 변하지 않으면(이전 props와 동일하면) 인자로 넘긴 함수는 재실행되지 않고, 이전 memoized된 결과를 반환함.

차이점

• React.memo는 HOC, useMemo는 hook.
• React.memo: 함수이기 때문에 클래스형 컴포넌트와 함수형 컴포넌트 모두 사용 가능.
• useMemo: hook이기 때문에 오직 함수형 컴포넌트 내에서만 사용 가능.

컴퓨터와 컴퓨터 간의 LAN 또는 WAN에서 원활한 통신을 가능하게 하기 위한 통신 규약이다.

TCP 통신은 클라이언트와 서버가 연결된 상태에서 데이터를 주고 받는 연결 지향적 프로토콜로, 가장 큰 특징은 신뢰성이다.

신뢰성이란, 통신 중간에 데이터가 유실되지 않는 것을 뜻한다.

신뢰성을 구성하는 대표적인 방법으로는 흐름제어와 혼잡제어가 있다.

🌟 흐름 제어 (End to End)

흐름 제어는 송신 측과 수신 측의 데이터 처리 속도를 일치시키는 기법이다.

수신 측이 송신 측보다 데이터 처리 속도가 느릴 경우, 데이터를 손실할 위험이 존재하게 된다. 흐름 제어는 송신 측에서 전송하는 데이터의 양을 제어하는 방식으로 데이터 처리속도를 일치시킨다.

즉, 흐름 제어는 송신 측과 수신 측 사이의 **패킷** 수를 제어하는 기능이라고 할 수 있다.

→ 패킷 (Packet): 인터넷에서 라우팅을 효과적으로 하기 위해 나눈 데이터 조각

[흐름 제어가 필요한 상황]

• 송신 측 데이터를 전송량 > 수신 측 데이터 처리량
  • 수신자의 버퍼에 미처 처리하지 못한 데이터가 쌓임
  • 수신자의 버퍼 가득 참 → 버퍼가 가득 차있는 동안 전달된 데이터 손실 위험

[흐름 제어의 해결 방식]

• 송신자의 데이터 전송 속도 조절
  • 수신자가 데이터를 처리하는 속도만큼 송신자가 데이터를 천천히 보내게 하여 문제 해결

👣 Stop and Wait (→ 비효율적)

• 매번 전송한 패킷에 대해 확인 응답(ACK)을 받으면 다음 패킷을 전송하는 방법.
• 패킷을 하나씩 보내기 때문에, 비효율적인 방식!

💦 데이터 보낼 때마다 아래 과정 반복 💦

1. 송신자 → [데이터] → 수신자
2. 수신자 → [남은 버퍼 공간] → 송신자 (데이터 받을 때마다 알려줌)
3. 송신자 → [수신자가 보낸 정보] → 자신의 데이터 전송 속도 조절

⇒ 매번 전송한 패킷에 대한 확인 응답을 받아야 다음 패킷 전송 가능한 구조.

⇒ 구현은 간단하지만 매우 비효율적 !!

👣 Sliding Window 방식 (→ Stop and Wait 방식 개선)

• 데이터를 하나만 보내고 기다리는 것이 아닌, 한 번에 여러 개의 데이터 전송 → 수신자의 응답 기다림
• 송신 측이 수신 측에서 받은 윈도우 크기를 참고해서 데이터의 흐름을 제어하는 방식
  • 윈도우 크기: 단위 시간 내에 보내는 패킷 수

💦 데이터를 다 받을 때까지 아래 과정 반복 💦

1. 수신자 → 최초 윈도우 크기를 7로 설정

2. 송신자 → 수신자의 확인 응답(ACK)을 받기 전까지 데이터 전송

   • 재전송
     • 일정 시간동안 수신 측으로부터 확인 응답(ACK)을 받지 못하면 패킷 재전송
     • 송신 측 재전송 → 수신 측 버퍼의 남은 공간 없는 경우 → 문제 발생
       • 이를 해결하기 위해, 확인 응답(ACK)을 보내면서 남은 버퍼의 크기(윈도우 크기)도 함께 전송

3. 수신자 → 확인 응답(ACK) → 송신자에게 전송 → 윈도우 크기를 충족할 수 있도록 윈도우를 옆으로 이동 시킴.

🌟 혼잡 제어 (End to Network)

혼잡 제어는 송신 측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법이다.

데이터의 양이 라우터가 처리할 수 있는 양을 초과할 경우, 라우터는 데이터를 처리하지 못하고 송신 측에서는 해당 데이터를 손실 데이터로 간주하게 된다. 혼잡 제어는 송신 측의 데이터 전송 속도를 적절히 조절하여 데이터 처리 속도 차이를 해결한다.

즉, 혼잡 제어는 네트워크 내의 패킷 수를 조절하여 네트워크의 오버 플로우를 방지하는 기능이라고 할 수 있다.

[혼잡 제어가 필요한 상황]

• 송신자가 사용하는 네트워크에 엄청나게 많은 인원이 데이터를 전송하는 경우
  • 라우터가 데이터를 처리하는 속도보다 많은 양의 데이터가 들어오면 문제 발생
  • 송신자 → 라우터가 처리하지 못한 데이터를 잃어버린 것으로 간주 → 계속해서 데이터 재전송
    • 라우터(router): 네트워크에서 송신자가 보낸 데이터를 알맞은 수신자에게 보내주는 장치/ 데이터 처리 속도와 처리할 데이터를 보관해두는 버퍼 존재
  • 이러한 과정이 반복되면 네트워크는 점점 혼잡해짐.

[혼잡 제어 해결 방식]

• 송신자의 데이터 전송 속도 조절
  • 네트워크에 전송되는 데이터가 과도하게 증가하는 현상 방지

👣 AIMD(Additive Increase/ Multiplicative Decrease)

• 패킷을 하나씩 전송하다가 문제없이 도착 시, 윈도우 크기 1씩 증가시켜가며 전송하는 방법
• 패킷 전송에 실패 시, 네트워크가 혼잡하다 판단 → 패킷 전송 속도 절반으로 줄임.

💦 특징 💦

• 공평한 방식
• 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 불리하지만, 시간이지나면 평형상태로 수렴.

💦 문제점 💦

• 초기 네트워크의 높은 대역폭을 사용하지 못함 → 오랜 시간 소요 → 네트워크가 혼잡해지는 상황을 미리 감지하지 못함.
• 즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식

👣 Slow Start (느린 시작)

• AIMD 방식: 네트워크의 수용량 주변에서는 효율적으로 작동하지만, 초기 전송 속도를 올리는데 오랜 시간이 소요되는 단점 존재.
• 패킷을 하나씩 전송하다가 문제없이 도착 시, 각각의 ACK 패킷마다 윈도우 크기 1씩 증가시킴.
  • 한 주기가 지나면 윈도우 크기는 2배가 됨.
• 전송 속도는 AIMD에 반해 지수 함수 꼴로 증가
  • 단, 혼잡 현상 발생 시, 윈도우 크기를 1로 떨어뜨림.

💦 특징 💦

• 초기 네트워크의 수용량을 예상할 수 있는 정보 없음.
• 그러나 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느정도 예상 가능
• ACK가 도착할 때마다 윈도우 크기를 증가 시킴
  • 초기 윈도우 크기가 느리게 증가할 지 라도, 시간이 지날 수록 윈도우 크기가 점점 빠르게 증가!
  • 혼잡 현상이 발생했던 윈도우 크기의 절반까지는 지수 함수 꼴로 창 크기 증가 → 완만하게 1씩 증가

👣 Fast Retransmit (빠른 재전송)

• TCP의 혼합 조절에 추가된 정책.
• 패킷을 받는 쪽에서 먼저 도착 해야할 패킷이 도착하기 전, 다음 패킷이 도착한 경우에도 ACK 패킷 보냄.
• 순서대로 잘 도착한 마지막 패킷의 다음 패킷 순번을 ACK 패킷에 실어서 보냄.
  • 중간에 하나의 패킷 손실 → 송신 측: 순번이 중복된 ACK 패킷 받음.
  • 이를 감지하는 순간, 문제가 되는 순번의 패킷 재전송.
• 중복된 순번의 패킷을 3개 받으면 재전송.
  • 혼잡한 상황 감지 → 윈도우 크기 줄임.

💦 특징 💦

• 송신 측은 자신이 설정한 타임아웃 시간이 지나지 않았어도 바로 손실 패킷 재전송 가능
  • 보다 빠른 재전송률 유지 가능

👣 Fast Recovery (빠른 회복)

• 혼잡한 상태 → 윈도우 크기를 1이 아니라 반으로 줄이고, 선형 증가시킴.
• 혼잡 상황을 한 번 겪은 이후로는 AIMD 방식으로 동작.

🌟 마무리

흐름 제어와 혼잡 제어는 모두 TCP의 신뢰성있는 데이터 전송을 위한 기능이다.

두 기능의 공통점은 송신자의 전송 속도를 제어함으로써 데이터 전송 시의 오류를 줄이는 기능이라는 것이다.

두 기능의 차이점은 흐름 제어는 송신 측과 수신 측의 패킷 수를 제어하는 기능이고, 혼잡 제어는 네트워크 내의 패킷 수를 조절하는 기능이라는 것이다.

인터넷 상에서 데이터를 메시지 형태로 보내기 위해 IP와 함께 사용하는 프로토콜을 말한다.

즉, 클라이언트와 서버가 연결된 상태에서 데이터를 주고 받는 연결 지향적 프로토콜이라고 할 수 있다.

일반적으로 TCP는 IP와 함께 사용되며 IP는 배달을, TCP는 패킷의 추적 및 관리를 하게 된다.

TCP는 연결형 서비스로, 신뢰적인 전송을 보장하기 때문에 데이터의 흐름제어와 혼잡제어를 수행한다.

👣 TCP 특징

• 3-way handshake 과정을 통해 연결을 수립하고, 4-way handshake을 통해 연결을 해제한다.
• 연결 지향적 → 상대방이 내 신호를 받을 수 있는지 확인하고 전송
• 높은 신뢰성 보장
• 흐름 제어 및 혼잡 제어 수행

👣 TCP 작동 방식 (큰 틀)

• 데이터 전송 전, 3-way handshake → 논리적 접속 성립
  • 모든 데이터는 고정된 통신 선로를 통해 전달 됨
• 데이터 전송이 끝나면 4-way handshake → 데이터가 모두 전달됐는지 확인 → 연결 해제

따라서, TCP는 서버와 클라이언트 간의 데이터를 신뢰성 있게 전달하기 위해 만들어진 프로토콜이다.

데이터를 정확하고 안정적으로 전달할 수 있기 때문에 높은 신뢰성을 보장한다.

🌟 TCP 3-way handshake 란?

• 전송제어 프로토콜(TCP)에서 통신하는 장치 간 연결이 잘 되었는지 확인하는 과정/ 방식.
• TCP/IP 4계층을 통과, 데이터를 보낼 준비가 되면 수신 측이 받을 준비가 되었는지 확인하는 과정.
• 3-way handshake를 수행하기 위해서는 TCP 헤더에 표시한 SYN과 ACK 플래그들이 사용됨.

👣 3-way handshake 과정

1. 클라이언트 → 서버에 접속 요청 메시지 SYN(x) 패킷 전송.

   • SYN(Synchronize Sequence Number): 임의의 랜덤 숫자

2. 서버 → SYN(x) 받음 → 클라이언트에게 연결요청 메시지 ACK(x+1) + SYN(y) 패킷 전송.

   • ACK(Acknowledgement number: SYN+1의 값

3. 클라이언트 → ACK(x+1) + SYN(y) 받음 → 서버에 ACK(y+1) 전송.

⇒ 3️⃣번의 통신 완료 후, 연결 성립(Established)

🌟 TCP 4-way handshake 란?

• 연결 성립 후, 모든 통신이 끝났다면 이를 해제해야 함.
• 전송제어 프로토콜(TCP)에서 통신을 중단할 때 사용하는 과정/ 방식
  • 연결 중단 시, 한 번 더 확인 후 해제
• 데이터 송수신이 완료되면 TCP 연결을 해제하는 과정
• 4-way handshake를 수행하기 위해서는 TCP 헤더에 표시한 ACK와 FIN 플래그들이 사용됨.

👣 TCP 4-way handshake 과정

1. 클라이언트 → 서버에게 연결 종료를 알리는 FIN 플래그가 설정된 패킷 전송.

   • FIN (finish): 세션을 종료시키는데 사용됨, 더이상 보낸 데이터가 없음을 의미

2. 서버 → FIN 신호 확인 → 확인했다고 알려주기 위해 ACK 신호 전송.

   • 이때, 모든 데이터를 보내기 위해 CLOSE_WAIT 상태 돌입.

3. 서버 통신 끝 → 연결 종료 요청 합의의 의미로 클라이언트에게 FIN 플래그가 설정된 패킷 전송.

4. 클라이언트 → FIN 받음 → 확인의 의미로 ACK 플래그가 설정된 패킷 보냄

   • 아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다림
   • TIME_WAIT: 의도치 않은 에러로 인해 연결이 데드락으로 빠지는 것 방지 목적
     • 에러 발생 → 종료 지연 → 타임 초과 → CLOSED 상태로 변경
   • 서버 → ACK 받은 이후 소켓 닫음 (Closed)
   • 클라이언트 → TIME_WAIT 시간이 끝나면 클라이언트 닫음(Closed)

⇒ 4️⃣번의 통신 이후, 연결 해제

• 데이터 가져오기를 위한 react hook
• 캐시(stale)로부터 데이터 반환 → fetch 요청 → 최신화된 데이터 가져오기
• 즉, 다른 컴포넌트에서 동일한 상태를 사용하고자 하는 경우 이전에 캐시했던 상태를 그대로 사용
  • 서버로 재요청 하는 방식 ❌❌
  • 서로 다른 컴포넌트에서 동일한 상태 공유 가능!
• 한 줄의 코드로 데이터 가져오기 가능

💎 SWR ! React Query와 비교하여 자세히 알아보기

🔥 React Query

리액트 어플리케이션에서 서버 상태를 가져오고, 캐싱, 동기화, 업데이트하는 것을 쉽게 해줌.

import { QueryClient, QueryClientProvider, useQuery } from "react-query";

const queryClient = new QueryClient();
const url = "https://61b88c9d64e4a10017d19053.mockapi.io/user";

const App = () => (
  <div>
    <QueryClientProvider client={queryClient}>
      <ReactQueryProfile />
    </QueryClientProvider>
  </div>
);

const ReactQueryProfile = () => {
  const {isLoading, error, data, isFetching} = useQuery("users", () =>
    fetch("https://61b88c9d64e4a10017d19053.mockapi.io/user").then(res => res.json())
  );

  if (error) return <div>failed to load</div>;
  if (isLoading) return <div>loading...</div>;

  return <Profile library="React Query" data={data} />;
}

const Profile = ({library, data}) => (
  <div>
    <h1>Users from {library}</h1>
    {data.map(user => <p>{user.level} developer <strong>{user.name}</strong></p>)}
  </div>
)

export default App;

🌊 SWR

캐시에서 데이터를 반환한 후, 서버에 데이터를 가져오는 요청을 보내고, 마지막으로 최신 데이터를 제공함.

import useSWR from "swr";

const App = () => (
  <div>
    <SWRProfile />
  </div>
);

const SWRProfile = () => {
  const {data, error} = useSWR("https://61b88c9d64e4a10017d19053.mockapi.io/user", url =>
    fetch(url).then(res => res.json())
  );

  if (error) return <div>failed to load</div>;
  if (!data) return <div>loading...</div>;

  return <Profile library="SWR" data={data} />;
}

const Profile = ({library, data}) => (
  <div>
    <h1>Users from {library}</h1>
    {data.map(user => <p>{user.level} developer <strong>{user.name}</strong></p>)}
  </div>
)

export default App;

1. Provider

🔥 React Query

Provider로 컴포넌트를 감싸지 않을 경우, 에러 발생함.

🌊 SWR

별도의 Provider 없이 컴포넌트에서 바로 사용 가능함.

2. Fetcher

모두 두 번째 인자로 fetcher를 받음.

🔥 React Query

fetcher에 url 직접 전달해야 함.

꼭! 두 번째 인자에 fetcher를 넘겨줘야 함.

🌊 SWR

fetcher의 인자로 useSWR의 첫 번째 인자를 넘겨줌.

전역 성정을 통해 fetcher 정해둘 수 있음.

3. Mutation

🔥 React Query

post/ patch/ put/ delete를 통해 서버의 상태를 변형시키는 것.

🌊 SWR

useSWR()을 통해 받아온 데이터를 클라이언트 사이드에서 변형시켜 업데이트 해주는 것.

4. Selectors

🔥 React Query

select를 이용해 데이터를 가공할 수 있음.

🌊 SWR

데이터 가공은 불가능함.

5. Offline Mutation

🔥 React Query

오프라인 상태에서 뮤테이션을 시도했을 때, 해당 요청을 잠시 멈췄다가 온라인 상태가 되면 요청 재시도함.

🌊 SWR

API를 멈췄다가 다시 시도하기 때문에, 서버 데이터를 변경하는 것은 불가능함.

6. Auto Garbage Collection

🔥 React Query

지정된 시간(기본 5분)동안 쿼리가 사용되지 않을 경우, 자동으로 가비지 컬렉션 지원.

🌊 SWR

SWR에서는 별도로 제공하고 있지 않음.

📚 참고 자료

https://swr.vercel.app/ko

https://tech.madup.com/react-query-vs-swr/

https://velog.io/@seohee0112/React-Query-vs-SWR

카카오 로그인 구현 방식은 크게 2가지로 나뉜다.

1. JavaScript SDK 활용
2. REST API 활용

Kakao Developers 문서에 들어가보면, REST API를 활용한 카카오 로그인은 PC 및 모바일 웹에서 구현시 적합한 방식이라고 명시되어있다. 나는 모바일 웹에서 카카오 로그인을 구현할 예정이었기에, REST API를 활용하여 해당 기능을 구현하게 되었다.

실제 코드를 구현하기 전, 먼저 postman에서 로직을 실행해보았다.

📜 핵심 플로우

1. 카카오 서버에 인가코드를 요청한다. → 본인 인증 성공 시, 인가코드가 발급된다.
2. 인가코드를 활용하여 개인 token을 발급받는다. → 로그인 성공 시, token이 발급된다.
3. token으로 로그인을 유지한다.

📮 인가코드 및 token 발급받기

KakaoDevelopers

1️⃣ 위의 사이트에 들어가서 새로운 어플리케이션을 만들어준다. (개인적으로 테스트해보는 용도라면, 사업자 명도 자유롭게 적으면 된다!)

2️⃣ 내 애플리케이션 > 제품 설정 > 카카오 로그인에 들어간다.

→ 카카오 로그인을 활성화 해주고, Redirect URI도 추가한다.

https://getpostman.com/oauth2/callback

3️⃣ 내 애플리케이션 > 앱 설정 > 요약 정보에 들어가서 REST API 키를 확인한다.

4️⃣ postman에서 oauth2.0 인증을 해본다. 🚨 이 때, postman 웹 사이트가 아닌 앱에서 진행을 해야 제대로 oauth2.0 인증 테스트를 할 수 있다! 🚨

5️⃣ 아래의 사진을 참고하여 정보를 채워준 후, Get New Access Token을 눌러준다.

• Token Name : kakao rest API
• Callback URL : Authorization Code 방식으로 토큰 발급을 받는 url/ Redirect URI 부분에 추가한 주소 적어준다. 안되면 006 Error 뜬다. (postman에서 실습하기 때문에, postman 주소로 적어줌.)
• Auth URL : OAUTH를 지원해 주는 서버에 로그인을 하기 위한 주소
• Access Token URL : 발급 받은 인증 코드를 포함하여 req 하여 res로 token을 받기 위한 URL
• Client ID : REST API 키
• Client Secret : 안 적어도 되지만, Client Secret을 따로 설정해줬다면 적어줘야 한다. (내 애플리케이션 > 제품 설정 > 카카오 로그인 > 보안)

6️⃣ Get New Access Token 버튼을 클릭하면 아래와 같은 창이 뜬다.

7️⃣ 로그인에 성공하면 토큰이 발급되고, Use Token 버튼을 클릭하면 postman에서 자동으로 토큰을 저장한다.

☑️ 코드에 활용하기

1️⃣ Redirect URI에 콜백 주소를 추가하고, 해당 주소와 REST API 값을 env 파일에 저장한다.

2️⃣ oAuth.ts 파일을 만들어서 해당 정보를 상수파일에 저장해둔다. 이때, vite로 react를 시작한 경우 env에 저장된 값을 불러오고 싶다면 import.meta.env.VITE_APP_~~를 사용해야 한다!!

export const CLIENT_ID = import.meta.env.VITE_APP_REST_API_KEY;
export const REDIRECT_URI = import.meta.env.VITE_APP_REDIRECT_URI;

// prompt=login: 기존 사용자 인증 여부와 상관없이, 로그인 화면 출력 (추가 설정/ 필수 아님!)
export const KAKAO_AUTH_URL = `https://kauth.kakao.com/oauth/authorize?client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URI}&response_type=code&prompt=login`;

3️⃣ 카카오 서버에 요청보내기

import { KAKAO_AUTH_URL } from "../constant/OAuth";
import loginLogo from "../assets/loginLogo.png";

function KakaoLogin() {
  return (
    <div>
      <a href={KAKAO_AUTH_URL}>
        <img
          src={loginLogo}
          alt="카카오로 계속하기"
        />
      </a>
    </div>
  );
}

export default KakaoLogin;

→ 이미지 클릭 시, 콜백주소로 이동

function KakaoCallback() {
  // code: 카카오로부터 받은 인가코드
  const code = new URL(window.location.href).searchParams.get("code");
  const grantType = "authorization_code";

  useEffect(() => {
    if (code) {
      // 토큰을 받기 위한 코드 (access_token(6시간), refresh_token(2달) 받아올 수 있음)
      axios
        .post(
          `https://kauth.kakao.com/oauth/token?grant_type=${grantType}&client_id=${CLIENT_ID}&redirect_uri=${REDIRECT_URI}&code=${code}`,
          {},
          {
            headers: {
              "Content-type": "application/x-www-form-urlencoded;charset=utf-8",
            },
          }
        )
        .then((res: resInfo) => {
          console.log(res);
          const { access_token } = res.data;
          // 유저 개인정보 받아오기 위한 호출 코드
          axios
            .post(
              `https://kapi.kakao.com/v2/user/me`,
              // post body (post 통신 시, 데이터가 없다면 빈 객체로 보냄)
              {},
              // request headers
              {
                headers: {
                  // Authorization: 사용자 인증 수단, 엑세스 토큰 값
                  Authorization: `Bearer ${access_token}`,
                  "Content-type":
                    "application/x-www-form-urlencoded;charset=utf-8",
                },
              }
            )
            .then((res: resInfo) => {
              // 유저 id도 발급해줌
              console.log(res);
              // 유저 닉네임 가져오기
              console.log(res.data.kakao_account.profile);
            });
        })
        .catch((Error: object) => {
          console.log(Error);
        });
    }
  }, [code]);
  return <div></div>;
}

→ 콜백 주소에 등록해놓은 컴포넌트 → 이렇게 하면 토큰 및 유저 정보를 가져올 수 있음!

💪 마무리

• 처음 소셜 로그인을 구현했을 때, 여러 자료를 참고해도 잘 감이 오지 않아 많이 헤맸던 기억이 있다.
• 개인적으로는, 무작정 코드로 구현하지 않고 postman을 활용하여 pre-task를 진행한 후에 코드 구현을 했던 것이 소셜 로그인에 대한 이해를 높이는데 많은 도움이 됐다!
• 소셜 로그인을 구현하고자 하는 많은 사람들에게 이 글이 도움이 되길 바라며..!!

• fetching, caching, 서버 데이터와의 동기화를 지원해주는 라이브러리
• 비동기 처리를 쉽게 관리할 수 있는 라이브러리
• Client state에 적합한 라이브러리
• react component 내부에서 간단하고 직관적으로 api 사용 가능
• api 요청 관련 번잡한 작업 없이 “핵심 로직”에 집중 가능

0️⃣ 상태

• fresh

  • 요청이 만료되지 않은 쿼리

  • 새롭게 추가된 쿼리

  • 최신 상태의 쿼리

    
    

• fetching

  • 요청 중인 쿼리

• stale
  • 요청이 만료된 쿼리
  • 기존 상태의 쿼리

• inactive
  • 비활성화된 쿼리

1️⃣ 캐싱

• 데이터 캐싱 (특정 데이터의 복사본 저장 → 동일한 데이터에 재접근 속도 높이는 것)
• 반복적인 비동기 데이터 호출 방지 → 불필요한 api 콜 줄임 → 서버에 대한 부하 줄일 수 있음.
• 데이터를 캐싱했는데 해당 데이터의 상태가 변경되기 전의 내용을 가지고 있는 상황이 발생하지 않도록, 필요한 상황에 적절히 데이터를 갱신해야 함.
  1. 화면을 보고 있을 때
  2. 페이지 전환이 일어났을 때
  3. 페이지 전환없이 이벤트가 발생해 데이터 요청할 때
• react query에서는 어떤 시점에 데이터를 refetching 하는지 알 수 있는 옵션을 제공함.
  • refetchOnWindowFocus: 브라우저에 포커스가 들어온 경우
  • refetchOnMount: 새로운 컴포넌트 마운트가 발생한 경우
  • refetchOnReconnect: 네트워크 재연결이 발생한 경우

➡️ staleTime & cacheTime

• staleTime
  • 데이터가 fresh → stale 상태로 변경되는 데 걸리는 시간
  • fresh 상태 → refetch 트리거 (위의 3가지 상태) 발생해도 refetch 일어나지 X!!
  • 기본 값: 0
  • 따로 설정해주지 않는다면, refetch 트리거 발생 → 무조건 refetch
• cacheTime
  • 데이터가 inactive한 상태일 때 캐싱된 상태로 남아있는 시간
  • 특정 컴포넌트 unmount → 사용된 데이터는 inactive 상태로 전환 → cacheTime만큼 데이터 유지
  • cacheTime 이후 데이터 → 가비지 콜렉터로 수집 → 메모리에서 해제
  • cacheTime이 모두 지나기 전, 컴포넌트가 다시 mount → 새로운 데이터를 fetch 해오는 동안 캐싱된 데이터 보여줌
  • 즉, fetch 하는 동안만! 캐싱된 데이터를 임시로 보여주는 것!

⇒ 사용자가 특정 이벤트가 발생했을 때 refetching 하도록 설정할 수 있음!

2️⃣ Client Data & Sever Data

• Client Data
  • 상태 관리 라이브러리가 관리
  • 세션 간 지속되지 않는 데이터
  • 클라이언트가 소유하는 데이터
  • ex) 컴포넌트의 state, 동기적으로 저장되는 redux store의 데이터
• Sever Data
  • react query가 관리
  • 세션 간 지속되는 데이터
  • 비동기적이며, 여러 클라이언트에 의해 수정, 공유되는 데이터
  • ex) 비동기 요청으로 받아올 수 있는 백엔드 DB에 저장되어 있는 데이터
• onError, onSuccess 등의 함수를 통해 데이터 fetch 성공, 실패에 대한 분기를 간단히 구현 가능

const { data, isLoading } = useQueries(
    ['unique-key'],
    () => {
        return api({
            url: URL,
            method: 'GET',
        });
    },
    {
        onSuccess: (data) => {
            // data로 이것저것 하는 로직
        }
    },
    {
        onError: (error) => {
            // error로 이것저것 하는 로직
        }
    }
)

3️⃣ 대표적인 기능들

💡 기본적으로 GET - useQuery / PUT, UPDATE, DELETE - useMutation 사용

❇️ useQuery

• 첫 번째 파라미터: unique key를 포함한 배열 (동일한 쿼리를 불러올 때 유용하게 사용 가능)
  • 배열의 첫 요소: unique key
  • 배열의 두 번째 요소 ~ : query 함수 내부의 파라미터
• 두 번째 파라미터: 실제 호출하고자 하는 비동기 함수 (함수는 Promise를 반환하는 형태)
• 최종 반환 값: API 성공/ 실패 여부, 반환 값을 포함한 객체

// useQuery 활용 코드
const { isLoading, error, data } = useQuery({
    queryKey: ['repoData'],
    queryFn: () =>
      fetch('https://api.github.com/repos/tannerlinsley/react-query').then(
        (res) => res.json(),
      ),
  })

// 전체 예시 코드
import {
  QueryClient,
  QueryClientProvider,
  useQuery,
} from '@tanstack/react-query'

const queryClient = new QueryClient()

export default function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

function Example() {
    // data를 통해, fetch 성공 시 데이터 반환 가능
  const { isLoading, error, data } = useQuery({
    queryKey: ['repoData'],
    queryFn: () =>
      fetch('https://api.github.com/repos/tannerlinsley/react-query').then(
        (res) => res.json(),
      ),
  })

    // isLoading을 통해 로딩 여부를 알 수 있음
  if (isLoading) return 'Loading...'

    // error를 통해 에러 발생 여부를 알 수 있음
  if (error) return 'An error has occurred: ' + error.message

  return (
    <div>
      <h1>{data.name}</h1>
      <p>{data.description}</p>
      <strong>👀 {data.subscribers_count}</strong>{' '}
      <strong>✨ {data.stargazers_count}</strong>{' '}
      <strong>🍴 {data.forks_count}</strong>
    </div>
  )
}

❇️ useMutation

• PUT, UPDATE, DELETE와 같이 값을 변경할 때 사용하는 api
• 첫 번째 파라미터: 비동기 함수
• 두 번째 파라미터: 상황 별 분기 설정
• 최종 반환 값: API 성공/ 실패 여부, 반환 값을 포함한 객체 (useQuery와 동일)

// useMutation 활용 코드
const mutation = useMutation({
    mutationFn: (newTodo) => {
      return axios.post('/todos', newTodo)
    },
  })

// 전체 예시 코드
function App() {
  const mutation = useMutation({
    mutationFn: (newTodo) => {
            // 처음에 post 비동기 함수를 넣어줌
      return axios.post('/todos', newTodo)
    },
  })

  return (
    <div>
      {mutation.isLoading ? (
        'Adding todo...'
      ) : (
        <>
          {mutation.isError ? (
            <div>An error occurred: {mutation.error.message}</div>
          ) : null}

          {mutation.isSuccess ? <div>Todo added!</div> : null}

          <button
            onClick={() => {
                            // 첫 번째 인자로 api 호출 시 전달해야 할 데이터 넣어주기!
              mutation.mutate({ id: new Date(), title: 'Do Laundry' })
            }}
          >
            Create Todo
          </button>
        </>
      )}
    </div>
  )
}

✅ 추가 내용

📚 useQuery 동기적 실행

• enabled 옵션 사용

  • enabled에 값 대입 → 해당 값이 true일 때 → useQuery 비동기 실행 가능!

    const { data: todoList, error, isFetching } = useQuery("todos", fetchTodoList);
    const { data: nextTodo, error, isFetching } = useQuery(
    "nextTodos",
    fetchNextTodoList,
    {
      enabled: !!todoList // true가 되면 fetchNextTodoList를 실행한다
    }
    );

📚 useQueries

• 여러 개의 useQuery를 한 번에 실행 가능
• Promise.all() 처럼 묶어서 실행할 수 있도록 도와주는 역할!
• 여러 query에 대한 반환 값이 배열로 묶여 반환됨

const results = useQueries({
  queries: [
    { queryKey: ['post', 1], queryFn: fetchPost, staleTime: Infinity},
    { queryKey: ['post', 2], queryFn: fetchPost, staleTime: Infinity}
  ]
})

📚 retry

• 요청이 실패한 경우, 지정한 최대 요청 횟수까지 재요청 보냄 (기본: 3회)
• retryDelay: 다음 재요청까지의 딜레이 시간

const userQuery = useQuery(['users',1], fetchUsers,
                           { retry : 10, retryDelay : 400});

4️⃣ 장점

1. Devtools
   • react-query/devtools 를 통해 Devtool 지원 → 확실한 데이터 흐름 파악 가능
   • 개발 모드에서만 사용
   • swr : devtools 사용 가능하지만, 서드 파티 라이브러리를 이용해야 함!

1. 무한 스크롤 구현
   • getPreviousPageParam, fetchPreviousPage, hasPreviousPage 등의 기능을 활용하여 쉽게 무한 스크롤 구현 가능
   • swr을 활용해도 무한 스크롤을 구현할 수 있긴 하지만, 유저가 부가적인 코드를 작성해야 한다는 단점있음

2. Selectors

   • select 를 통해 raw data로 부터 원하는 데이터 추출, 반환 가능

     import { useQuery } from 'react-query'
     
     function User() {
     const { data } = useQuery('user', fetchUser, {
     
           // select 활용
       select: user => user.username,
     })
     return <div>Username: {data}</div>
     }

     
     

3. Data Optimization

   • swr과 달리, 쿼리가 업데이트 될 때만 refetch 진행

   • 여러 컴포넌트에서 동일한 쿼리 사용 시, 한 번에 묶어 업데이트 진행

   • 이를 통해 렌더링 퍼포먼스 개선 가능!

     
     

4. Garbage Collection

   • 지정 시간(기본 5분)동안 쿼리가 사용되지 않을 경우, 메모리 해제 → Auto Garbage Collection → 메모리 관리

📚 Reference

https://tanstack.com/query/latest/docs/react/overview?from=reactQueryV3&original=https%3A%2F%2Ftanstack.com%2Fquery%2Fv3%2Fdocs%2Foverview

https://velog.io/@seohee0112/React-Query

https://velog.io/@kandy1002/React-Query-푹-찍어먹기

• JS 기반 상태 관리 라이브러리
• 사용량이 압도적으로 높은 만큼, 안전성 보장
• 보일러 플레이트 코드 양이 너무 많음.
  • 작은 기능 하나를 추가하더라도 여러 줄의 코드 필요
• 러닝 커브 높음.
• 하나의 파일(store)에서 상태를 관리하기 때문에, 버그 발생 시 추적이 쉽고 관리가 용이함
• Redux DevTools를 활용하면 디버깅이 쉽다.
  • 앱의 상태가 언제, 어디서, 왜, 어떻게 바뀌었는지 쉽게 추적 가능
• 대규모 프로젝트에서 많이 쓰임

💡Store, Action, Reducer

🏠 Store

• 상태가 관리되는 하나의 공간
  • 컴포넌트와 별개로 Store라는 공간에 상태를 담아두고, 관리한다.
  • 컴포넌트에서는 상태가 필요할 때, 스토어에 접근한다.

📜 Action

• 앱에서 Store에 운반할 데이터 (주문서)

• JS 객체 형식

    {
      type: 'ACTION_CHANGE_USER', // 필수
      payload: { // 옵션
        name: '하나몬',
        age: 100
      }
    }

💌 Reducer

• Action을 Store에 전달하기 위해 거쳐야 하는 곳
• Action → Reducer에 전달 → Store에 상태 업데이트
• Action → Reducer에 전달하기 위해서는 dispatch() 메소드 사용해야 함.

✅ 결론

1. Action 객체 → dispatch() 메소드에 전달됨
2. dispatch(Action) 통해 Reducer 호출
3. Reducer → 새로운 Store 생성

🪢 Recoil

• React 상태 관리 라이브러리
• 직관적이기 때문에, 비교적 사용자 친화적임.
• get/ set 인터페이스 사용 → boilerplate-free API 제공
• 러닝 커브 낮음.
• data-flow graph: 상태 데이터가 atom → selector → 컴포넌트 순서로 흐름
• 컴포넌트 수정 없이 동기/ 비동기 식 전환 가능

💡 Atoms, Selectors

🫧 Atoms

• 상태의 단위
• 업데이트/ 참조 가능
• atom 업데이트 → 구독된 컴포넌트는 새로운 값을 반영 → 리렌더링
• 런타임에서도 생성 가능
• React의 state 대신 사용 가능
• 동일한 atom이 여러 컴포넌트에서 사용 → 모든 컴포넌트는 상태를 공유함.
• Atoms는 atom 함수를 사용해 생성

const fontSizeState = atom({
  key: 'fontSizeState',
  default: 14,
});

• 고유한 키 값 필요

• useRecoilState 훅을 통해 atom 읽고 쓰기 가능

  • useState와 비슷하지만, 컴포넌트 간의 상태가 공유될 수 있다는 차이.

    function FontButton() {
    const [fontSize, setFontSize] = useRecoilState(fontSizeState);
    return (
      <button onClick={() => setFontSize((size) => size + 1)} style={{fontSize}}>
        Click to Enlarge
      </button>
    );
    }

👀 Selectors

• atoms나 다른 selectors를 입력으로 받아들이는 순수 함수
• atom 상태 값을 동기/ 비동기 방식을 통해 변환
• 상위 atoms/ selectors 업데이트 → 하위의 selector도 다시 실행됨
• 참조 가능
• selectors 변경 → 컴포넌트 리렌더링
• 최소한의 상태 집합만 atoms에 저장 → 다른 모든 파생 데이터 → selectors에 명시한 함수를 통해 효율적 계산 가능
• 어떤 컴포넌트가 자신을 필요로 하는지, 어떤 상태에 의존하는지 추적
• 컴포넌트의 관점)) selectors, atoms는 동일한 인터페이스 가짐 → 서로 대체 가능
• Selectors는 selector 함수를 사용해 생성

const fontSizeLabelState = selector({
  key: 'fontSizeLabelState',
  get: ({get}) => {
        // fontSizestate라는 하나의 atom에 의존성을 가짐
    const fontSize = get(fontSizeState);
    const unit = 'px';

    return `${fontSize}${unit}`;
  },
});

function FontButton() {
  const [fontSize, setFontSize] = useRecoilState(fontSizeState);
    // Selectors는 useRecoilValue() 통해 읽을 수 있음
    // fontSizeLableState는 writable 하지 않기 때문에 useRecoilState()를 이용하지 않음!
  const fontSizeLabel = useRecoilValue(fontSizeLabelState);

  return (
    <>
      <div>Current font size: ${fontSizeLabel}</div>

      <button onClick={setFontSize(fontSize + 1)} style={{fontSize}}>
        Click to Enlarge
      </button>
    </>
  );
}

📚 Reference

Redux - 자바스크립트 앱을 위한 예측 가능한 상태 컨테이너. | Redux

Redux(리덕스)란? (상태 관리 라이브러리) - 하나몬

주요 개념 | Recoil

📌Next.js란?

웹 어플리케이션을 구축하기 위한 React 프레임워크

👇 그래서.. React랑 뭐가 다른건데!! 👇 React와의 차이를 알아보기 위해 CSR과 SSR에 대해 짚고 넘어가보자!

📌CSR vs SSR

✅ CSR (Client Side Rendering)

• 클라이언트 쪽에서 렌더링을 진행하는 방식이다.
• 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내주고 클라이언트에서는 이것을 받아서 렌더링을 시작한다.
• 서버에서의 처리없이 클라이언트로 보내주기 때문에, 모든 JavaScript 파일을 다운로드하는 동안 제대로 된 화면을 볼 수 없다.
• 브라우저가 JS를 다운로드하고 동적 DOM을 생성하기 위해 초기 로드 시간이 오래 걸린다.
• 이후 렌더링은 서버에서 해당 데이터만 response 받아 사용하면 되기 대문에 첫 렌더링 이후 구동 속도는 빠른 편이다.
• 검색 엔진 최적화(SEO)가 필요없거나, 데이터의 사전 렌더링이 필요없거나, 페이지의 내용이 실시간으로 자주 업데이트되어야 할 경우에는 유용하게 쓰이는 방식이다.

✅ SSR (Server Side Rendering)

• 서버 쪽에서 렌더링 준비를 마친 상태로 클라이언트에 전달하는 방식이다.
• 이미 렌더 가능한 상태로 서버에서 클라이언트로 전달되기 때문에, JavaScript 파일이 다운로드 되는 동안 사용자는 로딩 화면만 보고 있지 않아도 된다.
• 검색 엔진은 자동화된 로봇인 '크롤러'로 웹 사이트를 읽게 되는데,서버에서 렌더링된 HTML 파일을 보내주는 SSR은 검색 엔진 최적화(SEO)에 유리하다.
• JavaScript 파일 다운로드를 기다리지 않아도 되기 때문에 초기 구동 속도가 빠르다.
• 그러나 서버 호출 시 페이지가 새로고침 되며 깜빡임이 발생하고, 요청이 생길 때마다 서버에서 렌더링되지 않아도 될 부분까지 준비하기 때문에 서버 부하를 일으키기도 한다.

📌React와 Next.js

React와 Next.js의 가장 큰 차이점 중 하나는 렌더링하는 방식에 있다. React는 CSR, Next.js는 SSR 방식으로 렌더링한다.

✅ React (feat. CSR)

• 대표적인 CSR 라이브러리인 React는 웹 사이트를 요청했을 때 빈 HTML을 가져와서 JS를 로딩하는 구조이다.
• 로딩 시간이 SSR에 비해 오래 걸리고, 만약 JS를 다룰 줄 모르는 검색 엔진이 사이트를 크롤링한다면 텅 빈 HTML만 인식하게 된다.
• 즉, CSR 방식을 사용하는 React는 로딩 시간도 비교적 오래걸리고 SEO에 취약하다는 단점이 있다.

✅ Next.js (feat. SSR)

반면, Next.js는 웹에 사이트를 요청했을 때 서버 측 렌더링을 거친 후 HTML과 JS를 따로 reponse한다.

💡 Next.js의 작동원리는 다음과 같다.
1. 초기에 사용자가 서버에 접속을 요청하면, SSR 방식으로 렌더링될 HTML을 보낸다. 2. 브라우저에서 JavaScript를 다운로드하고 React를 실행한다. 3. 사용자와 페이지가 서로 상호작용하며 다른 페이지로 이동하게 될 경우에는 CSR 방식으로 브라우저에서 처리한다.

• Next.js는 모든 페이지를 pre-render(HTML을 JS 처리하기 전, 사전에 생성) 하기 때문에, 검색엔진 최적화가 가능해진다.
• 사전 렌더링에 의해 만들어진 HTML은 해당 페이지에서 필요한 최소한의 JavaScript 코드와 연결된다.
• 어떤 페이지의 HTML이 브라우저에 의해 로드되면 그 HTML에 연결된 JavaScript 코드가 실행되어 해당 페이지 상호작용이 가능해지며, 이런 과정을 Hydration이라고 부른다.
• 즉, Next.js는 리액트 문법을 쓰는 프론트 문법을 쓸 수 있게 도와주 백엔드 프레임워크 라고 할 수 있다.

📌Next.js, 어떤 특징/ 기능을 가지고 있을까?

다음은 공식 문서에서 가져온 Next.js 특징 중 일부이다.
- 직관적인 페이지 기반 라우팅 시스템 - 사전 렌더링, 정적 생성(SSG) 및 서버 측 렌더링(SSR)은 페이지 별로 지원 - 더 빠른 페이지 로드를 위한 자동 코드 분할 - 최적화된 프리패치를 사용한 클라이언트 측 라우팅(CSR) - 내장 CSS 및 Sass 지원 및 모든 CSS-in-JS 라이브러리 지원

👇 좀 더 자세히 알아보자!

1. Automatic Routing

React와 달리, 별도의 세팅없이 페이지를 기반으로 한 라우팅을 지원한다. React에서는 별도의 라우터를 제공하지 않기 때문에, react-router-dom이라는 패키지를 설치하여 사용했다.

Next.js 13은 app 폴더 하위에page 파일을 추가하고 그 안에 레이아웃을 넣는 방식으로, 추가한 파일을 export하게 되면 폴더명이 페이지 route가 되어 해당 파일이 라우터 역할을 하게 된다!

ex1. app/blog/page.js → /blog

ex2. app/blog/first-blog/page.js → /blog/first-blog

2. Dynamic Routes

항상 미리 정의된 경로를 사용할 수 있는 것은 아니다. 예를 들어 블로그 게시물의 경로는 /blog1, /blog2, /blog3 … 과 같은데, 모든 경로를 미리 정의하거나 페이지 컴포넌트를 생성하는 일은 굉장히 비효율적이다.

이때 사용하는 것이 동적 라우팅이다. [folderName]과 같이 폴더 이름을 대괄호로 묶어주면 해당 페이지 컴포넌트가 동적으로 라우팅 된다.

클라이언트 사이드에서 동적 경로에 접근하고 싶다면 next/link를 사용해주면 되고, router.push 같은 메소드를 사용할 수 도 있다!

📍 [folderName]

app/category/[slug]/page.js

Next.js 13 Automatic Routing에 따라 app 폴더 하위에 category 폴더를 만들고, 그 안에 Dynamic Routes를 위한 [slug] 폴더를 만든 것이다. /category/food, /category/study 등의 주소는 모두 /post/[pid].js로 매칭된다. [id]나 [slug]처럼 동적인 부분은 Layout과 Page나 Head 컴포넌트들에게 params prop으로 전달된다.

/category/food → { slug: 'food' }

/category/study → { slug: 'study' }

📍 Catch-all Segment : [...folderName]

app/shop/[...slug]/page.js

[slug]에 ...을 추가하여 shop 하위의 모든 경로를 잡아낼 수 있다.

/shop/clothes → { slug: ['clothes'] }

/shop/clothes/pants → { slug: ['clothes', 'pants'] }

/shop/clothes/tops/t-shirts → { slug: ['clothes', 'tops', 't-shirts'] }

3. Code Splitting

코드 분할은 다른 페이지에 대한 코드는 처음에 제공하지 않고, 원하는 페이지에 접근하는데 필요한 chunk(작은 코드 조각)만을 로드한다.

여러 개의 페이지가 있는 웹 사이트일지라도 필요한 페이지만을 빠르게 로드할 수 있으며, 이는 JavaScript 페이로드를 최소화하고 애플리케이션 로드 시간을 개선할 수 있다.

초기 페이지 로드에 필요하지 않은 구성 요소가 있는 경우 다음(👇)과 같이 동적으로 가져올 수 있다. 이는 필요할 때만 Puppy를 로드하도록 지시하고 있다.

// import Puppy from "../components/Puppy";
import dynamic from "next/dynamic";

// ...

const Puppy = dynamic(import("../components/Puppy"));

4. Client-Side Navigation

<Link /> 컴포넌트를 통한 페이지 이동이 빠르고 매끄럽다. HTML의 a 태그와 달리, 페이지를 리로딩하지 않는다. <Link />가 뷰포트에 보이면 관련 페이지를 백그라운드에서 미리 가져오기 때문에, 사용자가 링크를 클릭했을 때 매우 빠르게 해당 페이지로 이동할 수 있게 해준다.

5. TypeScript

TypeScript를 활용하기 위해서 웹팩이나 바벨을 만지지 않아도 된다. TypeScript를 설치하고 yarn run dev를 해주면 자동으로 tsconfig, next-end.d.ts가 생성되어 TypeScript를 사용할 수 있다.

yarn add typescript @types/node @types/react

yarn run dev

6. SSR + CSR

초기 페이지 로딩에서는 SSR 방식을 이용하여 처리하고, 이후의 요청에 대해서는 CSR 방식으로 처리하기 때문에 SSR 방식의 장점(SEO에 유리)과 CSR의 이점을 모두 활용할 수 있다.

7. Pre-rendering

Next.js는 모든 페이지를 사전 렌더링한다.

📌Next.js 13

👉 app/ Directory

• 기존 버전에서는 Automatic Routing 사용 시, pages 안에 파일 생성하여 별도의 라우터 없이도 애플리케이션 내부에서 즉시 경로 생성이 가능했다. 하지만 Next.js 13 버전부터는 app/ 디렉토리가 등장하여 라우팅 및 레이아웃 기능을 개선했다.
• 현재는 pages 디렉토리와 app 디렉토리가 공존할 수 있는 베타 버전으로 제공되고 있다.

👉 Streaming

• app/ 디렉토리에서 loading.js 예약 파일을 생성하면 렌더링이 되기 전에 로딩 중인 화면을 표시할 수 있는 기능이 추가됐다.
• 아래 코드처럼 엄청 간단하게 만들어볼 수 있다!

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

👉 Data Fetching

• 기존 버전에서는 데이터를 가져올 때 getServerSideProps()나 getStaticProps()를 사용했지만, Next.js 13 버전부터는 이 문법들을 사용하지 않는다.

• 공식문서에 따르면, 현재 Client Component에서의use() 사용은 권장되지 않으며, 이는 무수한 리렌더를 유발할 것이라고 언급하고 있다. Client Component에서 fetch 데이터가 필요하다면, SWR과 React Query와 같은 라이브러리 사용을 추천한다고 한다.

• 정적 데이터 가져오기

  fetch('https://...'); // cache: 'force-cache' is the default

• 캐시된 데이터의 유효성을 주기적으로 다시 검사하려면 next.revalidate 옵션을 사용해서 리소스의 캐시 유효시간(초)을 설정할 수 있다.

fetch('https://...', { next: { revalidate: 10 } });

• 동적 데이터 가져오기

  fetch('https://...', { cache: 'no-store' });

• fetch 구문의 URL 뒤에 { cache: '' } 를 넣어줄 수 있다. cache에 들어가는 내용에 따라 기존의 getServerSideProps(), getStaticProps()의 기능을 구현할 수 있다.

// Similar to `getStaticProps`.
fetch(URL, { cache: 'force-cache' });

// Similar to `getServerSideProps`.
fetch(URL, { cache: 'no-store' });

// Similar to `getStaticProps` with the `revalidate` option.
fetch(URL, { next: { revalidate: 10 } });

👉 etc..

이 외에도 Next.js 13에서 변경된 부분이 다수 있다. 자세한 내용은 nextjs.org를 참고해보자!

📘참고자료 How Next.js Works What is Next.js? Next.js를 사용하면서 리액트랑 별반 다르지 않다고 느꼈던 이유 [Next.js] 기본 개념 : Next.js 란? Next.js를 왜 사용할까? Next.js의 장점은? Next.js 13 Next.js 13 신버전 발표회 요약 Next.js의 Routing Next.js Dynamic Import(동적 가져오기): 성능 및 사용자 경험 개선 dynamic-routes