[TIL] 221101

먼지·2022년 11월 1일
0

TIL

목록 보기
40/57
post-thumbnail

벨로그 개발 글 읽기

아직

면접에서 동기 & 비동기 묻는 이유

https://velog.io/@jkijki12/%EB%A9%B4%EC%A0%91%EC%97%90%EC%84%9C-%EB%8F%99%EA%B8%B0-%EB%B9%84%EB%8F%99%EA%B8%B0-%EB%AC%BB%EB%8A%94-%EC%9D%B4%EC%9C%A0

전통적인 서버
Web Server의 전통적인 동기 방식
1. Client에 요청이 들어옴
2. 웹 서버에 Request가 도착함
3. Thread Manager가 Thread pool을 확인함
4. Thread pool에 쉬고 있는 Thread가 존재하면 Request에 Thread를 할당해 요청에 대한 처리를 진행
5. Thread pool에 남아있는 Thread가 존재하지 않는다면, Task Queue에 Request를 담고 Thread가 나올 때까지 기다림

전통적인 서버의 단점

  • 수많은 요청이 생기고 모든 Thread가 할당받아서 처리되는 중일 때 엄청난 Latency(지연 시간)가 발생함
    엄청난 latency가 발생하는 이유? Context Switching + Blocking 때문

위와같은 문제들을 해결하기 위해 새로운 형식의 서버가 언급됨. 새로운 서버구성은 다음과 같이 동작함
1. Request가 들어옴
2. 먼저 Event Queue에 담는다.
3. 처음에 설정해둔 1개 이상의 쓰레드가 모든 Event를 스케쥴링하여 수행함
4. 다른 API 호출 및 디스크 I/O가 존재할 경우, 쓰레드는 대기상태로 기다리지 않음
5. 사용자에게 우선 return 함
6. 그리고 해당하는 작업이 완료되면 비동기적으로 결과 값을 받음
7. 완료된 작업을 사용자에게 Return함

결론
묻는 이유는 여러가지 이유가 존재하겠지만, 기본적인 서버 latency를 발생시키는 주요 원인을 물어본 것. 지속적으로 발생하는 문제이고 이에 대한 해결을 해나가는게 서버 개발자이다

음 조금 이해하기 어려웠다. 내가 생각한 동기 비동기 개념이 아닌 것 같지만 알아두면 좋겠지? 서버 개발자들에게 더 필요한 개념인 듯..?

Thinking in React

https://velog.io/@hyunjine/Thinking-in-React

React를 다룰 때 갖고 있어야 하는 생각들.
DOM은 Document Object Model의 약자로, 브라우저가 HTML을 파싱하여 객체 형태로 만든 것을 말함

<div>
  <span>하하</span>
</div>

위와 같은 HTML 구조를 갖는 웹사이트가 있다고 가정했을 때, HTML은 문자열이고 문자열은 파싱, 합치기 등의 작업을 다루기 어려움

브라우저는 이 다루기 어려운 문자열을 다루기 쉬운 객체 형태로 바꿔주고 이 객체를 DOM이라고 함.

DOM API는 반환하는 값이 Live 할 수도 있고, Static 할 수도 있기 때문에 일관성이 없다고 표현함

그럼 어떻게 해야 할까?

가장 간단한 답은 DOM API를 사용하지 않는 방법으로 DOM API를 직접 사용하지 않고 중간에 매개체(React)를 두어서 DOM을 조작!

React
React는 웹 애플리케이션의 UI를 재사용 가능한 컴포넌트들을 모아서 구성함. 각 컴포넌트엔 데이터 모델이 존재하며, 앱과 UI가 상호작용하려면 UI에 내재하는 데이터 모델을 바꿔야 함. 이 데이터 모델을 React에선 State(상태)라고 함. 상태란 주어진 시간에 대해 시스템을 나타내는 것으로 언제든지 변경될 수 있고 상태가 업데이트되면 React 컴포넌트는 렌더링 됨.

렌더링이란 리액트가 컴포넌트에게 현재 Props와 State에 개반해 UI에 어떻게 보여지고 싶은지 알려달라고 요청하는 과정. 간단히 말해 함수 컴포넌트를 호출하는 것으로, 함수에서 반환하는 JSX는 시간에 따른 UI의 스냅샷과 같음

리액트는 VirtualDOM을 활용해서 기존 VirtualDOM과 업데이트 후의 VirtualDOM에서 바뀐 부분만을 계산(diffing) 하여 실제 바뀐 부분만 DOM에 적용함. 이를 React에서 Reconciliation(재조정)이라고 함.

렌더링을 두 단계로 쪼갤 수 있음

  • Render phase(렌더 단계): 컴포넌트를 렌더링하고 변경 사항을 계산하는 모든 과정이 이루어지는 단계(VirtualDOM 조작 단계)
  • Commit phase(커밋 단계): 변경 사항을 실제 DOM에 적용하는 단계

렌더링은 기본적으로 상태 업데이트에 의해 발생하므로, 적절한 상태를 적절한 컴포넌트에 배치시켜야 함

Props(properties)는 컴포넌트간에 값을 전달할 때 사용함(데이터 전달)

같이 변경돼야 하는 중복 상태는 가장 가까운 공통 부모로 상태를 이동시킨 후에 props를 통해 전달함. 이를 상태 끌어올리기(Lifting State Up)이라고 함.

React에선 데이터의 흐름이 상위 컴포넌트에서 하위 컴포넌트로 한 방향으로만 흐름 (단방향 데이터 흐름, Unidirectional Data Flow)

하위 컴포넌트에서 상위 컴포넌트의 상태를 변경하고 싶다면? Props로 상태를 업데이트 하는 setState 함수를 전달하여 하위 컴포넌트에서 이 함수를 호출하면 됨. (= 역방향 데이터 흐름, Inverse Data Flow)

위의 경우처럼 브라우저에서 모든걸 처리할 수 있다면 클라이언트 상태로도 충분하지만 대다수의 어플리케이션은 서버 상태가 존재함.

Server State
서버상태의 특성

  • 사용자의 제어를 벗어난 위치에서 원격으로 유지됨
  • 비동기 요청을 통해 fetching 또는 updating이 가능함
  • 소유권을 공유함. 즉 사용자 모르게 다른 사용자가 변경할 수 있음
  • 시간이 지남에 따라 stale(신선하지않은?) 또는 outdated(구식?) 됨

React는 UI 라이브러리기 때문에 데이터를 fetching 하는 것에 관심이 없고, 단지 fetching한 데이터를 UI에 반영시키는 것에만 관심이 많음. 그래서 서버 상태를 다루기 위해 여러가지 상태를 정의해야 함. Loading, Error, Success 상태를 정의해 각각의 상태별로 매 렌더링마다 UI 스냅샷을 찍어서 보여줌

기존엔 API 요청의 상태에 따라 적합한 UI를 보여주기 위해 컴포넌트 외부에 수많은 보일러 플레이트 코드를 작성해야 했음.

React Query
React Query는 이를 해결하며 역할이 명확 => 서버 상태를 관리하기 위해 필요했던 보일러 플레이트 코드를 제거하고 단 몇 줄의 코드로 대체함

리액트 쿼리를 사용하면 여러 상태를 정의해야 하는 문제는 해결되지만 컴포넌트가 isLoading과 같은 상태일 때 반환할 UI를 정의해줘야 함. 이는 UI의 일관성을 해침

Suspense
Suspense는 이를 해결함. Suspense의 목표는 서버 상태를 읽어오는 것을 React의 props와 state처럼 쉽게 다루는 것임

<Suspense fallback={<Spinner />}>
  <Component />
</Suspense>

비동기적으로 데이터를 불러오는 컴포넌트를 Suspense로 감싸고 fallback으로 보여줄 컴포넌트를 전달함. 이렇게 하면 기존 UI의 로딩 상태를 명령형(imperative) 방식으로 정의해야 했던 것을 React 패러다임에 맞게 선언적(declarative)인 방식으로 바꿀 수 있음

React v18
React팀의 목표는 "성능이 좋은 React를 만들어 수백만개의 React로 만들어진 웹사이트 성능을 높이는 것" 하나인데 가장 큰 문제는 React를 만든 언어에 있음. 리액트는 자바스크립트 위에서 만들어졌기 때문에 JS의 제약을 따를 수 밖에 없음. 특히 JS가 브라우저 위에서 동작하는 방식을 따름

브라우저의 메인 스레드는 싱글 스레드로 한번에 하나의 작업만 처리할 수 있음. HTML을 파싱하거나 JavaScript를 실행하거나 화면에 보이는 내용을 렌더링하는데 사용됨. 리액트를 비롯한 대다수의 UI 라이브러리 작동 방식도 이 한계에 종속될 수 밖에 없음.

React도 화면에 그리기 위한 내부 연산, 즉 렌더링을 시작해서 화면을 완성할 때까지 실행을 멈출 수 없음. 이를 리액트 팀에선 블로킹 렌더링이라고 부름

React 18에선 동시성 기능이 추가됨.(Concurrent features)
동시성이란 두 개 이상의 독립적인 작업을 잘게 나누어 Context Switchin을 하며 동시에 실행되는 것처럼 보이도록 프로그램을 구조화하는 방법으로, 이를 활용하면 렌더링을 잘게 쪼개어 상태 업데이트에 우선순위를 두어 좀 더 긴급한 상태 업데이트를 먼저 수행할 수 있음.

정리

  • React는 DOM 조작의 문제점을 해결하기 위해 만들어짐
  • React는 Reconciliation(재조정) 과정을 통해 DOM을 업데이트함
  • React의 핵심은 상태 관리
  • React에서 Concurrent Feature를 활용해 렌더링 우선순위를 정할 수 있음

React는 UI를 변수에 저장할 수 있으며 값으로 전달할 수 있음. 즉 React는 value UI. React의 핵심 원칙은 UI는 값이라는 것임

profile
꾸준히 자유롭게 즐겁게

0개의 댓글