이 글은 사내 Synology NAS에서 돌아가는 Portainer GUI를 로컬머신의 브라우저에서 보고싶어 삽질한 이야기다.

간단한 웹크롤러, 알림 서비스에 CI/CD를 붙이려고 부단히 노력했다.

NAS에 Docker registry 구축

ECR, DockerHub를 사용하는 것은 사치라 생각해 registy 이미지를 이용해, NAS에 이미지 레지스트리를 구축하고, GithubAction은 여기에 빌드한 이미지를 push한다.

docker 를 이용한 CI/CD는 처음에는 어려웠지만, 막상 경험해보니 이만한 기술도 없다. docker 사랑해요.

새로운 이미지 자동으로 pull받아 실행하기

이제 CICD의 마지막 관문, 어떻게 push된 이미지를 감지해서, NAS에서 새 이미지로 갈아끼워 실행할 것이냐?

선택지는 3가지 정도였다(from Gemini)

• WatchTower사용 (Polling. 내가 원하는 방식 아님)
• Portainer 사용 (기존방식. 내가 원하는 감지 후 pull가능) => 원하는 기능이었지만, Portainer Community Edition에서는 막혀있는 기능이었다. 웹훅(Github Action마지막에, Portainer의 웹훅 URL을 등록하면, 여기로 POST 웹훅요청을 보내서, Portainer가 레지스트리에서 최신 이미지를 pull하는 기능) 기능또한 Community Edition에서는 지원하지않는다.
• 독자 스크립트 (스크립트 유지보수에 시간을 쓰고 싶지 않았다)

이 세 방법 중, 한 번 설치해 본 적 있는 Portainer를 시도해보기로 했다. (Portainer 설치와 사용법은 다음에 정리하겠다)

GUI환경을 지원하니 최대한 GUI환경을 이용하고싶었으나 문제는 NAS는 현재 VPN Node라는것.

SSH 포트는 익명의 외부자에 노출하지 않는 것을 목적으로 VPN을 적용했다.

그렇기에 Portainer 포트를 외부에 노출시키면 나는 접근이 편리하겠지만, 다른 사람들도 접근할 수 있다는 점에서 부적합하다는 생각이 들었다.

로컬포트포워딩 써보셨나요?

docker exec -it [docker container] ssh -p <SSHPortOfRemoteMachine> -L 0.0.0.0:<PortOfMyLocalMachine>:127.0.0.1:<PortOfInternalServiceOfRemoteMachine> <user>@<TailscaleIP>

VPN으로 원격 서버를 설정한 이유는, 서버를 무차별적인 외부 ssh 접근으로부터 막기위함이었다.

Tailscale을 사용해서, 내 Mac(로컬머신)과 원격 서버의 연결은 SSH로 가능했다.

엥, 그러면 Portainer같은 내부용 모니터링 서비스는 어디서 보나?

아아... SSH 는 로컬포트포워딩(Local Port Forwarding)을 -L 옵션으로 지원한다.

그래서 원격호스트에서 돌아가는 내부 서비스포트를 내 로컬 포트에 연결하면, 로컬머신의 localhost:<원격호스트내부서비스포트> 에서 바로 볼 수 있다.

EventTarget - Node - Element - HTMLElement - HTMLDivElement

HTMLDivElement 는 속성과 매서드를 부모인 HTMLElement에서 상속을 받음. 따라서 HTMLElement를 살펴봐야한다.

그래서 아래 스크립트를 추가해서 사용중인데 괜찮은 것 같다.

pull-clean을 하면 main브랜치로 옮겨가고, 원격에서 없어진 브랜치들을 로컬에서도 삭제하는 방식이다.

"list-gone-branches": "git fetch -p && git branch -vv | awk '/: gone]/{print $1}'",
"delete-gone-branches": "git fetch -p && git branch -vv | awk '/: gone]/{print $1}' | xargs git branch -D",
"pull-clean": "git switch main | npm run delete-gone-branches"

=> 2024.12.11 수정 위 스크립트에서 bash 가 한국어 설정이 되어 있을 때와 이미 브랜치가 삭제되어서 없는 상황에 대한 처리가 되지 않아 제대로 로컬 브랜치가 지워지지 않는 문제가 있었다.

정규식을 통해 한글과 영어로 된 브랜치 삭제/없음 케이스들을 처리하자. 영어로는 삭제됨과 없음이 "gone"으로 퉁쳐서 표현된다.

"delete-gone-branches": "git fetch -p && git branch -vv | awk '/: 삭제됨]|: gone]|: 없음]/{print $1}' | xargs git branch -D"

더 좋은 방법이 있지 않을까?

있다. 내가 생각하기에는 아래 방법이 더 좋은 것 같다.

현재 husky를 활용해서 pre-commit과 pre-push 훅을 프리티어와 린트검사에 사용하고 있다.

그런데 이것 말고도 post-merge라는 훅이 하나 더 있다. 자세한 내용은 (링크)깃북을 읽어보고 일단 따라해보자.

husky 설치 및 초기화

npm install husky --save-dev
npx husky install

yarn add husky -D 
yarn husky init

깃훅 추가

파일 이름을 post-merge로 짓는다.

# .husky/post-merge
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

# This command will be run after pulling changes
# npm 사용 시
npm run delete-gone-branches

#yarn 사용 시
yarn run delete-gone-branches

위에 언급한 delete-gone-branches를 등록해주자.

이제 사용해보자

브랜치 머지 후, main에서 pull을 받아보자.

나는 post-merge가 더 좋아보여서 사용했지만, post-checkout을 사용해도 괜찮아보인다.

참고

• Husky 공식문서- get-started

도입 배경

나는 솔직히 SQL에 문외한이다. 백엔드 아키텍처도 잘 모른다. 기껏 해봐야 정보처리기사 자격증을 취득할 때 공부한게 다였다.

그런데 이번 회사 신제품에 Next.js + Supabase를 기술스택으로 선정하여 빠른 MVP 구축을 개발하기로 협의되었다.

문제는 내가 회사 유일의 개발자라는 점ㅜㅜ. 그래서 SQL때문에 백엔드 개발이 늦어지면 안되겠다고 판단했다. 내 단점은 생각이 너무 많은 점인데, 백엔드 걱정하면서 또 코드 쓰기를 주저하길래 일단 사용해보면서 익히기로 하고 prisma를 설치해버렸다.

Prisma는 ORM type-safe하게 데이터베이스에 접근하는 방법이 있었다. 도입하여 공부중이다.

Next.js에서의 Prisma

Next.js에서 Prisma는 서버사이드 코드에서 활용할 수 있다.

클라이언트단에서 미리 내가 정해놓은 서버사이드 API로 요청을 보내고, 이 요청을 처리하는 코드에서 Prisma를 사용하여 Supabase로 트랜잭션 요청을 보내는 방식이다. 이 과정에서 Prisma Client가 활용이 된다.

Prisma Client 는 내가 사용하는 데이터베이스 스키마대로 쿼리를 만들어주는 type-safe 쿼리 빌더이다. 어렵다. 단순히 말해서 "Prisma Client 는 데이터베이스에 쿼리를 보내는 역할만 한다(링크)".

schema.prisma파일에 내가 사용하는 데이터베이스 모델을 명시해주면 그에 따라서 맞는 API가 Prisma Client로 생성되는 것이다.

이 스키마 파일에 명시되는 모델은 [Model의 두 가지 목적 - Prisma 공식문서참고]이 있다.

• Prisma를 통해 통신할 데이터베이스 테이블을 표현
• Prisma Client API 생성(generate)의 기반이 된다.

npx prisma generate

[React] 중첩된 커스텀 훅의 리렌더링

memo 를 활용하여 불필요한 렌더링 방지

import styled from '@emotion/styled';
import useNestedHook from '@Hook/nested-custom-hook/useNestedHook';
import { memo } from 'react';
import { v4 as uuidv4 } from 'uuid';

export default function NestedCustomHook() {
  const formId = `user_${uuidv4()}`;
  const { formValues, setter } = useNestedHook();

  return (
    <VerticalFlexContainer>
      <form>
        <label htmlFor={`name_${formId}`}>
          Name:&nbsp;
          <input
            id={`name_${formId}`}
            name="name"
            type="text"
            value={formValues.name}
            onChange={(e) => {
              setter.setName(e.target.value);
            }}
          />
        </label>
        <label htmlFor={`email_${formId}`}>
          Email:&nbsp;
          <input
            id={`email_${formId}`}
            name="email"
            type="text"
            value={formValues.email}
            onChange={(e) => {
              setter.setEmail(e.target.value);
            }}
          />
        </label>
      </form>
      <HorizontalFlexContainer gap="20px">
        <MemoizedSpan label="Name" data={formValues.name} />
        <MemoizedSpan label="email" data={formValues.email} />
      </HorizontalFlexContainer>
    </VerticalFlexContainer>
  );
}

const MemoizedSpan = memo(
  ({ label, data }: { label: string; data: string }) => {
    console.log('MemoizedSpan', label, data);
    return (
      <CustomSpan>
        {label}: {data}
      </CustomSpan>
    );
  }
);

const HorizontalFlexContainer = styled.div<{ gap: string }>`
  display: flex;
  gap: ${(props) => props.gap};
`;

const VerticalFlexContainer = styled.div`
  display: flex;
  flex-direction: column;
  gap: 1rem;
  padding: 12px;
`;

const CustomSpan = styled.span`
  display: inline-block;
  background-color: 'red';
`;

MemoizedSpan이라는 컴포넌트를 임의로 선언해 보았다(emotion/styled는 무시하자). 공식문서대로라면, prop이 바뀌지 않는 부분의 컴포넌트는 리렌더링이 되지 않아야 한다.

실제로 잘 동작한다. Name 인풋을 수정할 때 email 쪽의 Span컴포넌트는 리렌더링 되지 않는다.

물론 memo를 사용하더라도 memo된 컴포넌트의 내부 state가 변경되거나 사용 중인 context가 변경되면 리렌더링 된다는 점에는 주의해야 한다.

객체를 props로 넘기는 경우(작성중)

객체를 props로 넘기는 경우는 컴포넌트를 작성하면서 자주 접하는 상황이다.

memo는 내부적으로 Object.is 로 비교를 하여 prop이 이전 렌더링 때의 prop과 동일한 지를 비교한다.

그러면 Object.is는 어떻게 동작을 할까?

Object.is

내가 궁금한 점은 중첩객체일 때 과연 Object.is가 제대로 동작하느냐였다. 실무에서 prop에 중첩객체를 전달해야 하는 경우가 잦았는데 이 경우에도 제대로 객체 간 비교를 수행하는지 궁금했다.

console.log(Object.is({ name: 'child1' }, { name: 'child1' }));
//false

props변경을 최소화하기

나는 상태를 변경했는데, 리렌더링이 되지 않는 경우

prop이 변경되지 않은 컴포넌트가 함께 리렌더링이 되는 경우

내 깃헙 이슈 PR

//NestedCustomHook 페이지
import styled from '@emotion/styled';
import useNestedHook from '@Hook/nested-custom-hook/useNestedHook';
import { v4 as uuidv4 } from 'uuid';

export default function NestedCustomHook() {
  const formId = `user_${uuidv4()}`;
  const { formValues, setter } = useNestedHook();

  return (
    <VerticalFlexContainer>
      <form>
        <label htmlFor={`name_${formId}`}>
          Name:&nbsp;
          <input
            id={`name_${formId}`}
            name="name"
            type="text"
            value={formValues.name}
            onChange={(e) => {
              setter.setName(e.target.value);
            }}
          />
        </label>
        <label htmlFor={`email_${formId}`}>
          Email:&nbsp;
          <input
            id={`email_${formId}`}
            name="email"
            type="text"
            value={formValues.email}
            onChange={(e) => {
              setter.setEmail(e.target.value);
            }}
          />
        </label>
      </form>
      <HorizontalFlexContainer gap="20px">
        <CustomSpan>Name: {formValues.name}</CustomSpan>
        <CustomSpan>Email: {formValues.email}</CustomSpan>
      </HorizontalFlexContainer>
    </VerticalFlexContainer>
  );
}

const HorizontalFlexContainer = styled.div<{ gap: string }>`
  display: flex;
  gap: ${(props) => props.gap};
`;

const VerticalFlexContainer = styled.div`
  display: flex;
  flex-direction: column;
  gap: 1rem;
  padding: 12px;
`;

const CustomSpan = styled.span`
  display: inline-block;
  background-color: 'red';
`;

//useNestedCustomHook.tsx
import useEmail from './useEmail';
import useName from './useName';

interface FormValues {
  name: string;
  email: string;
}

interface Setter {
  setName: React.Dispatch<React.SetStateAction<string>>;
  setEmail: React.Dispatch<React.SetStateAction<string>>;
}

export default function useNestedHook(): {
  formValues: FormValues;
  setter: Setter;
} {
  console.log('useNestedHook Rerender');
  const { name, setName } = useName();
  const { email, setEmail } = useEmail();

  return { formValues: { name, email }, setter: { setName, setEmail } };
}

//useName.tsx
import { useState } from 'react';

export default function useName() {
  console.log('useName rerender');
  const [name, setName] = useState('');

  return { name, setName };
}

//useEmail.tsx
import { useState } from 'react';

export default function useEmail() {
  console.log('useEmail rerender');
  const [email, setEmail] = useState('');

  return { email, setEmail };
}

위 예시 코드는 React의 커스텀 훅 동작에 대한 이해를 위해서 예시로 작성한 코드이다.

실행을 하게 되면 아래와같은 리렌더링 양상을 보여준다.

왜 이럴까?

Render and Commit

정답은 리액트의 렌더링 과정에 있었다.

커스텀 훅은 상태 관리 로직을 재사용성을 위해 분리한 것에 지나지 않는다. 중첩된 커스텀훅을 호출하는 컴포넌트는 커스텀 훅의 상태들을 참조(구독)하고 있는 것이다.

Triggering a render

상태가 변경되어 트리거된 리렌더는 큐에 등록이 되고, 이후 상태가 변경되어 리렌더링이 필요한 컴포넌트가 재호출된다. 재호출된다는 것은 함수 내부 라인을 한 줄 한 줄 다 훑으며 실행이 된다는 것이다. 그렇기에 커스텀 훅에서 리턴된 상태값을 참조하는 페이지 컴포넌트가 리렌더링 대상이 되었다.

Rendering the component

첫 렌더링 시에는 루트 컴포넌트를 호출하고,

이후 렌더에서는 렌더링을 트리거한 상태 업데이트를 지닌 컴포넌트를 호출한다. 이 과정은 재귀적이어서, 만약 A컴포넌트가 호출되었다면, 하위 컴포넌트들도 다시 재호출된다.

이 작업은 한 눈에 비효율적임을 알 수 있다.

그래서 리액트는 useMemo, useCallback 등의 불필요한 리렌더링을 방지하는 API를 제공하고 있다.

Committing to the DOM

컴포넌트들을 렌더링(호출)했다면, 이제 DOM을 변경하게 된다.

• 첫 렌더 시에는 appendChild() DOM API를 통해 화면에 생성한 노드를 추가한다.

• 리렌더링 시에는, DOM과 최신 렌더링 결과를 맞추기 위해 최소한의 작업을 진행한다.

리액트는 렌더와 렌더 사이에 차이가 생긴 DOM 노드만 변경한다. 컴포넌트 호출은 하지만, Commit 단계에서 컴포넌트와 매칭되는 DOM을 조작하는 건 일부만 진행할 수 있다는 이야기이다.

브라우저 페인트

DOM 업데이트를 하고 나면, 화면을 리페인트한다.

나의 오개념

내부 커스텀 훅의 상태를 바꾸니까 리렌더링이 내부 커스텀 훅에서 먼저 일어날 것이라 생각한 것이 오개념이었다.

리렌더링은 별도의 큐잉으로 진행이된다.

tutorialspoint, Fetch API - Credentials MDN, Using the Fetch API

미안해 fetch... 난 널 아직 잘 몰라

나는 fetch API를 잘 모르는 것 같다. 항상 하던대로 url에 쿼리 스트링, body에 JSON.stringify()를 사용한 작업만 하던 내 스스로에 부족함을 느꼈다. fetch API에 대해 궁금해져 찾아본 내용을 기록해 본다.

fetch API는 비동기로 동작하며, 요청에 대한 Response 객체를 리턴하는 Promise를 리턴하며, 해당 Promise가 resolve되었을 시에 얻게되는 Response객체의 비동기로 동작하는 json()매서드를 통해서 다시 body객체를 얻는 과정(헥헥...)은 프론트엔드 웹개발을 학습하다보면 자주 접하게 되는 부분이다.

그런데 내게 credentials옵션은 낯설었다.

fetch('https://example.com/data', {
  credentials: 'include'
})
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

credentials라는 옵션은 어떤 역할을 하며, 언제 사용해야할까?

credentials 옵션

개발을 하면서 옵션의 기본값을 알아두면 유용하다는 것을 절감하고 있다. 다행히도 credentials 옵션의 값은 3종류밖에 안된다.

• same-origin − (기본값) 페이지를 요청할 때 same-origin 대상의 요청에서만 credential 데이터를 전달하는 것이다. same origin URL들로부터 온 credentials 데이터만 사용한다.

• omit − 브라우저가 리소스를 요청할 때 credentials를 제거한다.는 물론이고, Response의 credentials도 무시한다.

• include − 이 옵션을 사용하면, same-origin일 때도, corss-origin일 때도 credentials를 포함하여 요청을 보내게 된다. 더불어 Response의 credentials도 사용한다.

credentials에는 어떤 데이터들이 해당되는가?

그래, 요청을 보내고 받을 때 credentials를 사용할 지 말 지 여부를 판단하는 옵션인 것을 알았다. 그러면 credentials에는 어떤 데이터들이 해당이 될까?

Cookies − 쿠키라는 녀석들은 브라우저에 저장되는 작은 데이터이다. same-origin 요청일 때 담겨 보내진다. 쿠키는 세션 정보, 자주 사용되는 데이터, 등등 다양한 목적으로 사용이 된다. 만약 서버에서 Set-Cookie 헤더와 함께 사용되면, 응답을 받은 브라우저에서는 해당 오리진에 대한 쿠키를 브라우저에 저장하게 된다. 서버에서 브라우저에 전달하고자 하는 데이터가 있는 경우에 유용하겠다! 그러면 아무때나 Set-Cookie 헤더를 사용하면 브라우저에 쿠키를 저장할 수 있으려나...? 그건 더 공부를 해봐야겠다.

Authorization Headers − 서버의 보호된 자원에 접근하기 위해서 헤더에 포함시키는 데이터이다.

Authorization: <auth-scheme> <authorization-parameters>

이렇게 쓰이는데...많이 사용했었는데... Bearer 토큰 사용해 본 적이 있는데... 이 부분은 내가 더 공부를 해서 다른 포스팅으로 돌아오겠다. 꼭 돌아오겠다. 미안해 일단 넘어가자!

MDN - Authorization MDN - HTTP Authentication

TLS Client Certificates − CA로부터 클라이언트 브라우저가 제공받은 디지털 인증서이다. 이것도 credentials에 포함이 된다니 의외였다. 그럼 이 인증서는 어떻게 요청에 포함이 되려나....? 이 부분도 더 공부해서 돌아오겠다. 일단 넘어가자!

실습

위에 첨부한 tutorialspoint에는 좋은 실습 코드가 있다. 한 번 옵션을 바꿔보면서 실행해보자.

먼저 내 credentials중 하나인 cookie가 실제로 옵션에 따라 포함되고 안되는지를 실행해보자.

여기 내 쿠키다.

same-origin 옵션

네트워크 탭의 Timing 탭 옆에 아무것도 없다.

omit 옵션

네트워크 탭의 Timing 탭 옆에 아무것도 없다.

include 옵션

띠용, 쿠키 탭이 생기고, 살펴보니 쿠키들이 Request에 담겨 함께 전달되는 모습을 확인할 수 있었다. 완전 신기하다.

회고

Chat-GPT같은 생성형 AI 서비스에 물어보면 이런 기본적인 지식들은 손쉽게 얻을 수 있다. 그러면 이런 지식들을 블로그에 굳이 정리하는 의미가 있을까에 대한 고민이 문득 들었다.

이 고민은 사실 내가 습득한 지식의 복습선에서 깔끔하게 정리가 되었다.

내가 궁금한 부분을 검색하고, 내 언어로 직접 정리하는 작업은 복습이었다. 이렇게 블로그에 정리한 지식은 오롯이 나만의 지식으로서 내 기억 깊은 곳에 꽤나 오래 살아있었다. 물론 나도 사람이고 아직 꾸준히 학습하고 더 개발을 많이 해봐야 하기에 부족한 부분이 많은 글이다. 그래서 남들에게 보여주기 민망한 수준의 똥글을 적을 때도 있다. 그런 글을 우연히라도 방문하게 되는 독자분들에게는 죄송하다... 그렇지만 머리속에만 담아두려 하는 아이디어와 지식들이 언젠가는 휘발되는 것이 너무 아까울 때가 있다. 그러니 너그러이 이해해주셨으면 하는 바람이다 하하.

언젠가는 나도 나만의 노하우와 통찰이 담긴 글을 쓸 날이 오겠지.

| 자식 컴포넌트 트리 안에서 발생한 자바스크립트 에러를 잡아서, 로깅하고, fallback UI (에러가 발생한 컴포넌트 트리 대신 대체해서 보여줄 UI)를 보여주는 리액트 컴포넌트이다.

단, (1) 이벤트 핸들러 (2) 비동기 코드 (setTimeout, requestAnimtionFrame 등) (3) 서버사이드 렌더링 (4) 자식 컴포넌트들이 아니라, 에러 바운더리 자체에서 발생한 에러 들은 Error boundaries가 캐치해내지 못한다.

공식문서에서 ErrorBoundary는 클래스 컴포넌트로 작성되어 있다. 아래코드는 공식문서의 예시 코드에 TS를 적용한 모습이다.

import { Component, PropsWithChildren, ReactNode } from 'react';

interface ErrorBoundaryProps extends PropsWithChildren {
  fallback: ReactNode;
}

interface ErrorBoundaryState {
  hasError: boolean;
}

export default class ErrorBoundary extends Component<
  ErrorBoundaryProps,
  ErrorBoundaryState
> {
  constructor(props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(_: Error): ErrorBoundaryState {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

  componentDidCatch(error: Error, info: React.ErrorInfo): void {
    // Example "componentStack":
    //   in ComponentThatThrows (created by App)
    //   in ErrorBoundary (created by App)
    //   in div (created by App)
    //   in App
    console.error('Error caught by ErrorBoundary:', error);
    console.error('Component stack:', info.componentStack);
  }

  render() {
    if (this.state.hasError) {
      // You can render any custom fallback UI
      return this.props.fallback;
    }

    return this.props.children;
  }
}

ErrorBoundary 는 getDerivedStateFromError()라는 컴포넌트생명주기를 활용하여, 하위 자식 컴포넌트 트리에서 발생한 애러를 캐치할 수 있다.

static getDerivedStateFromError(error) {
    // Update state so the next render will show the fallback UI.
    return { hasError: true };
  }

자식 컴포넌트에서 던져진(thrown)에러 이후에 이 생명주기 매서드가 발동된다. 그리고 그 에러가 매서드의 파라미터로 들어오게되고, 상태값인 hasError를 true로 변경하여 다음 렌더 때 fallbackUI를 보여주게 된다.

getDerivedStateFromError()는 render단계에서 호출되기에, 사이드 이펙트들이 허용되지 않는다.

UserManagement 컴포넌트 리팩토링 하는 과정에서 Error boundary를 사용해보았다.

추가적인 의문

단순히 공식문서만보고 아하, Error boundary를 쓰면 에러 발생시에 fallback UI를 렌더링해준대요 라고 믿기에는 뭔가 성에 차지 않는다.

개발 단계에서 Error boundary가 실제로 잘 동작하는지 여부를 테스트하기위해서는 어떤 방법들이 있을까?

학습 출처: [Typescript Handbook - Modules]

typescript를 사용하다보면 tsconfig.json에서 관련 설정들을 조정해주어야 할 때가 잦았다. 각 옵션이 무엇을 의미하는지, 또 어떻게 typescript는 동작을 하는지 조금 늦게나마 학습하고 기록으로 정리하는 중이다.

그 중, 자바스크립트에서의 Module개념은 반드시 알아야 하는 녀석이라 생각하여 우선적으로 정리한다.

모듈이란

In TypeScript, just as in ECMAScript 2015, any file containing a top-level import or export is considered a module.

타입스트립트에서 모듈의 정의이다. 즉, 파일에 import, export문이 없으면 모듈이 아니다. 모듈은 각자의 스코프가 존재한다. 반면 모듈이 아닌 파일은 script라 부르며, 스크립트는 전역 스코프에서 접근이 가능하다.

우리는 개발 과정에서 거의 필연적으로 모듈을 호출하고, 모듈로 코드를 분리해 코드를 작성한다. typescript는 컴파일 과정을 통해 javascript로 변환된다. 타입스크립트의 tsc(typescript compiler)가 어떤 형태의 자바스크립트 코드를 읽어들여서 어떤 형태의 자바스크립트 코드로 변환할 지를 tsconfig.json 파일을 통해 지시받는다. 그래서 tsc가 모듈의 경로를 해석하여 적절한 파일로 연결해주고, 잘 컴파일 할 수 있도록 설정해주는 것이 중요하다.

그래서 tsconfig.json의 옵션들 중에서 모듈과 관련된 옵션들을 몇 개 추려서 공부해보았다.

ESM, CJS

만약 어떤 파일(가령 .js 파일)이 ESM으로 결정되었으면, Node.js는 require와 CommonJS module을 평가 과정에 주입하지 않는다. 만약 해당 파일에서 require, CommonJS module을 사용하고 있다면 충돌이 발생한다.

반면, 어떤 파일이 CJS로 결정되었으면, 파일 내에서의 import, export 키워드의 사용은 충돌을 발생시킬 것이다.

참고 - What the heck are CJS, AMD, UMD, and ESM in Javascript?

TypeScript의 "module" 옵션

스택오버플로우 Why we need "nodenext" typescript compiler option when we have "esnext"?

이 질문글의 답변에는 typescript의 module 옵션에 대한 설명이 꽤나 친절하게 적혀있었다. 그런데도 나는 이해를 잘 하지 못했다.

그래서 공식 문서를 뒤져봤고, The module output format 섹션을 읽어본 결과,

module 옵션은 컴파일러가 어떤 형태로 모듈을 내보낼지 결정하는 (emit)옵션이었다.

import sayHello from "greetings";
sayHello("world");

가령 위 코드는 tsconfig.json의 module 옵션에 따라 컴파일 결과가 달라질 수 있다는 것!

TypeScriptdml "moduleResolution" 옵션

Module resolution is the process of taking a string from the import or require statement, and determining what file that string refers to.

TypeScript includes two resolution strategies: Classic and Node. Classic, the default when the compiler option module is not commonjs, is included for backwards compatibility. The Node strategy replicates how Node.js works in CommonJS mode, with additional checks for .ts and .d.ts.

위 인용구는 Module의 import/require 구문의 문자열이 해당 문자열이 의미하는 파일로 결정되는지에 대한 과정인 Module resolution 에 대한 설명이다.

타입스크립트는 Classic, Node 이렇게 두 resolution 전략을 가지고 있다. Classic은 타입스크립트 1.6버전 이전에 사용된 옵션이라 모던 타입스크립트에서는 사용하지 않는 옵션이란다(tsconfig/moduleResolution). Node 전략은 CommonJS mode에서 Node.js가 동작하는 방식을 그대로 따르는 것으로, .ts와 .d.ts파일을 통한 추가적인 체크를 하는 방식으로 이루어진단다.

내가 지금 진행하고 있는 electron프로젝트의 tsconfig.json를 예시로 한 번 살펴보자.

{
  "compilerOptions": {
    "incremental": true,
    "target": "es2022",
    "module": "commonjs",
    "lib": ["dom", "es2022"],
    "jsx": "react-jsx",
    "strict": true,
    "sourceMap": true,
    "moduleResolution": "node",
    "esModuleInterop": true,
    "allowSyntheticDefaultImports": true,
    "resolveJsonModule": true,
    "allowJs": true,
    "outDir": ".erb/dll"
  },
  "exclude": ["test", "release/build", "release/app/dist", ".erb/dll"]
}

moduleResolution이 "node"이다. 이 옵션에 대한 공식 문서의 설정을 살펴보면 아래와 같다.

'node16' or 'nodenext' for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS require, which resolve using different algorithms. These moduleResolution values, when combined with the corresponding module values, picks the right algorithm for each resolution based on whether Node.js will see an import or require in the output JavaScript code.

'node10' (previously called 'node') for Node.js versions older than v10, which only support CommonJS require. You probably won’t need to use node10 in modern code.

조금 더 자세한 설명을 찾아볼까?

node10: Formerly known as node, this is the unfortunate default when module is set to commonjs. It’s a pretty good model of Node.js versions older than v12, and sometimes it’s a passable approximation of how most bundlers do module resolution. It supports looking up packages from node_modules, loading directory index.js files, and omitting .js extensions in relative module specifiers. Because Node.js v12 introduced different module resolution rules for ES modules, though, it’s a very bad model of modern versions of Node.js. It should not be used for new projects.

아하, 지금 module옵션에 commonjs가 설정되어 있어서 moduleResolution이 node로 설정되어 있구나.

그런데 현재 나는 electron ^26.2.1 버전을 사용중이고, 이 경우에 Node.js 버전은 18이다. 그러니, module옵션과 moduleResolution 옵션을 수정해도 될 것 같다.

그러나 결과는 에러!

에러가 났던 이유는, 내가 사용하는 보일러플레이트 프로젝트에서 webpack ts-loader의 compilerOption이 "esnext"로 되어있어 Node16옵션과 맞지 않았기 때문이다.

그런데 ts-loader? 이 녀석은 webpack과 관련된 주제라 오늘은 여기까지...후우...

electron-react-boilerplate 프로젝트 기반으로 데스크탑 어플리케이션을 개발하면서 내 프로젝트는 어떻게 실행파일로 변환되는가 가 가장 궁금하고 신기했다.

데스크탑에서 실행가능한 형태로 변환하는 툴에는 대표적으로 electron-forge, electron-builder가 있는데 나는 electron-builder를 사용했다.

변환과정은 다음과 같았다.

React(리액트를 사용하는 경우) -> BUILD (리액트 코드를 JS, HTML, CSS파일로 변환) -> electron-builder를 통해 실행파일로 변환!(생각해보면 당연한 수순같기도...ㅎㅎ)

나는 웹개발 프로젝트를 만들 때 배포환경까지 세팅을 해놓고 프로젝트를 진행해야 안심이 되었다. 그래서 이번에도 보일러플레이트 프로젝트를 클론받자마자 npm run package 스크립트를 실행했는데 웬걸... 에러가 나면서 제대로 내가 원하는 옵션대로 빌드가 되지 않았다.

원인

내 작업 환경은 Windows10 x64, VSCode로 진행하고 있었다.

문제는 내가 특정 스크립트를 실행할 때 충분한 권한이 없었던 것이었다.

해결

VSCode를 관리자 권한으로 실행하여 문제를 해결했다.

지금은 Code Signing 단계를 거치지 않고 배포했기에, 아래와 같이 옵션을 설정해놓았다. 다다음주 쯤에는 인증서도 등록해서 어엿한 하나의 제품으로 배포해야 하는데 후움...잘 되려나? 모르겠다.

 "win": {
      "target": "portable",
      "verifyUpdateCodeSignature": false,
      "sign": null
    },

참고

[Window] Electron Builder 실행시 cannot create symbolic link 이슈

electron-builder 설정 옵션 문서

Electron.App.isPackaged 라는 boolean 값이 있다. 이 값을 활용해서 development환경과 production환경을 구분하여 로직을 짜보자.

dotenv를 사용하지 않아도 환경을 구분할 수 있어서 편리하다.

어떤 기술이 electron으로 개발하고 빌드할 때 더 편리하냐인데, 흥미로워서 링크를 가져와봤다.

[링크]electronbuilder_vs_electronforge

읽어보고 나니, 조금 더 많은 빌드 옵션을 제공하는 라이브러리는 electron-builder인듯 하다.

그런데 electron 공식문서에는 electron-forge가 가장 처음 예시로 나와서 electron-forge를 사용했는데... 에러가 자꾸 나니까(물론 내가 뭔가를 잘못설정했을 가능성이 100%이지만...) electron-builder도 사용해보고 싶어진다.

보일러플레이트 레포들을 살펴보면서 디렉토리 구조와 웹팩 설정을 잘 살펴보면서 눈을 트여야겠다.

빌드까지 가능한 유용한 보일러플레이트

electron-builder 공식문서에서 소개하는 보일러플레이트

electron-builder에는 electron-builder를 활용한 다양한 보일러플레이트 프로젝트들을 소개해주고 있다.

그 중 나는 electron-react-boilerplate를 선택했다.

현재 내가 설정한 회사 프로젝트는 electron + electron-forge + react + typescript + webpack + tailwindCSS 로 이루어져 있는데, 어떤 차이점이 있는지 비교해보고 싶어졌다.

새로운 preload 스크립트 활용 패턴 발견

electron-react-biolderplate의 preload 스크립트가 짜여진 방식이 매우매우 마음에 들어서 복붙해왔다. 내가 preload스크립트를 짤 때 스스로에게 불만이었던 점은 preload스크립트에 매 이벤트마다 이벤트 핸들러를 등록해야하는 점이었다.

그런데 보일러플레이트 코드에서는 ipcRenderer라는 객체에 실제 electron/ipcRenderer 객체를 래핑한 인터페이스 함수를 작성하여 리액트코드에서 조금 더 안전하게 ipcRenderer를 사용할 수 있도록 코드를 작성했다.

이 코드에서 export한 타입들은 기본적으로는 Window객체에 추가가 되지 않으니, preload.d.ts에서 Window 객체에 타입을 추가해준다.

// Disable no-unused-vars, broken for spread args
/* eslint no-unused-vars: off */
import { contextBridge, ipcRenderer, IpcRendererEvent } from 'electron';

export type Channels = 'ipc-example';

const electronHandler = {
  ipcRenderer: {
    sendMessage(channel: Channels, ...args: unknown[]) {
      ipcRenderer.send(channel, ...args);
    },
    on(channel: Channels, func: (...args: unknown[]) => void) {
      const subscription = (_event: IpcRendererEvent, ...args: unknown[]) =>
        func(...args);
      ipcRenderer.on(channel, subscription);

      return () => {
        ipcRenderer.removeListener(channel, subscription);
      };
    },
    once(channel: Channels, func: (...args: unknown[]) => void) {
      ipcRenderer.once(channel, (_event, ...args) => func(...args));
    },
  },
};

contextBridge.exposeInMainWorld('electron', electronHandler);

export type ElectronHandler = typeof electronHandler;

//preload.d.ts
import { ElectronHandler } from '../main/preload';

declare global {
  // eslint-disable-next-line no-unused-vars
  interface Window {
    electron: ElectronHandler;
  }
}

export {};

원인

최종 번들된 코드에 node.js 의 모듈들이 포함되어 있지 않는 이유.

settings: {
    'import/parsers': {
      '@typescript-eslint/parser': ['.ts', '.tsx'],
    },
    'import/resolver': {
      typescript: {},
    },
  },

https://github.com/import-js/eslint-import-resolver-typescript

설정 바꾸고 cmd + shift + p => Reload Window 해서 제대로 설정이 적용되는지 확인해보자. 이거 때문에 헤매다가 세 시간 날렸다 우씨!

https://www.electronforge.io/config/plugins/webpack#how-do-i-do-virtual-routing

브라우저환경에서 사용하던 createBrowserRouter가 아닌, MemoryRouter로 페이지를 구현해야 한다!

Session이 뭔데?

세션은 동일한 클라이언트/유저(브라우저)와 서버(웹서버) 사이에서 여러 요청에 걸쳐 이루어지는 상호작용을 stateful하게 유지하는 데이터를 유지할 수 있도록 하는 매커니즘을 의미한다.

HTTP 요청은 클라이언트의 요청에 응답을 한 번 주고나면 더 이상 서버는 클라이언트와의 연결을 유지하지 않는 비연결성을 지니는 프로토콜이다. 이는 별도의 추가적인 장치 없이는 클라이언트가 서버로 보내는 매 HTTP 요청은 별도의 요청으로 취급된다는 것이다.

하지만 실제 세상에서는, 클라이언트가 보내는 요청들에 대해 웹서버가 연결성있게 처리해주어야 하는 요구사항들이 등장한다. 그래서 웹서버는 특정 유저와 관련된 행위를 지속적으로 추적할 필요가 있다. 가령 유저인증이 그렇다. 우리는 한 번 로그인을 하고 나서, 페이지 이동시마다 새로 로그인을 하지는 않는다. 로그인이 성공하고 나면, 우리는 로그인 된 상태로 페이지들을 노닐 수 있다. 서버에서 이 기능은 어떻게 구현된 것일까?

바로 세션을 통해서이다.

HTTP 웹서버는 클라이언트의 연결이 검증되면, 브라우저와 웹사이트 사이의 세션을 생성한다. 유저가 사이트에 로그인되고 나서 세션을 생성하는 경우도 있다.

후자의 경우에 웹서버는 로그인 정보를 기반으로 해당 클라이언트에 대한 세션(서버 나름의 자료구조)을 생성하고, session-related(세션과 관련된) 정보들을 특정한 데이터스토어(서버의 디렉토리구조, 또는 데이터베이스)에 저장함으로써 관리한다.

세션을 생성하고 나서, 서버는 해당 세션의 태그에 해당하는 session ID - 세션아이디를 Set-cookie 헤더에 쿠키로 담아 응답을 하게 된다.

응답을 받은 브라우저는 해당 세션아이디를 쿠키에 저장하고, 다음 요청때 헤더에 담아 서버와 통신하게 된다.

클라이언트가 서버로 다음 요청을 보낼 때, 쿠키에는 이전에 발급받은 세션아이디가 존재할 것이고, 서버는 쿠키에 담겨온 세션아이디를 통해 서버의 세션스토어(세션 데이터가 저장되는 공간)의 세션 데이터에 접근하여 해당 세션아이디에 해당하는 세션이 아직 유효한지 검증한다.

PR

링크

참고

[링크1] What is a session ID?

[링크2] Difference between cookies, session and tokens

내 방의 책장을 정리하다가 오~래 전에 사놓은 [node.js 200제]라는 책을 발견했다.학부시절 이 책을 기반으로 한 실습강의를 듣고, 웹개발자가 되기로 결정했던 날이 생각나 문득 책을 열어보았다. 교수님의 코드를 받아 적기만 하던 그 때의 나보다 지금의 나는 얼마나 성장해 있을지 나 스스로 느껴보고 싶기도 했다.

총 200개의 예제 중 160번예제까지는 모두 아는 것들이었다. 아하. 나는 모던자바스크립트 Depp Dive를 잘 공부해 놓았기에 자바스크립트 기초 문법은 다 알고, 잘 사용할 수 있는 내용들인데. 다행이다. 아, request response에 대해 알고 있구나, 다행이다. 아, 프로젝트 셋업에서 package.json이 하는 역할을 잘 알고, 적절하게 의존성 모듈을 설치할 줄 아는구나 다행이다. HTML 태그 종류와, 속성들을 잘 알고 있구나 휴...다행이다. 그래도 성장은 했구나.

160번 이후에는 express 모듈과 미들웨어를 활용한 라우팅 관련 실습예제들이었다. HTML Form에서 데이터를 보내면, 백엔드에서는 이 데이터를 어떻게 다루고, 응답은 어떻게 해 주는지 얼핏 알지만, 더 정확하게 알고싶어졌다. 이제 회사에서 백엔드 개발도 해야하기에 필요한 지식이었다.

그래서 161번부터 실습예제를 빠르게 따라해보고 있는 중이다.

body-parser 미들웨어

express 모듈 기준에서 미들웨어는 <request 수신>- <미들웨어> - <response 송신> 그 사이에서 다양한 작업을 처리해주는 소프트웨어(로직)으로 이해했다.

redux-toolkit에서도 스토어 셋업 시 미들웨어 미들웨어 개념이 나와서 공부했었던 기억이 있기에, 미들웨어 그 자체가 무엇인지에 대해서 이해하는데 많은 시간이 들지는 않았다.

express모듈에는 다양한 미들웨어를 추가하여 사용할 수 있는데, 그 중 body-parser라는 미들웨어 모듈을 사용하는 예제가 있었다.

전체 코드는 다음과 같다.

<login.html>

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Login page</title>
  </head>
  <body>
    <h1>Login</h1>
    <hr />
    <form method="post" action="/login">
      <table>
        <tr>
          <td>
            <label for="userId">UserId</label>
            <input type="text" name="userId" />
          </td>
          <td>
            <label for="password">PW</label>
            <input type="password" name="password" />
          </td>
        </tr>
        <tr></tr>
      </table>
      <input type="submit" value="confirm" name="" />
    </form>
  </body>
</html>

<app.js>

const path = require("path");
const express = require("express");
const bodyParser = require("body-parser");
const app = express();
const port = 5500;

app.use(express.static(path.join(__dirname, "./html")));

/**
 * @description bodyParser.urlencoded 를 설정하지 않으면 앱이 동작을 하지 않는다.
 */
app.use(bodyParser.urlencoded());
app.use(bodyParser.json());

/**
 * 미들웨어를 여러개를 순차적으로 엮을 수 있다.
 */
app.use((request, response, next) => {
  console.log(request.body);
  console.log("first middleware");
  request.user1 = "승록";
  next();
});

app.use((request, response, next) => {
  console.log("second middleware");
  request.user2 = "승재";
  next();
});

app.use((request, response, next) => {
  console.log("third middleware");
  next();
});

app.get("/", (req, res) => {
  res.sendFile(path.join(__dirname, "./html/index.html"));
});

app.get("/login", (req, res) => {
  res.status(200).set("Content-Type", "text/html");
  res.sendFile(path.join(__dirname, "./html/login.html"));
});

app.post("/login", (req, res) => {
  const { userId, password } = req.body;
  if (!userId || !password) {
    return res.status(400).json({ error: "Missing id, pw" });
  }
  res.status(200).set("Content-Type", "application/json");
  const jsonData = {
    date: new Date(),
    userId,
    password,
  };
  res.json(jsonData);
});

app.get("/error", (req, res) => {
  res.status(404).send("<h1>404 ERROR</h1>");
});

app.listen(port, () => {
  console.log(`Example app listening to port${port}`);
});

문제상황

app.use(bodyParser.urlencoded({ extended: false }));

처음에는 위 구문 없이 앱을 구동했다. 그랬더니 request.body가 비어있는 객체가 나오는 것이 아닌가?

원인

body-parser의 urlencoded의 extended옵션이 어떤 역할을 하는지 무엇인지 궁금해졌다. 대체 뭐길래 저게 있고 없고가 form에서 post요청으로 보낸 body의 데이터를 읽어서 채우고 말고를 결정하는 것인가? 책에는 나와있지 않아 직접 찾아보았다.

body-parser 레포지토리 링크

밝혀진 진실

urlencoded 바디만 파싱해서 만든 새로운 body 객체를 reqeust.body에 반영시키는 역할을 하는 미들웨어 기능이었다.

그 중 extended 옵션은 querystring라이브러리와 qs라이브러리 둘 중 어느 것을 사용하여 URL-encoded 데이터를 파싱할 지 고르는 옵션이었다. 결국 이 둘의 차이를 알고 있어야 사용할 수 있는 옵션이었던 것이다.

나는 여기서 세 가지 모르는 점이 생겼다.

• URL-encoded body object가 뭐야?
• querystring 라이브러리는 뭐야?
• qs 라이브러리는 뭐야?

하지만 그 중에서 첫 번째 의문점만 이 글에서는 알아보았다.

URL-encoded body object

URL-encoded body 는 클라이언트가 서버로 key value쌍의 형식의 데이터를 URL-encoded 포맷으로 인코딩하여 보낸 데이터를 뜻한다.

여기서 URL encoding이란, 문자를 인터넷상에서 전송될 수 있는 형식으로 변환하는 것을 의미한다.

이렇게 인코딩된 문자들은 결국 클라이언트측에서 설정한 대로 작성되기에, 우리는 데이터의 출처인 클라이언트 코드를 봐야한다.

내 코드의 예시에서는 <form> 태그가 데이터의 출처니, form 에서 어떻게 입력값이 변환되어 서버로 전달되는지가 내 지식의 공백이겠다.

HTML form 태그의 데이터 전송 방식

Mozilla POST 에서는 HTML form태그에서 수행되는 POST방식의 요청의 경우에, content-type을 enctype속성에 명시할 수 있다고 한다.

이 때 세 가지 content-type을 줄 수가 있는데,

• application/x-www-form-urlencoded
• multipart/form-data
• text/plain

그 중에서, application/x-www-form-urlencoded형식을 채택한 경우에는 알파벳이 아닌 문자가 URL-encoded된다고 한다. 그리고 application/x-www-form-urlencoded는 form 태그요소의 기본 MIME type이다.

가령

<form method="post" action="/submit">
  <label for="username">Username:</label>
  <input type="text" id="username" name="username">
  <label for="password">Password:</label>
  <input type="password" id="password" name="password">
  <button type="submit">Submit</button>
</form>

이런 form이 있을 때, submit된 데이터는 아래의 형식으로 인코딩이 된다. 서버는 아래 형식으로 인코딩된 데이터를 파싱해서 원래 데이터 형식으로 복원하는 작업이 필요했던 것이다.

username=user123&password=secret123

결론

body-parser 모듈의 urlencoded() 메서드는 서버로 들어온 application/x-www-form-urlencoded 포맷의 데이터를 파싱하기 위한 작업을 하는 미들웨어함수였다.

더불어 json()메서드는 서버로 들어온 application/json 포맷의데이터를 파싱하기 위한 작업을 하는 미들웨어 함수였다.

이렇게 파싱이 된 데이터를 우리의 서버 코드는 그제서야 알아보고 후속 작업을 진행할 수 있는 것이었다.

아하~ 그랬군!

<form>태그에 default MIME type 이 있다는 것을 처음 알아서 가장 유익했고, 서버는 다양한 형식으로 서버에 전송되는 데이터를 처리할 수 있어야 하기에, 대비가 되어있어야 한다는 점이 재미있었다.

오늘 참 유익했다~

Defining a signal in the __init__ function of a class versus defining it outside the __init__ function has a significant difference in terms of scope and visibility.

1. Defining in __init__:
   • When you define a signal in the __init__ function of a class, it becomes an instance attribute of that class. This means that each instance of the class will have its own signal attribute.
   • Signals defined in __init__ are accessible only within the instance of the class where they are defined. Other instances of the same class will have their own separate signal attributes.

Example:

from PySide6.QtCore import QObject, Signal

class MyClass(QObject):
    def __init__(self):
        super().__init__()
        self.my_signal = Signal()

# Usage
obj1 = MyClass()
obj2 = MyClass()

# obj1 and obj2 have their own separate instances of my_signal

2. Defining outside __init__:
   • When you define a signal outside the __init__ function (as a class attribute), it becomes a class-level attribute.
   • Signals defined outside __init__ are shared among all instances of the class. They behave like static members of the class.

Example:

from PySide6.QtCore import QObject, Signal

class MyClass(QObject):
    my_signal = Signal()

# Usage
obj1 = MyClass()
obj2 = MyClass()

# obj1 and obj2 share the same instance of my_signal

In Summary:

• If you define a signal in the __init__ function, each instance of the class will have its own signal attribute. This can be useful if you need different instances to emit signals independently.
• If you define a signal outside the __init__ function, it becomes a class-level attribute shared among all instances. This can be useful if you want all instances to share the same signal, such as for notifying about global events or state changes.