vegatality blog RSS Feed

React에 SOLID 원칙 적용하기

Sun, 16 Jun 2024 00:00:00 GMT

개요

SOLID 원칙은 객체 지향 프로그래밍 언어를 염두에 두고 구상되고 설명되었습니다. 이러한 원칙과 설명은 클래스와 인터페이스의 개념에 크게 의존하지만 JS에는 실제로 그런 개념이 없습니다.

JS의 클래스는 prototype과 prototype chaining을 사용한 클래스의 유사체일 뿐이며 인터페이스는 존재하지 않습니다(단, Typescript를 사용하면 인터페이스 활용 가능).

더 나아가서 React 코드를 작성하는 방식은 객체 지향과는 거리가 멉니다. 함수형에 더 가깝습니다.

그래서 SOLID원칙을 좀 더 자세히 살펴보고 함수형 React 코드에 적용하기 위해서 약간의 해석 및 적용 변형이 필요합니다.

단일 책임 원칙(SRP, Single Responsibility Principlele)

단일 책임 원칙은 클래스(객체)는 단 하나의 책임만 가져야 한다는 원칙입니다.
여기서 ’책임‘이라는 의미는 하나의 ’기능 담당‘으로 보면 됩니다.
즉 하나의 클래스는 하나의 기능만을 담당하여 하나의 책임을 수행하는데 집중하도록 클래스를 따로따로 여러 개 설계하라는 원칙입니다.

리액트에 대입

이를 리액트에 대입시키면 “모든 함수/모듈/컴포넌트는 정확히 한 가지 작업을 수행해야 한다.”라는 정의로 해석할 수 있습니다.

SRP는 5가지 원칙 중 가장 따르기 쉬운 원칙입니다. SRP를 지키기 위해 다음을 고려하여 수행할 수 있습니다.

너무 많은 작업을 수행하는 컴포넌트를 더 작은 컴포넌트로 나눔
주요 컴포넌트 기능과 관련 없는 코드를 별도의 유틸리티 함수로 추출
관련 있는 기능들을 커스텀 hook으로 캡슐화

이제 이 원칙을 적용하는 방법을 살펴보겠습니다. 다음은 활성 사용자 목록을 표시하는 예제 컴포넌트 코드입니다.

const ActiveUsersList = () => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    const loadUsers = async () => {
      const response = await fetch("/some-api");
      const data = await response.json();
      setUsers(data);
    };

    loadUsers();
  }, []);

  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);

  return (
    <ul>
      {users
        .filter((user) => !user.isBanned && user.lastActivityAt >= weekAgo)
        .map((user) => (
          <li key={user.id}>
            <img src={user.avatarUrl} />
            <p>{user.fullName}</p>
            <small>{user.role}</small>
          </li>
        ))}
    </ul>
  );
};

이 컴포넌트는 데이터를 가져오고, 필터링하고, 컴포넌트 자체와 목록의 각 항목을 렌더링는 등 이미 많은 작업을 수행하고 있습니다. 이를 나눠보도록 하겠습니다.

커스텀 hook으로 추출하기

우선 서로 연관된 useState와 useEffect가 있을 때는 언제든지 커스텀 hook으로 추출할 수 있습니다.

const useUsers = () => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    const loadUsers = async () => {
      const response = await fetch("/some-api");
      const data = await response.json();
      setUsers(data);
    };

    loadUsers();
  }, []);

  return { users };
};

const ActiveUsersList = () => {
  const { users } = useUsers();

  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);

  return (
    <ul>
      {users
        .filter((user) => !user.isBanned && user.lastActivityAt >= weekAgo)
        .map((user) => (
          <li key={user.id}>
            <img src={user.avatarUrl} />
            <p>{user.fullName}</p>
            <small>{user.role}</small>
          </li>
        ))}
    </ul>
  );
};

useUsers훅은 오직 API에서 사용자를 가져오는 것 하나에만 관련되어 있습니다. 또한 ActiveUsersList컴포넌트 내부의 코드가 짧아지고 useUsers라는 커스텀 훅의 이름 덕분에 선언적으로 용도를 파악할 수 있기 때문에 읽기 더 쉬워졌습니다.

렌더링 로직 분리

다음으로 컴포넌트가 렌더링하는 JSX를 살펴보겠습니다. 객체 배열을 순회하며 매핑하는 경우 배열의 각 항목에 대해 생성하는 JSX의 복잡성에 주의를 기울여야 합니다.
이벤트 핸들러가 연결되지 않은 한 줄짜리 마크업인 경우 인라인으로 유지하는 것이 좋지만 더 복잡한 마크업의 경우 별도의 컴포넌트로 추출하는 것이 좋습니다.

const UserItem = ({ user }) => {
  return (
    <li>
      <img src={user.avatarUrl} />
      <p>{user.fullName}</p>
      <small>{user.role}</small>
    </li>
  );
};

const ActiveUsersList = () => {
  const { users } = useUsers();

  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);

  return (
    <ul>
      {users
        .filter((user) => !user.isBanned && user.lastActivityAt >= weekAgo)
        .map((user) => (
          <UserItem key={user.id} user={user} />
        ))}
    </ul>
  );
};

사용자 항목을 렌더링하는 로직을 별도의 컴포넌트로 분리한 덕분에 메인 컴포넌트인 ActiveUsersList컴포넌트 내부 로직의 가독성이 더 좋아졌습니다.

유틸 함수 분리

마지막으로 API로부터 얻은 전체 사용자 목록에서 비활성 사용자를 필터링하는 로직이 있습니다. 이 로직은 비교적 독립되어 있고 애플리케이션의 다른 부분에서 재사용될 수 있으므로 유틸리티 함수로 쉽게 추출할 수 있습니다.

const getOnlyActive = (users) => {
  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);

  return users.filter(
    (user) => !user.isBanned && user.lastActivityAt >= weekAgo
  );
};

const ActiveUsersList = () => {
  const { users } = useUsers();

  return (
    <ul>
      {getOnlyActive(users).map((user) => (
        <UserItem key={user.id} user={user} />
      ))}
    </ul>
  );
};

데이터를 페칭한 다음 필터링을 적용하고 있지만 추가 조작 없이 데이터를 가져와 렌더링하기만 하는 것이 이상적입니다. 따라서 마지막 개선 사항으로 이 로직을 새로운 커스텀 hook으로 캡슐화할 수 있습니다.

const useActiveUsers = () => {
  const { users } = useUsers();

  const activeUsers = useMemo(() => {
    return getOnlyActive(users);
  }, [users]);

  return { activeUsers };
};

const ActiveUsersList = () => {
  const { activeUsers } = useActiveUsers();

  return (
    <ul>
      {activeUsers.map((user) => (
        <UserItem key={user.id} user={user} />
      ))}
    </ul>
  );
};

SRP의 ‘단 하나의 책임만 가져야 한다.‘라는 규칙을 따져보았을 때 누군가 위 컴포넌트는 여전히 먼저 데이터를 얻은 다음 렌더링하기 때문에 ‘하나의 책임’이 아니라고 주장할 수도 있습니다. 비즈니스와 뷰 로직이 함께 있는 것처럼 보이기 때문이죠.

이를 충족시키기 위해 한 컴포넌트에서 hook을 호출한 다음 그 결과를 다른 컴포넌트에 props로 전달해서 더 나눌 수 있습니다.

그러나 함수형 컴포넌트와 훅의 도입 이후부터는 데이터 로직과 뷰 로직을 그렇게까지 나누지는 않고 있고 그렇게 나눈다고 해도 실제로 이로운 경우는 거의 없습니다.

리액트 훅의 도입 전에는 비즈니스 로직과 뷰 로직을 분리하기 위한 컴포넌트를 작성하곤 했습니다.

리액트 훅의 도입 전에 관심사의 분리(SoC, separation of concerns)를 강제하는 방법은 Container/Presentational Pattern을 이용하는 방법이 있었습니다. Presentational Components는 뷰 로직을 다루는 표현을 위한 컴포넌트이고, Container Components는 비즈니스 로직을 다루는 컴포넌트로 사용합니다. 이를 통해 비즈니스 로직과 뷰 로직을 분리해낼 수 있었습니다.
하지만 리액트 훅이 이를 완전히 대체할 수 있어 더 이상 권장되지 않는 패턴입니다. Container/Presentational 참고

개방-폐쇄 원칙(OCP, Open Closed Principle)

OCP 원칙은 클래스는 ’확장에 열려있어야 하며, 수정에는 닫혀있어야 한다‘를 뜻합니다.
기능 추가 요청이 오면 클래스를 확장을 통해 손쉽게 구현하면서, 확장에 따른 클래스 수정은 최소화하도록 프로그램을 작성해야 하는 설계 기법입니다.

개방-폐쇄 원칙은 원본 소스 코드를 변경하지 않고 확장할 수 있는 방식으로 구성 요소를 구조화하도록 권고합니다.

Header컴포넌트를 예시로 들어보도록 하겠습니다.
Header컴포넌트를 여러 페이지에서 공유하고 있으되, 현재 있는 페이지에 따라 조금 다른 UI를 렌더링 해야 하는 상황이라고 가정해보겠습니다.

const Header = () => {
  const { pathname } = useRouter();

  return (
    <header>
      <Logo />
      <Actions>
        {pathname === "/dashboard" && (
          <Link to="/events/new">Create event</Link>
        )}
        {pathname === "/" && <Link to="/dashboard">Go to dashboard</Link>}
      </Actions>
    </header>
  );
};

const HomePage = () => (
  <>
    <Header />
    <OtherHomeStuff />
  </>
);

const DashboardPage = () => (
  <>
    <Header />
    <OtherDashboardStuff />
  </>
);

현재 경로별로 다른 컴포넌트를 렌더링하도록 하고 있네요.
코드를 딱 한 번 봐도 더 많은 페이지를 추가하기 시작할 때 어떤 일이 일어날지 생각하면 이 구현이 나쁘다는 것을 쉽게 알 수 있습니다.
새 페이지가 생성될 때마다 Header 컴포넌트로 돌아가서 렌더링할 작업 링크를 알 수 있도록 구현을 조정해야 합니다.
이러한 접근 방식은 Header 컴포넌트는 취약해지고 사용되는 컨텍스트와 긴밀하게 결합되어, 개방-폐쇄 원칙에 위배됩니다.

컴포넌트 합성(component composition)

이 문제를 해결하기 위해 컴포넌트 합성(component composition)을 사용할 수 있습니다. Header 컴포넌트는 내부에서 무엇을 렌더링할지 신경 쓸 필요가 없으며 대신 children prop을 사용해서 Header를 사용할 컴포넌트에게 이 책임을 위임할 수 있습니다.

const Header = ({ children }) => (
  <header>
    <Logo />
    <Actions>{children}</Actions>
  </header>
);

const HomePage = () => (
  <>
    <Header>
      <Link to="/dashboard">Go to dashboard</Link>
    </Header>
    <OtherHomeStuff />
  </>
);

const DashboardPage = () => (
  <>
    <Header>
      <Link to="/events/new">Create event</Link>
    </Header>
    <OtherDashboardStuff />
  </>
);

Header에서 이러한 props를 사용하는 컴포넌트로 일부 컨텍스트를 전달해야 하는 경우 Passing JSX as children을 사용할 수 있습니다. 보시다시피 합성(composition)은 매우 강력합니다.

리스코프 치환 법칙 (LSP, Liskov Substitution Principle)

부모 클래스의 인스턴스를 사용하는 위치에 자식 클래스의 인스턴스를 대신 사용했을 때 코드가 원래 의도대로 작동해야 한다는 의미입니다.
하위 타입 객체는 상위 타입 객체에서 가능한 행위를 수행할 수 있어야 합니다.
올바른 상속을 위해 자식 객체의 확장이 부모 객체의 방향을 온전히 따르도록 권고하는 원칙입니다.

아주 단순하게 정의하면, LSP는 “하위 타입 객체가 상위 타입 객체를 대체할 수 있는” 객체 간의 관계 유형입니다.

이 원칙은 하위 타입과 상위 타입 관계를 정의하기 위해 클래스 상속에 크게 의존하지만, 클래스 상속은 고사하고 클래스를 거의 다루지 않기 때문에 React에서는 거의 적용할 수 없습니다. 클래스 상속에서 벗어나면 필연적으로 이 원칙이 완전히 다른 것으로 바뀌겠지만 상속을 사용하여 React 코드를 작성하면 의도적으로 나쁜 코드를 만들게 되므로(React 팀에서 매우 권장하지 않음. 합성을 권장함) 이 원칙은 넘어가겠습니다.

인터페이스 분리 원칙(ISP, Interface Segregation Principle)

인터페이스를 각각 사용에 맞게끔 잘게 분리해야한다는 설계 원칙입니다.
SRP 원칙이 클래스의 단일 책임을 강조한다면, ISP는 인터페이스의 단일 책임을 강조하는 것으로 보면 됩니다.

React 애플리케이션을 위해 이것을 “컴포넌트는 사용하지 않는 props에 의존해서는 안 됩니다”로 해석하겠습니다.
ISP가 목표로 하는 문제를 더 잘 설명하기 위해 다음 예제에서는 TypeScript를 사용합니다.

interface Video {
  title: string;
  duration: number;
  coverUrl: string;
}

interface Props {
  video: Video;
}

const Thumbnail = ({ video }: Props) => {
  return <img src={video.coverUrl} alt='' />;
};

type LiveStream = {
  name: string;
  previewUrl: string;
};

type TVideoListProps = {
  items: Array<Video | LiveStream>;
};

const VideoList = ({ items }: TVideoListProps) => {
  return (
    <ul>
      {items.map((item, i) => {
        // if video
        if ('coverUrl' in item) {
          // eslint-disable-next-line react/no-array-index-key
          return <Thumbnail key={i} video={item} />;
          // if LiveStream
        } else {
          // video 객체를 전달해야 해서 LiveStream 썸네일을 사용할 수 없다.
          // return <Thumbnail key={i} video={item} />;
        }
      })}
    </ul>
  );
};

위 코드에서는 Video 목록을 렌더링하고 내부적으로 썸네일을 보여주되 LiveStream이라면 LiveStream의 thumbnail을 보여주도록 애플리케이션을 만들고자 했습니다.
Thumbnail컴포넌트에서 video프롭은 Video 객체가 Props로 전달되어야 하며 실질적으로 프로퍼티 중 하나만 사용합니다.

보시다시피 여기에는 문제가 있습니다. Video와 LiveStream 객체를 쉽게 구별할 수 있지만 Video와 LiveStream이 호환되지 않기 때문에 후자를 Thumbnail 컴포넌트에 전달할 수 없습니다.
첫째, 타입이 다르기 때문에 TypeScript는 즉시 문제를 제기합니다.
둘째, Video 객체는 ‘coverUrl’, LiveStream 객체는 ‘previewUrl’이라는 서로 다른 프로퍼티에 섬네일 URL을 갖고 있습니다.

이것이 컴포넌트가 실제로 필요한 것보다 더 많은 props에 의존했을 때 겪게 되는 문제의 핵심입니다. 재사용성이 낮아지기 때문에 이를 수정해 봅시다.

interface Video {
  title: string;
  duration: number;
  coverUrl: string;
}

interface Props {
  coverUrl: string;
}

const Thumbnail = ({ coverUrl }: Props) => {
  return <img src={coverUrl} alt='' />;
};

type LiveStream = {
  name: string;
  previewUrl: string;
};

type TVideoListProps = {
  items: Array<Video | LiveStream>;
};

const VideoList = ({ items }: TVideoListProps) => {
  return (
    <ul>
      {items.map((item, i) => {
        // if video
        if ('coverUrl' in item) {
          // eslint-disable-next-line react/no-array-index-key
          return <Thumbnail key={i} coverUrl={item.coverUrl} />;
        }
        // if LiveStream
        // eslint-disable-next-line react/no-array-index-key
        return <Thumbnail key={i} coverUrl={item.previewUrl} />;
      })}
    </ul>
  );
};

인터페이스 분리 원칙은 시스템의 컴포넌트들 간 의존성을 최소화해 컴포넌트의 결합도를 낮추고, 재사용성을 높일 수 있도록 합니다.

의존관계 역전 원칙 (DIP, Dependency Inversion Principle)

DIP 원칙은 어떤 Class를 참조해서 사용해야하는 상황이 생긴다면, 그 Class를 직접 참조하는 것이 아니라 그 대상의 상위 요소(추상 클래스 or 인터페이스)로 참조하라는 원칙입니다.
쉽게 이야기해서 구현 클래스에 의존하지 말고, 인터페이스에 의존하라는 뜻(추상화에 의존해야지, 구체화에 의존하면 안 된다)

이 원칙은 추상적이므로 이해하기 어려울 수 있습니다. 따라서 바로 예제를 살펴보겠습니다.
아래는 폼이 제출될 때 사용자 자격 증명을 일부 API로 보내는 LoginForm 컴포넌트입니다.

import api from "~/common/api";

const LoginForm = () => {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");

  const handleSubmit = async (evt) => {
    evt.preventDefault();
    await api.login(email, password);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
      />
      <button type="submit">Log in</button>
    </form>
  );
};

이 코드에서 LoginForm 컴포넌트는 api 모듈을 직접 참조하므로 둘 사이는 긴밀히 결합되어 있습니다.
한 컴포넌트의 변경이 다른 컴포넌트에 영향을 미치도록 만드는 이러한 의존성은 코드를 변경하기 더 어렵게 하기 때문에 좋지 않습니다.
의존관계 역전 원칙은 이러한 결합을 깨는 것을 권하므로 이를 어떻게 할 수 있을지 살펴보겠습니다.

먼저 LoginForm 내부에서 api 모듈에 대한 직접 참조를 제거하고 대신 props를 통해 필요한 기능을 주입할 수 있도록 합니다.

type Props = {
  onSubmit: (email: string, password: string) => Promise<void>;
};

const LoginForm = ({ onSubmit }: Props) => {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");

  const handleSubmit = async (evt) => {
    evt.preventDefault();
    await onSubmit(email, password);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
      />
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
      />
      <button type="submit">Log in</button>
    </form>
  );
};

이 변경으로 LoginForm 컴포넌트는 더 이상 api 모듈에 의존하지 않습니다. API에 크리덴셜을 제출하는 로직은 onSubmit 콜백을 통해 추상화되었으며 이제 이 로직의 구체적인 구현을 제공하는 것은 상위 컴포넌트의 책임입니다.

이를 위해 폼 제출 로직을 api 모듈에 위임하는 연결된 버전의 LoginForm을 생성합니다.

import api from "~/common/api";

const ConnectedLoginForm = () => {
  const handleSubmit = async (email, password) => {
    await api.login(email, password);
  };

  return <LoginForm onSubmit={handleSubmit} />;
};

ConnectedLoginForm 컴포넌트는 api와 LoginForm 사이의 접착제 역할을 하며 서로 완전히 독립적입니다. 복잡한 의존성이 없기 때문에 깨지는 것에 대해 걱정하지 않고 독립적으로 반복하고 테스트할 수 있습니다. 그리고 LoginForm과 api가 모두 합의된 공통 추상화를 준수하는 한, 전체 애플리케이션은 예상대로 계속 작동할 것입니다.

의존관계 역전 원칙은 애플리케이션의 서로 다른 컴포넌트 간의 결합을 최소화하는 것을 목표로 합니다. 아시다시피, 최소화는 개별 컴포넌트에 대한 책임 범위를 최소화하는 것부터 컴포넌트 간의 인식 및 의존성을 최소화하는 것까지 모든 SOLID 원칙 전반에 걸쳐서 반복되는 주제입니다.

[!WARNING] 주의
SOLID 원칙을 맹목적으로 따르는 것은 오히려 악영향을 주고 오버 엔지니어링된 코드로 이어질 수 있습니다. 따라서 충분한 고려가 항상 필요합니다.

레퍼런스

javascript 파싱과 실행 과정

Sun, 09 Jun 2024 00:00:00 GMT

용어 정리

바이너리 코드(binary code)

컴퓨터가 인식할 수 있는 0과 1로 구성된 이진수로 표현된 코드를 의미합니다.

기계어(machine language)

컴퓨터의 CPU가 직접 이해하고 실행할 수 있는 바이너리 코드

CPU가 직접 실행할 수 있는 유일한 형태의 코드
바이너리 코드로 이루어져 있습니다.
어셈블리어보다 더 저수준의 언어로, 0과 1의 비트 패턴으로 구성됩니다.
기계어가 바이너리 코드로 이루어졌을 뿐이지 모든 바이너리 코드가 기계어인 것은 아닙니다. ( 바이너리 코드 != 기계어)

- 기계어는 특정한 언어가 아닙니다. - 단지 CPU제조사에서 CPU를 만들 때 해당 CPU에서 사용하는 명령어 집합을 공개하는데, 이것을 ‘기계어’라고 부를 뿐입니다. - 때문에 CPU가 변경되면 기계어가 달라집니다. 같은 동작을 하는 명령어지만 완전히 다른 0과 1의 나열이 될 수 있다는 말입니다.

기계어는 컴파일러나 어셈블러에 의해 자동으로 생성됩니다.
예시

10110000 00000001 ; MOV AX, 1을 기계어로 표현
00000001 11000011 ; ADD AX, BX를 기계어로 표현
11101001 11000000 ; JMP LABEL을 기계어로 표현

어셈블리어(Assembly Language)

기계어와 일대일 대응이 되는 컴퓨터 프로그래밍의 저급 언어

기계어에서 한 단계 위의 언어
기계어 명령어에 대한 사람이 읽을 수 있는 기호적 표현입니다.
기계어의 이진 명령어를 사람이 이해하기 쉬운 형태로 표현합니다.

구성:
- 명령어(OpCodes): ADD, SUB, MOV, JMP 등 기계어 명령어를 대체하는 기호.
- 레지스터(Registers): CPU의 데이터 저장소를 나타내는 기호 (예: AX, BX, CX).
- 주소 및 상수(Addressing and Constants): 메모리 주소나 상수를 나타내는 기호.
사용:
- 어셈블리어는 주로 시스템 프로그래밍, 임베디드 시스템, 디바이스 드라이버 개발에 사용됩니다.
- 각기 다른 CPU 아키텍처에 맞춰 어셈블리어 코드가 작성됩니다.
예시:

MOV AX, 1        ; 레지스터 AX에 1을 저장
ADD AX, BX       ; 레지스터 AX에 BX 값을 더함
JMP LABEL        ; LABEL로 점프

가상 머신(Virtual Machine, VM)

물리적인 컴퓨터와는 달리 소프트웨어로 구현된 (가상의) 컴퓨터 시스템

중간 언어를 실행하기 위한 소프트웨어나 하드웨어 기반의 가상적 실행 환경을 의미합니다.

예를 들어 script.py 라는 고급 언어로 작성 되어 있는 고급 언어를 실행시키고 싶다면,

터미널에서

python script.py

파이썬의 인터프리터 (가상머신) 를 이용해서 고급언어를 중간 언어로 번역 시키고 , 가상 머신에서 실행시킬 수 있습니다.

추상 구문 트리(abstract syntax tree, AST)

프로그래밍 언어의 소스 코드를 구조화한 트리 형태의 표현입니다. 이는 컴파일러나 인터프리터가 소스 코드를 이해하고 처리하기 위해 사용하는 중간 표현 단계입니다.

AST는 코드의 문법적인 구조를 추상화하여 표현합니다. 여기서 ‘추상화’는 실제 코드의 구체적인 문법 요소들을 제거하고, 그 핵심적인 구조와 의미만을 남기는 과정을 말합니다. 예를 들어, 괄호나 세미콜론 같은 구체적인 구문 요소들은 AST에서는 생략됩니다.

보통 파싱(Parsing) 을 소스코드를 불러온 후 AST로 변환하는 과정이라고 표현합니다.

바이트 코드(Bytecode)

고급언어로 작성된 소스코드를 가상 머신이 이해할 수 있는 중간 코드로 컴파일한 것을 말합니다.

CPU가 이해할 수 있는 언어가 바이너리 코드라면 바이트 코드는 가상 머신이 이해할 수 언어입니다.
CPU가 아닌 가상 머신에서 이해할 수 있는 코드를 위한 이진 표현법입니다. (즉, 가상 머신이 이해할 수 있는 0과 1로 구성된 이진코드를 의미.)

컴파일 (Compile)

(고수준의) 프로그래밍 언어(소스코드)를 기계어 혹은 기계어와 유사한 low level까지 해석하는 과정입니다.

즉, 컴파일이 된 이후의 코드는 언어에 따라 바이트 코드인 경우도 있고 기계어로 직접 변환이 되는 경우도 있습니다.

ex) C -> Assembly
Java -> bytecode

컴파일러(Compiler)

(고수준의) 프로그래밍 언어를 기계어로 빠르게 컴파일할 수 있도록 미리 번역해둔 프로그램

트랜스파일 (Transpile)

프로그래밍 언어(소스코드)를 비슷한 수준의 추상화를 가진 다른 언어로 변환하는 과정입니다.

ex) C++ -> C
ES6 -> ES5 (Babel)
typescript / coffescript -> javascript
sass / scss -> css

object code

기계어나 기계어 수준의 바이너리 코드로 해석된 코드를 의미합니다.

인터프렛(interpret)과 인터프리터(Interpreter)

(고수준의) 프로그래밍 언어를 각 행마다 해석하며 기계어로 번역 및 즉시 실행하는 방식을 뜻합니다. 인터프리터는 이 인터프렛이 가능하게 해주는 프로그램을 의미합니다. 인터프리터는 런타임에 코드를 한 줄씩 읽고 실행하며, ‘실행 파일’은 만들지 않습니다.

인터프리터 언어 vs 컴파일 언어

인간이 읽기 편한 고수준의 프로그래밍 언어를 컴퓨터가 읽을 수 있게 저수준의 기계어로 변환하기 위해 대표적으로 2가지가 있다고 보면 됩니다. 컴파일러와 인터프리터 방식이 바로 그것입니다.

인터프리터 언어

인터프리터 언어는 프로그램을 한 줄씩 읽어 들이면서 즉시 실행하는 방식입니다.
인터프리터는 런타임에 소스 코드를 직접 해석하고 실행하므로, 컴파일 과정이 필요하지 않습니다. 이는 개발 과정에서 빠른 피드백을 받아 실시간으로 코드를 수정하거나 디버깅할 수 있다는 장점이 있습니다.
인터프리터 언어는 동적 타이핑을 지원하여 변수의 타입을 명시하지 않아도 되므로 코드 작성이 간결해집니다.
컴파일러와 같은 오브젝트 코드 생성과정이 없기 때문에 메모리 효율이 좋다.
한번에 한 문장씩 해석하기 때문에 프로그램을 실행시키고 한 문장씩 해석될때 오류를 만나게 되면 바로 프로그램을 중지하게 됩니다. 즉, 런타임이 되어서야 오류 발견이 가능해서 사용성에 문제가 될 수 있습니다.
인터프리터 언어는 실행 속도가 상대적으로 느리다는 단점이 있습니다. 매 실행 시마다 소스 코드를 해석해야 하므로, 대규모 프로그램이나 복잡한 연산을 수행할 때는 성능 저하가 발생할 수 있습니다.
또한, 소스 코드가 그대로 노출되므로 코드 보안에 취약할 수 있습니다.

컴파일 언어

컴파일러 언어는 소스 코드를 기계어로 변역하는 컴파일 과정을 거칩니다.
컴파일러는 소스 코드 전체를 한 번에 분석하고, 최적화를 수행한 후 실행 파일을 생성합니다.
이렇게 개발 과정에서 컴파일 시간이 소요되므로, 인터프리터 언어에 비해 개발 속도가 느릴 수 있습니다.
하지만, 컴파일러는 전체 코드를 검사한 후에 오류 메시지를 생성하기 때문에 프로그램 실행 전에 오류를 발견 할 수 있습니다.
또한 컴파일 과정을 거쳐 생성된 실행 파일은 컴퓨터에서 직접 실행될 수 있으므로 전체 실행 시간만 따지고 보면 인터프리터 언어보다 빠릅니다.
컴파일 된 코드는 기계어로 변환되어 소스 코드의 로직이 직접 노출되지 않아 소스 코드를 공개하지 않아도 실행 파일을 배포할 수 있습니다.

위 비교 내용을 간단한 표로 정리하면 다음과 같습니다.

	인터프리터	컴파일러
개발 편의성	- 코드를 수정하고 즉시 실행할 수 있다. - 보통 동적 타이핑을 지원하여 코드 작성이 간결해진다.	- 코드를 수정하고 실행하려면 컴파일을 다시 해야 한다. - 보통 정적 타이핑을 지원하여 엄격한 타입 작성을 필요로 한다.
실행 속도	느리다	빠르다
보안	프로그램의 코드가 유출될 수 있다.	프로그램의 코드가 유출되지 않는다.
오류 검출	런타임이 되어서야 오류를 검출할 수 있다.	런타임이 아닌 컴파일 하는 과정에서 오류를 검출할 수 있다.

JIT vs 인터프리터

동적 컴파일 이라고도 불리는 JIT(Just in time)는 컴퓨터 프로그램의 런타임 성능을 개선하기 위해서 사용되는 기술입니다.

JIT는 인터프리터와 정적 컴파일을 혼합한 방식으로 생각할 수 있습니다. 프로그램 실행 시점에서 인터프리터 방식으로 기계어 코드를 생성하면서 그 코드를 캐싱하여, 같은 함수가 여러 번 불릴 때마다 매번 기계어 코드를 생성하는 것을 방지합니다.

바이트코드에서 번역된 기계어는 캐시에 저장되기 때문에 재사용시 다시 번역할 필요가 없습니다. 또한 코드가 반복된다면 재사용할 수 있으므로 시간이 단축됩니다.

동적 컴파일의 단점

동적 컴파일은 정적 컴파일의 단점(실행 환경이 바뀌면 동작된다는 보장이 없음)을 보완합니다. 실행 시 컴파일하기 때문에 실행 환경에 따라 동작을 보장할 수 있으며, 컴파일을 환경에 맞게 최적화할 수 있습니다.

하지만 이러한 특징으로 인해 컴파일된 내용을 메모리에 상주시켜야 하므로 메모리 사용량이 늘어나게 됩니다. 또한 수행 시 컴파일을 병행하므로 실행 지연이 발생합니다. 이러한 단점을 보완하기 위해 적응형 컴파일이 등장했습니다.

적응형 컴파일(Adaptive Compilation)

JIT 컴파일러의 단점을 보완하기 위한 방식으로, 코드가 사용되었을 때 즉시 컴파일하는 것이 아니라, 여러 번 호출된 후 지연시켜 컴파일을 수행하는데 이를 Lazy Compilation이라 합니다.

자바스크립트 파싱과 실행

1. 자바스크립트 소스코드 -> 바이트 코드

자바스크립트는 기본적으로 text형식이기 때문에, 코드를 실행하기 전에 해석하는 컴파일 과정이 필요합니다. 먼저 소스코드를 파싱하여 중간언어(IR)인 바이트코드(Bytecode) 형태로 변환합니다.

코드를 최소한의 문법적으로 의미있는 조각(=토큰)으로 나누는 토크나이징 (이때 스코프가 결정되므로 자바스크립트는 렉시컬스코프를 가지게 된다.)
토큰에 문법적 의미와 구조를 반영한 트리 구조로 나타내는 AST로 만드는 파싱
VM이 실행할 수 있도록 AST를 바이트코드로 변환하는 컴파일

여기서 AST를 바이트 코드로 변환시키는 주체는 Ignition Interpreter입니다.

바이트 코드 -> 실행

만들어진 바이트 코드를 Ignition interpreter가 실행함으로써 자바스크립트 코드가 실행됩니다.

V8 엔진은 바이트 코드를 실행하면서 코드의 실행 패턴을 모니터링합니다. 자주 실행되는 코드 경로(핫스팟, hotspot)를 감지합니다. 이런 모니터링 과정 자체를 프로파일링이라 부르는 것 같습니다. 수집한 정보를 바탕으로 최적화가 필요한 부분을 식별합니다.

TurboFan 컴파일러를 통해 핫스팟으로 감지된 즉, 자주 실행되는 코드 경로를 최적화 기법을 사용하여 기계어로 컴파일합니다. 최적화된 기계어 코드가 생성되면 캐시에 저장됩니다.

저장된 기계어 코드는 CPU가 이해하고 처리할 수 있는 저수준의 코드이기에 직접 실행될 수 있어 성능이 향상될 수 있습니다.

TurboFan Compiler의 최적화 기법

히든 클래스(Hidden Class)
쉽게 말해 객체를 정적 언어에서의 클래스처럼 다뤄 이미 만들어진 클래스의 구조를 전이 받는 방식이라고 할 수 있습니다.
이는 자바스크립트의 동적 프로퍼티 변경에 대응하기 위한 방법이라고 볼 수 있습니다.

히든 클래스의 동작 방식을 간단하게 보자면,

객체 생성:
- 객체가 생성될 때 V8 엔진은 기본 히든 클래스를 할당합니다.

let obj = {}; // obj는 기본 히든 클래스를 가짐 (C0)

속성 추가:
- 객체에 새로운 속성이 추가되면, V8 엔진은 기존 히든 클래스를 복사하여 새로운 속성이 포함된 새로운 히든 클래스를 생성합니다.

obj.x = 10; // obj의 히든 클래스가 C0에서 C1으로 전이

속성 변경:
- 추가적인 속성이 계속 추가되거나 변경될 때마다, 히든 클래스는 계속 전이됩니다.

obj.y = 20; // obj의 히든 클래스가 C1에서 C2로 전이

히든 클래스를 사용하면 빠른 속성 접근이 가능하다는 장점이 있습니다. 동일한 히든 클래스를 가진 객체는 동일한 메모리 레이아웃을 가지므로, 속성 접근 시 오프셋 계산이 빨라집니다.

인라인 캐싱(Inline Caching)
자주 사용되는 메서드 호출이나 속성 접근을 캐싱하여 성능을 최적화하는 기법입니다. 코드가 만약 hello()와 같은 함수의 호출부라면 이걸 function hello () { ... }와 같이 함수의 내용으로 바꿔버리는 것입니다. 말 그대로 캐싱(Caching)

위에서 쭉 얘기한 V8 엔진의 고수준 아키텍쳐를 보자면 아래와 같습니다.

레퍼런스

vite를 사용하는 이유

Sat, 01 Jun 2024 00:00:00 GMT

TL;DR

빠른 개발 환경과 유연한 프로덕션 환경의 조합

Vite는 개발 환경과 프로덕션 환경에서 다른 방식으로 번들링을 처리한다.

개발 환경에서는 Vite가 ES Modules(ESM)를 이용하여 번들링 없이 빠른 모듈 재로딩(HMR, hot module replacement)을 제공한다. 서버가 클라이언트에게 필요한 모듈만 전송하고, 브라우저가 이 모듈들을 병렬로 로딩하게 함으로써 가능하다.

프로덕션 환경에서는 ESBuild를 빠른 변환과 미니파이케이션(Minification)을 위해 사용되고, 최종적으로 Rollup을 사용하여 번들링을 수행한다. Rollup은 트리 쉐이킹(tree shaking을 지원하며, 작은 번들(codesplitting)을 생성하고, 효율적인 코드 분할을 가능하게 한다. 이는 최종적으로 더 빠른 로딩 시간과 더 나은 성능을 제공한다.

개요

vite는 ESBuild의 단점(webpack, rollup처럼 유연하지 못하다. es6이하의 문법을 아직 100% 지원하지는 않는다.)을 보완시킨 빌드 툴이다.
Vue.js의 창시자인 Evan You가 만든 frontend build tool이다.
관련있는 번들러 webpack, esbuild, rollup에 대해서도 알아보자.

사전지식(webpack, esbuild와 rollup에 대하여)

vite는 번들링 과정에 esbuild와 rollup을 사용하므로 이에 대해 반드시 알고 넘어가야 할 필요가 있다. 그리고 vite가 webpack을 사용하지는 않지만, 기존의 대세 번들러 webpack에 대해서도 간단하게라도 비교할 수 있게 다뤄보자.

webpack

2012년 등장

webpack의 정체성은 번들러의 순수한 목적인 ”통합“에 있다.

오래된 번들러인만큼 그만큼 정보의 풀이 넓고 에러 해결법도 쉽게 찾아볼 수 있다.
설정 또한 굉장히 쉽다. 하나의 설정 파일에서 원하는 번들이 생성 될 수 있도록 컨트롤할 수 있다. entry와 output을 명시하고 어떤 plugin과 loader로 파일들을 다룰 건지 명시하면 된다.

예시 파일을 보자

// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  entry: {
    home: './pages/home.js',
  },
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: '[name].bundle.js',
  },
  module: {
    rules: [
      {
        test: /\.js
$
/,
        exclude: /node_modules/,
        use: ["babel-loader"],
      },
    ],
  },
  plugins: [new HtmlWebpackPlugin()],
};

webpack의 꽃은 code splitting이다.

code splitting은 파일들을 한 개가 아니라 여러 개의 번들 파일들로 분리해서 병렬로 스크립트를 로드할 수 있게 해준다. 이를 통해 구동될 필요가 없는 코드를 분리해서 lazy loading을 통해 페이지 로딩 속도를 개선시킬 수 있다.

아, 그리고 참고로 code splitting 지원은 이제 웬만한 builder들은 이제 다 기본적으로 장착하고 나온다(rollup, esbuild, parcel ). 그럼에도 불구하고 webpack이 가장 유명하고 최초라서 뜨지 않았나 싶다. 어쨌든 code splitting 지원이 더 이상 웹팩만의 장점은 아니라는 점이다.

강력한 개발 서버 Hot Module ReplaceMent(HMR)

HMR은 개발과정에서 소스코드의 변화를 감지하여 브라우저를 직접 새로고침할 필요가 없이 변화를 바로 반영해준다. 이 덕분에 개발자는 빠른 개발이 가능해졌다.

그런데 마찬가지로 HMR은 웬만한 번들러들은 이제 다 지원한다. 단지 최초가 Webpack이었을 뿐…

Rollup

2017년 등장

Rollup의 정체성은 ”확장“이다.

홈페이지에 들어가보면 Compile small pieces of code into something larger and more complex라고 적혀있다. 작은 코드 조각들을 더 크고 복잡한 무엇인가로 컴파일해준다는 뜻이다. 그 크고 복잡한 무엇인가는 애플리케이션이나 라이브러리가 될 수 있겠다.

rollup 설정은 webpack과 아주 유사하다.

// rollup.config.js
import commonjs from '@rollup/plugin-commonjs';
import resolve from '@rollup/plugin-node-resolve';
import { terser } from 'rollup-plugin-terser';

const production = !process.env.ROLLUP_WATCH;

export default {
  input: 'src/main.js',
  output: {
    file: 'public/bundle.js',
    format: 'iife',
    sourcemap: true,
  },
  plugins: [
    resolve(),
    commonjs(),
    production && terser(),
  ],
};

🥊 vs Webpack

webpack은 내부적으로 Commonjs를 사용하고 rollup은 typescript(ES6)를 사용한다.
rollup이 webpack보다 조금 더 빠르다. webpack은 모듈들을 함수로 감싸서 평가하는 방식을 사용하고, rollup은 모듈들을 상단으로 호이스팅해서 한번에 평가해서 성능상 이점이 있다.
쓰지 않는 코드를 build 과정에서 털어내어 용량을 줄이는 것을 tree shaking이라고 하는데 기본적으로 ES6 코드에서 제대로 동작한다. 그렇기 때문에 기본적으로 ES6를 쓰는 rollup이 더 가벼운 번들을 생성한다.

esbuild

esbuild의 정체성은 ”빠른 속도“이다.

ESbulid는 2020년에 출시된 차세대 번들러로써, 빠른 성능으로 각광받고 있는 번들러이다. ESbuild가 왜 빠른지에 대해 간단하게 알아보자.

esBuild는 왜 다른 번들러들보다 빠를까?

Go 언어로 작성됨 자바스크립트가 아니라 GO 언어로 작성된 Esbuild는 해당 사이트에서도 강조하고 있듯이 기존의 Webpack, Parcel, rollup 등의 다른 번들러들보다 10 ~ 100배 빠른 속도를 강조하고 있다.
병렬성 Go 언어의 강력한 병렬성을 적극 활용한 알고리즘들을 다수 활용하고 있다.
처음부터 성능을 염두하고 만든 자체 parser이용

4경에서는 esbuild로 파일들을 통합(=사전 번들링)하고 프로덕션 환경에서는 rollup으로 유연하게 번들링 한다.

Vite가 탄생하게 된 배경과 해결방법에 대해서 다뤄보자.

1. 지루할 정도로 길었던 서버 구동

esbuild 사용하여 프리 번들링

vite는 esbuild를 사용하여 사전 번들링을 한다. 다른 번들러들보다 10 ~ 100배 빠르다.

패키지와 소스코드 분리하여 따로 처리

기존의 번들러들은 몇 백개의 javascript 모듈을 갖고 있는 매우 큰 의존성에 대한 번들링 과정이 비효율적이었는데, 개발 중에 자주 변경되지 않는 의존성(패키지)와 소스코드를 따로 처리한다.

위에서 얘기했다시피 vite는 의존성(패키지)을 Esbuild를 통한 사전 번들링으로 해결한다.

그리고 소스코드는 브라우저의 native ES module(Native ESM) 을 이용해 제공하기 때문에 브라우저가 번들러 작업 일부를 수행할 수 있도록 한다. native ES module은 우리가 알고 있는 바로 그 module javascript의 형태를 의미한다. vite는 브라우저가 요청하는 대로 소스코드를 변환하고 제공하기만 하면 된다.

2. 느렸던 소스 코드 갱신

기존의 번들러 기반으로 개발을 진행하면, 소스 코드를 업데이트 했을 때 처음부터 번들링 과정을 다시 거쳐야 했다. 이에 따라서 서비스가 커질수록 당연히 소스 코드 갱신 시간 또한 길어졌다.

‘모든 파일’을 번들링하고, 이를 다시 웹 페이지에서 불러오는 것은 굉장히 비효율적인 것이다. 이를 해결하기 위해 HMR(Hot Module Replacement) 라는 대안이 나왔던 것인데, vite는 이를 번들러가 아닌 ESM을 이용해 수행한다. 예를 들어 어떤 모듈이 수정되면 vite는 그저 수정된 모듈과 관련된 부분만을 교체할 뿐이다.

또한 HTTP 헤더를 활용해서 전체 페이지의 로드 속도를 높인다. 필요에 따라 의존성을 캐시하여 요청 횟수를 최소화하여 페이지 로딩을 빠르게 만든다.

3. 빌드 최적화

css 코드 분리

비동기적으로 불러와지는 청크 내에 css 코드가 포함된 경우 이를 자동으로 파일로 분리해놓는다. 나중에 해당 청크 파일을 불러올 때 <link>태그를 이용해 분리된 css 코드를 불러오게끔 하며, 이 불러온 css 코드가 모두 계산된 후에 청크를 렌더링하도록 한다. 이렇게 복잡한 과정을 거치는 이유는 이 과정을 통해 CSS가 렌더링될 때 화면이 잠깐 반짝이는 FOUC 현상을 회피할 수 있게 되기 때문이다.

Preload Directives Generation

vite는 빌드 시 Direct Import 구문에 대해 <link ref="modulepreload"> 디렉티브를 이용해 미리 모듈을 캐싱하도록 자동으로 변환한다. 덕분에 해당 모듈을 필요로 하는 경우 이를 바로 사용할 수 있게 된다.

Async Chunk Loading Optimization

(여기서부터는 공식문서에 적힌 내용)

빌드 시, 때때로 Rollup은 “공통(Common)” 청크 파일을 생성합니다. 보통 두 개 이상의 모듈에서 공유되는 청크가 이러한데, 이를 Dynamic Import를 이용해 불러오는 경우 다음과 같은 상황이 발생됩니다. (브라우저는 A와 B 모듈을 필요로 하며(Dynamic Import), A와 B 모듈은 공통적으로 모듈 C를 필요로 하는 경우(Direct Import)입니다. - 옮긴이)

최적화되지 않은 경우, 먼저 비동기적으로 A 청크가 불러와지게 되고, A 청크가 모두 파싱된 후에서야 C 청크가 필요하다는 사실을 알게 되기에 다음과 같은 네트워크 왕복이 필요합니다.

Entry ---> A ---> C

vite는 Preload 스텝을 이용해 A를 가져올 때 C 청크를 병렬적(Parallel)으로 가져올 수 있도록 Dynamic Import 구문을 자동으로 재작성합니다.

Entry ---> (A + C)

vite는 모든 Direct Import 구문에 대해 Preload 하도록 함으로써,** 쓸 데 없이 낭비되는 네트워크 왕복을 줄이도록 구성합니다.

레퍼런스

(번역) ‘Create React App 권장을 Vite로 대체’ PR 대한 Dan Abramov의 답변
공식 문서(한글화 100%) - https://ko.vitejs.dev/guide/why.html
https://github.com/vitejs/vite/discussions/7622
https://velog.io/@minboykim/Vite-%EC%99%9C-%EC%93%B0%EB%8A%94%EA%B1%B0%EC%A7%80
https://esbuild.github.io/
https://rollupjs.org/
https://bepyan.github.io/blog/2023/bundlers
관련 영상
1. https://youtu.be/j541SGnGcew?si=PkdvGM3VcQt6WlfB(배포와 번들러의 기초 + vite에 대해서 - 시나브로 자바스크립트)
2. https://www.youtube.com/watch?v=UdTD_NAWxyE&list=PLqbk_vAq_YQZO6Pqf39dnd-AwC2dcFH3q&index=5(위 영상 이어지는 내용 : vite 조금 더 뜯어보기 - 시나브로 자바스크립트)
3. https://youtu.be/iX3Nu1FcZKA?si=rKg0rX03LDyr_HFG - vite를 간단하게 설명(5분) - 코딩애플

tanstack query의 키 관리 기법

Thu, 30 May 2024 00:00:00 GMT

개요

tanstack query는 유니크한 query key를 통해서 쿼리를 관리합니다. 그런데 primitive type이 아닌 reference type을 사용해도 실제 데이터가 변경되지 않는 이상 재요청을 보내지 않습니다.

useQuery({ queryKey: ['user', [userId] ], ...})

const a = [1, 2, 3];
const b = [1, 2, 3];

console.log(a === b); // ?

자바스크립트를 공부한 사람이라면 위 코드에서 false가 로그로 찍힌다는 것을 알 수 있습니다.

리액트의 렌더링 때마다 새로운 배열값이 queryKey에 할당될 것입니다. 매번 새로운 값이 들어오는 셈이니 당연히 매번 데이터가 변경, 새로운 키라고 인식하겠죠.
하지만 useQuery를 한 번이라도 사용했다면, 당연히 그렇게 동작하지 않는다는 것을 알 수 있습니다.
이를 통해 tanstack query가 내부적으로 queryKey에 할당된 값의 메모리 주소를 그대로 비교해서 데이터의 변경을 캐치하는 것은 아님을 예상할 수 있겠죠. 무엇인가 이를 위한 특별한 로직이 있는 것입니다.

hashKey 함수

정답은 hashKey 라는 간단한 함수에 있었습니다. hashKey함수를 포함하여 내부적으로 사용하는 함수의 코드까지 가져와봤습니다.

/**
 * Default query & mutation keys hash function.
 * Hashes the value into a stable hash.
 */
export function hashKey(queryKey: QueryKey | MutationKey): string {
  return JSON.stringify(queryKey, (_, val) =>
    isPlainObject(val)
      ? Object.keys(val)
          .sort()
          .reduce((result, key) => {
            result[key] = val[key];
            return result;
          }, {} as any)
      : val,
  );
}

function hasObjectPrototype(o: any): boolean {
  return Object.prototype.toString.call(o) === '[object Object]';
}

// Copied from: https://github.com/jonschlinkert/is-plain-object
export function isPlainObject(o: any): o is object {
  if (!hasObjectPrototype(o)) {
    return false;
  }

  // If has no constructor
  const ctor = o.constructor;
  if (ctor === undefined) {
    return true;
  }

  // If has modified prototype
  const prot = ctor.prototype;
  if (!hasObjectPrototype(prot)) {
    return false;
  }

  // If constructor does not have an Object-specific method
  if (!prot.hasOwnProperty('isPrototypeOf')) {
    return false;
  }

  // Handles Objects created by Object.create(<arbitrary prototype>)
  if (Object.getPrototypeOf(o) !== Object.prototype) {
    return false;
  }

  // Most likely a plain Object
  return true;
}

JSON.stringify()의 두 번째 인자 활용

hashKey 함수의 코드를 보면 JSON.stringify 메서드의 두 번째 인자를 활용한 것을 볼 수 있습니다.

mdn에 따르면, JSON.stringify의 문법은 다음과 같습니다.

let json = JSON.stringify(value, [replacer, space]);

value 인코딩 하려는 값
replacer JSON으로 인코딩 하길 원하는 프로퍼티가 담긴 배열. 또는 매핑 함수 function(key, value)
space 서식 변경 목적으로 사용할 공백 문자 수

두 번째 인자에 대한 좀 더 자세한 설명을 하자면 다음과 같습니다.

두 번째 인자는 함수나 혹은 JSON화 하려는 객체의 속성들을 배열로 넘겨야 한다.
JSON으로 인코딩 하길 원하는 프로퍼티가 담긴 배열. 또는 매핑 함수 function(key, value)형태가 될 수 있다.
재귀적으로 처리하기 때문에 중첩된 프로퍼티도 처리 가능

다시 hashKey함수 코드로 돌아가 보겠습니다.

/**
 * Default query & mutation keys hash function.
 * Hashes the value into a stable hash.
 */
export function hashKey(queryKey: QueryKey | MutationKey): string {
  return JSON.stringify(queryKey, (_, val) =>
    isPlainObject(val)
      ? Object.keys(val)
          .sort()
          .reduce((result, key) => {
            result[key] = val[key];
            return result;
          }, {} as any)
      : val,
  );
}

두 번째 인자로 콜백함수를 넣어준 것을 알 수 있습니다. 그리고 sort를 통해 plainObject라면 정렬을 하는 코드가 있네요.

이를 통해 우리가 만약 아래와 같이 두 가지 방식으로 queryKey를 지정하여 stringified 되었다고 해도 정렬이 되어 동일하게 취급될 수 있음을 알 수 있습니다.

useQuery({ queryKey: ['user', { some: 1, something: 2} ], ...})

useQuery({ queryKey: ['user', { something: 2, some: 1 } ], ...})

결론

queryKey의 비교는 stringified된 string type 단에서 비교된다.
내부적으로 hashKey라는 함수를 사용하는데 JSON.stringifiy 메서드의 두 번째 인자 replacer를 활용하여 정렬을 통해 정확한 키의 비교를 수행한다.

레퍼런스

tanstack query의 리렌더링 최적화 기법

Sun, 26 May 2024 00:00:00 GMT

공식 문서에 나와있는 structural sharing에 대한 설명

structural sharing React Query uses a technique called “structural sharing” to ensure that as many references as possible will be kept intact between re-renders. If data is fetched over the network, usually, you’ll get a completely new reference by json parsing the response. However, React Query will keep the original reference if nothing changed in the data. If a subset changed, React Query will keep the unchanged parts and only replace the changed parts.

Note: This optimization only works if the queryFn returns JSON compatible data. You can turn it off by setting structuralSharing: false globally or on a per-query basis, or you can implement your own structural sharing by passing a function to it.

구조적 공유 React Query는 ‘구조적 공유’라는 기술을 사용하여 재렌더링 사이에 가능한 한 많은 참조가 그대로 유지되도록 합니다. 네트워크를 통해 데이터를 가져올 경우, 일반적으로 응답을 JSON 파싱함으로써 완전히 새로운 참조를 얻게 됩니다. 하지만 React Query는 데이터에 변동이 없다면 원래의 참조를 유지합니다. 일부 데이터가 변경된 경우, React Query는 변경되지 않은 부분은 유지하고 변경된 부분만 교체합니다.

참고: 이 최적화는 queryFn이 JSON 호환 데이터를 반환할 때만 작동합니다. 구조적 공유를 전역적으로 또는 쿼리별로 false로 설정하여 끌 수 있으며, 함수를 전달하여 자체적인 구조적 공유를 구현할 수도 있습니다.

위 말을 요약하자면, 쉽게 말해서 쿼리 결과들에 대한 레퍼런스가 데이터가 실제로 변경이 됐을 때만 변경되게끔 만든다는 뜻입니다.

Structural Sharing를 통한 최적화

React Query는 새로운 데이터를 만들 때 가능한 한 기존의 데이터를 유지하려고 합니다. 아래 코드와 같이 응답받은 데이터가 있을 때,

[
  { "id": 1, "name": "Learn React", "status": "active" },
  { "id": 2, "name": "Learn React Query", "status": "todo" }
]

서버에서 id 1에 대한 값이 업데이트되었다면, React Query는 아래 코드와 같이 모든 데이터를 교체하지 않고 변경된 값만 교체하여 기존의 데이터는 유지합니다.

[
- { "id": 1, "name": "Learn React", "status": "active" },
+ { "id": 1, "name": "Learn React", "status": "done" },
  { "id": 2, "name": "Learn React Query", "status": "todo" }
]

React Query는 이전 데이터를 유지함으로 변경되지 않은 데이터를 사용하는 컴포넌트에서는 리렌더링이 발생하지 않도록 최적화합니다. 기존의 데이터를 유지하지 않고 항상 새로운 데이터로 사용하기 위해서는 structuralSharing 옵션을 false로 설정하면 됩니다.

어떻게 이게 가능한 것일까요?

const a = [1, 2, 3]
const b = [1, 2, 3]

console.log(a === b) // ?

자바스크립트를 공부한 사람이라면 위 코드에서 false가 로그로 찍힌다는 것을 알 수 있습니다.

네트워크를 통해 데이터를 가져올 경우 일반적으로는 매번 참조주소값이 달라지므로 사실 상 매번 다른 데이터를 받아오는 것입니다. 리액트 쿼리는 어떤 방법으로 불필요한 리렌더링을 최소화했을까요?

궁금해서 tanstack query 내부에서 동작하는 코드를 찾아봤습니다. 정답은 replaceEqualDeep 함수에 있었습니다.

replaceEqualDeep함수 내부에서 사용하는 관련된 함수들까지 복사해서 가져와봤습니다.

/* eslint-disable no-prototype-builtins */
export function isPlainArray(value: unknown) {
  return Array.isArray(value) && value.length === Object.keys(value).length;
}

function hasObjectPrototype(o: any): boolean {
  return Object.prototype.toString.call(o) === '[object Object]';
}

// Copied from: https://github.com/jonschlinkert/is-plain-object
export function isPlainObject(o: any): o is object {
  if (!hasObjectPrototype(o)) {
    return false;
  }

  // If has no constructor
  const ctor = o.constructor;
  if (ctor === undefined) {
    return true;
  }

  // If has modified prototype
  const prot = ctor.prototype;
  if (!hasObjectPrototype(prot)) {
    return false;
  }

  // If constructor does not have an Object-specific method
  if (!prot.hasOwnProperty('isPrototypeOf')) {
    return false;
  }

  // Handles Objects created by Object.create(<arbitrary prototype>)
  if (Object.getPrototypeOf(o) !== Object.prototype) {
    return false;
  }

  // Most likely a plain Object
  return true;
}

/**
 * This function returns `a` if `b` is deeply equal.
 * If not, it will replace any deeply equal children of `b` with those of `a`.
 * This can be used for structural sharing between JSON values for example.
 */
export function replaceEqualDeep<T>(a: unknown, b: T): T;
export function replaceEqualDeep(a: any, b: any): any {
  // a와 b가 primitive type 혹은 a와 b가 같은 참조값이면 a를 반환
  if (a === b) {
    return a;
  }

  const array = isPlainArray(a) && isPlainArray(b);

  // 둘 다 배열이거나 둘 다 plain object면
  if (array || (isPlainObject(a) && isPlainObject(b))) {
    const aItems = array ? a : Object.keys(a);
    const aSize = aItems.length;
    const bItems = array ? b : Object.keys(b);
    const bSize = bItems.length;
    // 복사본을 저장할 배열 또는 object
    const copy: any = array ? [] : {};

    let equalItems = 0;

    for (let i = 0; i < bSize; i++) {
      const key = array ? i : bItems[i];
      // (배열 aItems에 있는 key이거나 a,b 둘 다 배열이고) && a[key]와 b[key]가 undefined이면
      if (((!array && aItems.includes(key)) || array) && a[key] === undefined && b[key] === undefined) {
        // 복사본에 해당 키의 값은 undefined로 저장
        copy[key] = undefined;
        // 둘 다 undefined로 같기 때문에 equalItems++
        equalItems++;
      } else {
        // 값이 undefined가 아니면 재귀적으로 replaceEqualDeep 호출
        copy[key] = replaceEqualDeep(a[key], b[key]);
        // 실질적으로 여기서 deep equal한지 확인
        // replaceEqualDeep에서 아래 return 문에서 a가 나왔으면 바로 밑 조건문 통과 equalItems++
        if (copy[key] === a[key] && a[key] !== undefined) {
          equalItems++;
        }
      }
    }

    // bSize가 0이거나 for문 전부 다 순회했을 때 aSize와 equalItems가 같으면 a를 반환
    return aSize === bSize && equalItems === aSize ? a : copy;
  }

  // a와 b가 다른 타입 혹은 다른 값일 경우 b를 반환
  return b;
}

코드의 핵심은 nested된 모든 프로퍼티까지 비교하여 변경된 부분만을 새로운 b로 교체하고 그렇지 않다면 a를 활용하는 것입니다. (a와 b가 완전 동일하다면 a, 일부만 변경되었다면 copy, 완전 다르다면 b를 반환하게 되는 로직입니다.) 재귀 함수를 통해서 이를 구현한 것을 확인할 수 있습니다.

이런 방식으로 리액트 쿼리는 실제로 데이터가 변경되었을 때만 레퍼런스가 변경되도록 할 수 있었던 것입니다.

[!TIP] 위 코드가 이해가 안 될 경우 간단한 중첩 객체를 대입시켜서 로직을 따라가면 이해하기 쉽다.

레퍼런스

accessToken과 refreshToken 안전하게 관리하기

Tue, 23 Apr 2024 00:00:00 GMT

개요

토큰 인증 방식에서 주로 사용되는 방식인 accessToken과 refreshToken을 역할을 간단하게 알아보고 각각 어떻게 관리해야 안전한 방식인지 살펴보도록 하겠습니다.

AccessToken

AccessToken은 유저에게 특정 권한을 주기 위한 목적으로 사용되는 토큰을 의미합니다. AccessToken에는 유저에 대한 정보를 암호화한 문자열이 담겨있습니다.

아무런 장치 없이 단독으로 사용하면 안전성 문제가 생길 수도 있습니다. 토큰의 만료 기간을 길게 잡으면 토큰을 누군가 가로챘을 때 더 오랫동안 특정 권한을 갖는 유저 행세를 할 수 있기 때문에 위험합니다. 그렇다고 해서 만료 기간을 짧게 잡으면 이메일과 비밀번호로 인증을 너무 자주 해야 해서 유저에게 귀찮을 일이 될 수 있고 위험할 수 있습니다.

이 문제를 어느 정도 해소하기 위해 refreshToken이라는 것을 같이 사용합니다. refreshToken은 accessToken이 만료됐을 때, 이메일 비밀번호를 사용하지 않고 accessToken을 새롭게 발급받는 데 사용되는 토큰입니다. 어떻게 사용되는지 조금 더 자세히 알아보겠습니다.

RefreshToken

먼저 유저가 로그인을 하기 위해서 리퀘스트로 서버에 이메일과 비밀번호를 보내고, 서버가 이걸 확인했다고 하겠습니다. 그러면 서버는 클라이언트에서 access와 refresh, 두 가지의 토큰을 보내줄 수 있습니다.

Access 토큰이 소유자가 특정 권한을 가질 수 있게 하는 토큰이라면, refresh 토큰은 이메일과 비밀번호를 사용하지 않고 새로운 access 토큰은 발급받을 수 있게 하는 토큰입니다.

그러니까 access 토큰을 사용하다가 만료가 돼서 더 이상 리퀘스트를 인증할 수 없게 되는 경우가 생겼다고 할게요. 그럼 클라이언트는 access 토큰을 새롭게 발급받는 URL에 새로운 GET 리퀘스트를 보냅니다. 이때 body에 refresh 토큰을 함께 보내죠. 그럼 서버는 refresh 토큰이 유효한 걸 확인한 후, 새로운 access 토큰을 발급한 후, 리스폰스로 클라이언트에게 돌려줍니다.

일반적으로 refresh 토큰이 access 토큰보다 만료 기간이 더 깁니다. 정말 설정하기 나름이지만 예를 들어 access 토큰의 만료 기간이 10분이면 refresh 토큰은 24시간 이렇게 시간을 설정할 수 있습니다.

access 토큰의 만료 기간이 짧기 때문에 서버로 토큰을 보낼 때 누군가 이 정보를 가로챈다고 해도 최대 10분까지만 다른 유저 행세를 할 수 있습니다. 만약 누군가 가로챈다고 해도 그렇게 오래 사용할 수는 없으니 조금 더 안전하겠죠?

Refresh Token이 탈취당한다면?

그런데 이 Refresh Token 자체가 탈취당한다면 어떻게 할까요? 공격자는 이 토큰의 유효 기간만큼 다시 Access Token을 생성해서 다시 정상적인 사용자인 척 위장할 수 있습니다. 그렇기 때문에 여기서는 서버측의 검증 로직이 필요합니다. 스택오버플로우의 답변을 보면 다음과 같은 방법을 제안하고 있습니다.

데이터베이스에 각 사용자에 1대1로 맵핑되는 Access Token, Refresh Token 쌍을 저장한다.
정상적인 사용자는 기존의 Access Token으로 접근하며 서버측에서는 데이터베이스에 저장된 Access Token과 비교하여 검증한다.
공격자는 탈취한 Refresh Token으로 새로 Access Token을 생성한다. 그리고 서버측에 전송하면 서버는 데이터베이스에 저장된 Access Token과 공격자에게 받은 Access Token이 다른 것을 확인한다.
만약 데이터베이스에 저장된 토큰이 아직 만료되지 않은 경우, 즉 굳이 Access Token을 새로 생성할 이유가 없는 경우 서버는 Refresh Token이 탈취당했다고 가정하고 두 토큰을 모두 만료시킨다.
이 경우 정상적인 사용자는 자신의 토큰도 만료됐으니 다시 로그인해야 한다. 하지만 공격자의 토큰 역시 만료됐기 때문에 공격자는 정상적인 사용자의 리소스에 접근할 수 없다.

이 때 중요한 점은 발급된 토큰 자체는 모든 토큰 기반 인증 방식이 그렇듯이 그냥 그 JWT 문자열 자체로 존재하는 것이기 때문에 클라이언트나 서버측에서 전역적으로 만료시킬 수 있는 개체가 아니라는 점입니다. 그렇기 때문에 토큰의 유효 기간이 지나기 전까지는 토큰을 NoSQL 같은 데이터베이스에 저장하여 관리할 필요가 있습니다.

만약 공격자가 Refresh Token을 탈취해서 Access Token을 먼저 재발급 받는다면?

만약 공격자가 Refresh Token을 탈취해서 정상적인 사용자가 Access Token을 다시 발급받기 전에 자기가 먼저 Access Token을 생성한다면 어떻게 될까요? 이 경우에도 Request 시 Access Token의 충돌이 일어나기 때문에 서버측에서는 두 토큰을 모두 폐기(만료 대신 폐기가 어울리는 용어인 것 같다)해야 할 것입니다. 그래서 ietf 문서에서는 아예 Refresh Token도 Access Token과 같은 유효 기간을 가지도록 하여 사용자가 한 번 Refresh Token으로 Access Token을 발급받았으면 Refresh Token도 다시 발급받도록 하는 것을 권장하고 있습니다.

쉽게 말해서 이전 AccessToken이 만료되지 않았는데 굳이 AccessToken을 재발급받아 새로운 AccessToken으로 요청이 들어온다면 두 AccessToken 모두 폐기 처리를 하고 요청을 받아들이지 않는다는 방식입니다. 이와 매핑되어 있는 RefreshToken도 마찬가지로 폐기처리가 됩니다.

만약 Access Token과 Refresh Token을 둘 다 탈취당한다면?

그럼 만약에 공격자가 Access Token, Refresh Token을 둘 다 탈취한다면 어떻게 할까요? 이 때는 방법이 없습니다. 프론트엔드나 백엔드 로직을 강화하여 토큰이 유출되지 않도록 보완하는 수 밖에 없을 것입니다.

토큰의 저장 장소

서버에서는 NoSQL이나 기타 데이터베이스에 저장할 수 있습니다. 그럼 클라이언트에서는 어디에 저장할 수 있을까요? 브라우저 환경의 경우 흔히 생각하는 방법은 쿠키, 로컬 스토리지 등 다양한 곳이 있지만 스택오버플로우에서는 http-only 속성이 부여된 쿠키에 저장하는 것을 권장하고 있습니다.

http-only 속성이 부여된 쿠키는 자바스크립트 환경에서 접근할 수 없습니다.그래서 XSS나 CSRF가 발생하더라도 토큰이 누출되지 않습니다. 일반 쿠키나 브라우저의 로컬 스토리지는 자바스크립트로 자유롭게 접근할 수 있기 때문에 보안 측면에서는 권장되지 않습니다.

이제 httpOnly 옵션을 통해 브라우저에서 쿠키에 접근하는 것은 방지할 수 있습니다. 하지만 쿠키는 HTTP 헤더를 통해 전송되고, 와이어 샤크 등과 같은 프로그램으로 네트워크 감청을 할 수 있다는 것은 널리 알려진 사실입니다. 이러한 통신 상 정보 유출을 방지하기 위해 HTTPS 프로토콜을 사용하여 데이터를 암호화할 수 있습니다. 그리고 Secure 옵션은 HTTPS 상에서 암호화된 요청일 경우에만 쿠키를 전송하도록 합니다.

레퍼런스

any는 유해한 것으로 고려됩니다. 단 이 경우만 제외하고 말이죠

Mon, 08 Apr 2024 00:00:00 GMT

개요

any는 다들 아시다시피 슈퍼 타입이든 서브 타입이든 고려하지 않고 할당이 가능한 강력하지만 위험한 타입입니다.

사용하게 되면 런타임이 되어서야 에러를 볼 수 있는 위험이 생길 수 있죠.

const myFunction = (input: any) => {
  input.someMethod();
};

myFunction('abc'); // This will fail at runtime!

그래서 any를 사용하는 것은 대부분 유해하기 때문에 권장되지 않습니다. 그러나 any를 예외적으로 사용해야 하는 경우가 있습니다.

Type Argument Constraints

예를 들어 우리가 ReturnType 빌트인 유틸리티 타입을 수행하고 싶다고 가정을 해보겠습니다.

우리는 type 전달인자로 함수 타입을 가지는 제네릭을 생성해야 합니다. any를 쓰지 않도록 제한한다면, 아마도 unknown을 아래와 같이 작성하게 될 것입니다.

type ReturnType<T extends (...args: unknown[]) => unknown> =
  // Not important for our explanation:
  T extends (...args: unknown[]) => infer R ? R : never;

위 코드는 전달인자가 없으면 잘 작동하는 것처럼 보입니다.

const myFunction = () => {
  console.log('Hey!');
};

type Result = ReturnType<typeof myFunction>;
//    ^ type Result = void

그러나 전달인자를 전달하면 에러가 뜨게 됩니다.

const myFunction = (input: string) => {
  console.log('Hey!');
};

type Result = ReturnType<typeof myFunction>;

Type '(input: string) => void' does not satisfy the constraint '(...args: unknown[]) => unknown'.
  Types of parameters 'input' and 'args' are incompatible.
    Type 'unknown' is not assignable to type 'string'.

이는 사실 함수 매개변수 타입을 unknown으로 바꾸면 해결되기는 합니다.

const myFunction = (input: unknown) => {
  console.log('Hey!');
};

type Result = ReturnType<typeof myFunction>;
//    ^ type Result = void

그러나 이 함수는 unknown 전달인자만 허락하는 함수가 되어버렸습니다. 이건 우리가 원하는 방향이 아닙니다. 우리는 어떠한 함수에서라도 정상적으로 작동하기를 원합니다.

여기에 대한 해결법은 any[]를 전달인자 제약사항으로 사용하는 것입니다.:

type ReturnType<T extends (...args: any[]) => any> = T extends (...args: any[]) => infer R ? R : never;

const myFunction = (input: string) => {
  console.log('Hey!');
};

type Result = ReturnType<typeof myFunction>;
//     ^ type Result = void

이제 원하는대로 동작합니다. 우리는 함수가 어떤 타입을 전달인자로 받든 상관하지 않는다고 선언한 것입니다.

이 방식은 안전합니다. 그 이유는 우리가 넓은 타입을 선언한 것이 의도적이기 때문입니다. 우리는 “함수이기만 하면, 함수가 어떤 것을 받든 상관 안 해”라고 말하는 것입니다. 이게 바로 any의 안전한 사용 예시입니다.

Returning Conditional Types From Generic Functions

어떤 곳에서는 TypeScript의 좁아지는 기능이 우리가 원하는 만큼 좋지 않습니다. 조건에 따라 다른 유형을 반환하는 함수를 만들고 싶다고 가정해 보겠습니다:

const youSayGoodbyeISayHello = (input: 'hello' | 'goodbye') => {
  if (input === 'goodbye') {
    return 'hello';
  } else {
    return 'goodbye';
  }
};

const result = youSayGoodbyeISayHello('hello');
//     ^ const result: "hello" | "goodbye"

이 함수는 우리가 원하는대로 작동하지 않고 있어요. 우리는 “goobye”에는 “hello”가 나오고, “hello”에는 “goodbye”가 나오기를 원하고 있습니다. 그러나 현재, result는 hello | goodbye로 타입되어 있습니다.

리턴되는 타입도 런타임 때 로직과 동일하게 미러링 처리하면 될까요?

const youSayGoodbyeISayHello = <TInput extends 'hello' | 'goodbye'>(
  input: TInput,
): TInput extends 'hello' ? 'goodbye' : 'hello' => {
  if (input === 'goodbye') {
    return 'hello';
    // Type '"hello"' is not assignable to type 'TInput extends "hello" ? "goodbye" : "hello"'.
  } else {
    return 'goodbye';
    // Type '"goodbye"' is not assignable to type 'TInput extends "hello" ? "goodbye" : "hello"'.
  }
};

이렇게 해도 에러가 뜹니다. 타입스크립트는 런타임 로직의 조건 타입과 매칭되지 않는 것으로 보입니다.

우리는 이를 as를 활용해서 고칠 수 있습니다. 올바른 조건 타입을 가리키도록 강제화하는 것이죠.

const youSayGoodbyeISayHello = <TInput extends 'hello' | 'goodbye'>(
  input: TInput,
): TInput extends 'hello' ? 'goodbye' : 'hello' => {
  if (input === 'goodbye') {
    return 'hello' as TInput extends 'hello' ? 'goodbye' : 'hello';
  } else {
    return 'goodbye' as TInput extends 'hello' ? 'goodbye' : 'hello';
  }
};

공용 제네릭 타입으로 로직을 추출해서 깔끔하게 만들 수도 있습니다.

type YouSayGoodbyeISayHello<TInput extends 'hello' | 'goodbye'> = TInput extends 'hello' ? 'goodbye' : 'hello';

const youSayGoodbyeISayHello = <TInput extends 'hello' | 'goodbye'>(input: TInput): YouSayGoodbyeISayHello<TInput> => {
  if (input === 'goodbye') {
    return 'hello' as YouSayGoodbyeISayHello<TInput>;
  } else {
    return 'goodbye' as YouSayGoodbyeISayHello<TInput>;
  }
};

그런데 이런 경우에는, as any를 사용하는 것이 더 적합할 수도 있습니다.:

const youSayGoodbyeISayHello = <TInput extends 'hello' | 'goodbye'>(
  input: TInput,
): TInput extends 'hello' ? 'goodbye' : 'hello' => {
  if (input === 'goodbye') {
    return 'hello' as any;
  } else {
    return 'goodbye' as any;
  }
};

네, 맞아요. 이게 우리의 함수를 type-safe하지 않게 만듭니다. 우리는 함수에서 실수로 bonsoir를 return할 수도 있겠죠.

그러나 이러한 경우에는, as any를 사용하고 이 함수의 동작을 위한 unit test를 작성하는 것이 종종 더 낫습니다. 타입스크립트는 이러한 사항을 검사하는 데 한계가 있기 때문에 이렇게 하는 것이 타입 안전성에 거의 근접한 경우가 많습니다.

결론

한 가지 의문이 남습니다. 코드베이스에서 any를 금지해야 할까요? 제 생각에는 ‘예’라고 대답해야 한다고 생각합니다. ESLint 규칙을 설정하여 사용을 방지하고 가능한 한 사용을 피해야 합니다.

하지만 any가 꼭 필요한 경우도 있습니다. 이러한 경우 eslint-disable을 사용하여 우회할 가치가 있습니다. 따라서 이 문서를 북마크에 추가하고 사용해야 할 필요가 있을 때 PR에 첨부하세요.

레퍼런스

https://www.totaltypescript.com/any-considered-harmful

websocket(feat. socket.io, sockjs, stomp)

Mon, 08 Apr 2024 00:00:00 GMT

TL;DR

websocket(ws) 은 html5에서 표준이 된 기술명
- 즉, 브라우저 기능이라고 보면 된다.
- ws는 최근에 나온 것이기 때문에 하위 버전과 호환이 안 된다.
socket.io은 해당 기술을 이용한 모듈명
- 이 socket.io 모듈이 nodejs 프레임워크에서 동작을 한다.
- 클라이언트 사이드, 서버 사이드 두 가지로 나뉘게 된다.
  - 서버 사이드는 nodejs에서 돌아가는 express 같은 프레임 워크이고, 클라이언트 사이드는 흔히 플러그인이라고 말하는 자바스크립트 websocket 통신 설정 및 제어를 api로 제공한다.
- 하위 버전과 호환이 되지 않는 ws의 문제를 해결한다.
- io는 ws를 기반으로 작동하되, 만일 클라이언트가 이를 지원하지 않는다면 하위버전에 맞는 폴링, 스트리밍과 같은 다양한 방법으로 통신을 시도한다.
- React와 nodejs 간에는 socket.io를 사용한다.
socketJS(= sockJS)
- Using STOMP with SockJS - 근데 공식 문서에서는 이미 WebSocket이 보편화되어 있으므로 SockJS를 권장하지 않는다고 함.
- websocket과 유사한 객체를 제공하는 브라우저 javascript 라이브러리
- sockJS를 이용하면 websocket을 지원하지 않는 브라우저에서도 WebSocket과 유사한 방식으로 실시간 통신을 수행할 수 있 커버가능
- 소켓을 지원하지 않는 브라우저 대응을 위해 sockjs-client 설치.
- 서버 개발 시 스프링 설정에서 일반 WebSocket으로 통신할지 SockJS 호환으로 통신할 지 결정 가능
- 클라이언트는 sockjs-client를 통해 서버랑 통신
@stomp/stompjs(= stompjs)
- STOMP는 Simple Text Oriented Messaging Protocol의 약자이다.
- 공식 레포지토리
- 공식 문서
- WebSocket을 통해 STOMP 브로커에 연결할 수 있게 해주는 라이브러리(WebSocket 위에서 돌아간다는 뜻임.)
- Javascript and Typescript Stomp client for Web browsers and node.js apps
- Stomp는 HTTP에서 모델링 되는 Frame 기반 프로토콜
- 메세지 전송을 효율적으로 하기 위해 탄생한 프로토콜(WebSocket 위에서 동작)
- 클라이언트와 서버가 전송할 메시지의 유형, 형식, 내용들을 정의하는 메커니즘
- 텍스트 기반 프로토콜로 subscriber, sender, broker를 따로 두어 처리를 한다.

보통 Node.js를 사용할 때 socket.io를 주로 사용하고, spring을 사용할 때 sockJS, STOMP를 주로 사용한다.

단, sockJS는 stompjs 라이브러리에서 권장하고 있지 않다. 왜냐하면, 이제는 WebSocket api를 대부분 지원(can I use WebSocket ?)하고 있기 때문이다. 정말 구형 브라우저까지 지원할거면 example with sockJS 카테고리를 보도록 하자.

Browser native WebSocket api

웹소켓(WebSocket) 프로토콜이란?

웹소켓(WebSocket)은 클라이언트와 서버(브라우저와 서버)를 연결하고 실시간으로 통신이 가능하도록 하는 통신 프로토콜이다. 웹소켓은 하나의 TCP(Transmission Control Protocol) 접속에 전이중(duplex) 통신 채널을 제공한다.

[!TIP] 전이중(duplex) 통신 채널

데이터가 양방향으로 전송되는 통신 채널을 의미한다. 양쪽에서 데이터를 동시에 송수신할 수 있다.

HTTP와의 차이점은?

기존 HTTP는 단방향 통신이다. 클라이언트가 Request를 보내면 서버가 클라이언트로 Response를 보내는 방식으로 동작했다.

웹소켓은 연결이 이루어지면 클라이언트의 요청 없이도 서버로부터 데이터를 수신할 수 있다. 웹소켓은 이전 요청 상태를 기억하지 않는 무상태성(Stateless)을 가지는 HTTP와는 다르게 상태(Statefull) 프로토콜이다. 그렇기 때문에 한 번 연결되면 같은 연결을 이용해 통신하므로 TCP Connection 비용을 아낄 수 있다.

웹소켓의 동작

웹소켓은 HTTP port 80, HTTPS는 port 443 위에서 동작한다. 웹소켓은 TCP 연결처럼 HandShake 방식을 사용해서 연결된다. 이 때 HTTP 업그레이드(HTTP Upgrade) 헤더를 사용해서 HTTP 프로토콜에서 웹소켓 프로토콜로 변경한다.

즉, HTTP 프로토콜을 사용하지 않는 것은 아니란 것이다. 최초 접속시에는 HTTP 프로토콜을 사용해서 핸드셰이킹을 한다.

연결이 맺어진 이후에는 어느 한 쪽이 연결을 끊지 않는 한 영구적인 동일한 채널이 맺어지고, HTTP 프로토콜이 웹소켓 프로토콜로 변경된다.

이 때 데이터를 암호화하기 위해 ws가 아닌 wss 프로토콜을 사용할 수 있다.

단점

WebSocket 프로토콜은 Text 또는 Binary 두 가지 유형의 메시지 타입은 정의하지만 메시지의 내용에 대해서는 정의하지 않는다. 즉, WebSocket만 사용해서 구현하게 되면 해당 메시지가 어떤 요청인지, 어떤 포맷으로 오는지, 메시지 통신 과정을 어떻게 처리해야 하는지 정해져 있지 않아 일일이 구현해야 한다.

문제해결

따라서 STOMP(Simple Text Oriented Messaging Protocol)라는 프로토콜을 서브 프로토콜로 사용한다.

STOMP 란?

STOMP는 클라이언트와 서버가 서로 통신하는 데 있어 메시지의 형식, 유형, 내용 등을 정의해주는 프로토콜이라고 할 수 있다. STOMP를 사용하게 되면 단순한 Binary, Text가 아닌 규격을 갖춘 메시지를 보낼 수 있다. 스프링은 spring-websocket 모듈을 통해서 STOMP를 제공하고 있다.

stompjs는 WebSocket 위에서 돌아간다?

stompjs는 STOMP 프로토콜을 사용할 수 있는 라이브러리이다. 그리고 이 라이브러리는 WebSocket을 기본적으로 사용하는 라이브러리이다. STOMP Client api 소스코드를 뜯어보면 다음과 같이 내부적으로 WebSocket을 사용하려는 코드가 있다. 공식 문서에서 소스 코드를 친절하게 제공해놔서 볼 수 있다.

private _createWebSocket(): IStompSocket {
    let webSocket: IStompSocket;

    if (this.webSocketFactory) {
      webSocket = this.webSocketFactory();
    } else if (this.brokerURL) {
      webSocket = new WebSocket(
        this.brokerURL,
        this.stompVersions.protocolVersions()
      ); // 이제 웬만한 브라우저에서는 다 지원해서 기본값이 됨.
    } else {
      throw new Error('Either brokerURL or webSocketFactory must be provided');
    }
    webSocket.binaryType = 'arraybuffer';
    return webSocket;
  }

Stompjs 사용 예시

공식 문서가 너무나도 잘 나와있다. 그 중 일부를 보자. 검색해보면 옛날 것들(3~4 버전대)이 너무 많이 나온다. 그렇기 때문에 공식 문서에서 최신 버전으로 사용하는 방법을 가져왔다.

upgrading from version 3/4

Old version

const client = Stomp.client('ws://localhost:15674/ws');

client.debug = function (str) {
  console.log(str);
};

client.heartbeat.incoming = 4000;
client.heartbeat.outgoing = 4000;

client.reconnect_delay = 5000;

client.connect('user', 'password', function () {
  // Do something
});

Updated version

const client = new StompJs.Client({
  brokerURL: 'ws://localhost:15674/ws',
  connectHeaders: {
    login: 'user',
    passcode: 'password',
  },
  debug: function (str) {
    console.log(str);
  },
  reconnectDelay: 5000,
  heartbeatIncoming: 4000,
  heartbeatOutgoing: 4000,
});

client.onConnect = function (frame) {
  // Do something
};

client.activate();

Example with sockJS

위쪽에서도 얘기했다시피 이제는 WebSocket이 보편화되어 있기 때문에 SockJS를 쓰는 것을 권장하지 않는다. 그러나 정말 구형의 브라우저까지 지원하고 싶다면, 아래와 같이 사용하면 된다고 한다.

const client = new StompJs.Client({
  brokerURL: 'ws://localhost:15674/ws',
  connectHeaders: {
    login: 'user',
    passcode: 'password',
  },
  debug: function (str) {
    console.log(str);
  },
  reconnectDelay: 5000,
  heartbeatIncoming: 4000,
  heartbeatOutgoing: 4000,
});

// Fallback code
if (typeof WebSocket !== 'function') {
  // For SockJS you need to set a factory that creates a new SockJS instance
  // to be used for each (re)connect
  client.webSocketFactory = function () {
    // 🚨 Note that the URL is different from the WebSocket URL
    return new SockJS('http://localhost:15674/stomp');
  };
}

client.onConnect = function (frame) {
  // Do something, all subscribes must be done is this callback
  // This is needed because this will be executed after a (re)connect
};

client.onStompError = function (frame) {
  // Will be invoked in case of error encountered at Broker
  // Bad login/passcode typically will cause an error
  // Complaint brokers will set `message` header with a brief message. Body may contain details.
  // Compliant brokers will terminate the connection after any error
  console.log('Broker reported error: ' + frame.headers['message']);
  console.log('Additional details: ' + frame.body);
};

client.activate();

WebSocket api를 지원하는 브라우저에서는 SockJS가 어떻게 동작할까?

일단 위 코드와 같이 작성하되, 궁금증이 생겼다. SockJS가 WebSocket도 지원하는 것 같은데 조건문 분기 처리 없이 그냥 SockJS를 사용하면 안될까? SockJS를 쓰면 WebSocket api를 지원하는 브라우저에서 WebSocket api를 우선 제공하지 않는 문제가 있나?

역시 똑같은 것을 궁금해하는 사람이 있었다. Does SockJS emulate websockets even on a browser that supports websockets?를 참고해보면, native WebSocket을 먼저 사용하려고 하되, 없으면 SockJS에서 WebSocket과 유사한 api를 expose한다고 한다.

그냥 SockJS를 사용하면 안될까?

그럼에도 불구하고 if문을 통해 webSocketFactory를 정의하여 WebSocket api를 사용하려고 하는 까닭은 html5에서 등장한 WebSocket api가 공식적으로 웹 소켓을 사용하는 방법일뿐더러 WebSocket으로 했을 때와 SockJS로 했을 때의 속도? 면에서 차이가 있기 때문이라고 추정한다(SockJS에서 구현된 방식은 websocket처럼 동작하도록 모방된 방식.).

참고

웹 소켓에 대해 알아보자 - 실전 편 - 테코
WebSocket과 Socket.io- 네이버 옛날 글
Stomp.js 를 이용한 WebSocket 연동- client 사이드 코드 있음.
실시간 통신 / 채팅 기능 Web Socket 과 Socket.io- 정리 잘 되어 있음