분류 전체보기

새로운 프로젝트를 준비하면서, 이전에는 JWT를 사용해 유저 인증과 상태 관리를 했지만, 이번에는 Redis를 활용한 세션 방식으로 전환하기로 결정했다. 이와 같은 방식은 유저 상태를 서버에서 직접 관리할 수 있어 보안과 세션 무효화 측면에서 더 유리하다. Redis를 도입한 김에, 인증 외의 일부 기능에도 캐싱을 적용해보자는 이야기가 나왔다.두 기능이 하나의 방식으로 처리될 것이라 예상했지만, 실제로 구현에 들어가 보니 세션 관리와 캐싱은 Redis를 사용한다는 점만 같을 뿐, 접근 방식과 구조가 꽤나 달랐다. 세션 관리는 주로 사용자별 데이터를 일정 시간 유지하고, 주기적으로 갱신하거나 만료시키는 로직이 중심이 되는 반면, 캐싱은 특정 요청에 대한 응답을 빠르게 반환하기 위한 키 기반의 저장 및 조회..

이번 주, sicilian과 caro-kann 모두 3.1 버전을 공개했다. 하나는 폼 관리 도구이고 다른 하나는 전역 상태 관리 도구라는 차이가 있지만, 이번 업데이트에서는 공통적으로 '런타임 타입 체크' 기능이 추가되었다. sicilian의 경우, 이전에도 내장된 validator를 통해 런타임 타입 검증이 가능했으나, zod, yup, superstruct와 같은 외부 스키마 라이브러리를 활용해 사용자 정의 검증 로직을 통합하는 방법은 존재하지 않았다. 그러나 3.1 버전부터는 이러한 스키마 라이브러리들과의 연동이 간편해졌고, 폼 데이터의 유효성 검사는 물론 구조와 타입까지도 런타임에서 명확하게 검증할 수 있게 되었다.sicilian에 외부 스키마 라이브러리를 통합하는 것은 오래전부터 품어온 염원이..

프론트엔드 개발자들 모인 자리에 가서 '어떤 스타일링 라이브러리 좋아하세요?'하고 물어보면 못해도 30분은 할 이야기가 생긴다. 내 경우에는 여러번 밝힌 바와 같이 TailwindCSS와 ModuleCSS를 선호한다. 하지만 내 선호를 밝히면 늘 돌아오는 질문이 있다. '그것들은 동적 스타일링하기 불편하지 않아요?'하고.요즘 사용자를 늘려가고 있는 Vanila-extract나 이제는 죽어버린 StyledComponent와 비교하면 앞서 언급한 두 라이브러리는 확실히 동적 스타일링에 취약하다. 특히 TailwindCSS는 빌드 과정에서 사용된 클래스 이름만 추출해서 최종 CSS를 생성하는 'content scanning' 과정이 필요한데, 이 때문에 아래와 같이 동적으로 클래스 이름을 조합하거나 조건부로 ..

이번 달 초, AWS 요금 청구서를 확인하고 자빠질 뻔했다. 프리티어가 끝난 데다 원달러 환율이 치솟으면서 12만 원이 넘는 요금이 결제된 것이다. AWS에 배포해 둔 프로젝트는 나만의 작은 독후감 작성 및 공유 사이트인 onef.co.kr 뿐인데, 아무리 애정이 가는 프로젝트라 해도 한 달에 12만 원은 참을 수 없다. 그리하여 나는 내가 가진 모든 AWS 지식을 긁어모아 ─ 마침 이번달에 AWS SAA C03을 취득했다. 만세! ─ 요금을 최대한 줄여나가보기로 했다. AWS Cost Explorer에 들어가면 어떤 서비스에서 얼마나 청구되었는지 자세히 확인해볼 수 있다. 내 경우는 EC2-인스턴스와 ELB, 그리고 VPC가 요금의 대부분을 차지하고 있다.그럴 수 밖에 없는 게 지금 내 서비스 아키텍쳐..

프론트엔드 개발을 하다보면 백엔드가 없는 상태에서 일단 뷰를 완성해야 할 때가 있다. 프로젝트의 극 초기라면 백엔드 인터페이스가 하루에 두 번씩 변하는 만큼 난장판도 그런 난장판이 없다. 이런 환경에서 초기 Mock 데이터를 통해 뷰를 구성하고, 이후 백엔드 인터페이스를 연결하는 일련의 과정을 나는 Mock First Development라고 부르고 있다.이번 포스트에서는 아주아주 간단한 '프로필 기능'을 만들어보며 [ RAD 아키텍처 ] 를 활용해 안전하게 Mock First Development를 수행하는 일련의 과정을 간단히 알아보고자 한다. Adaptor와 MockRAD 아키텍처의 A to Z는 어댑터 클래스에 있다고 해도 과언이 아니다. 우선 백엔드 인터페이스가 어떤 모습이 될 지는 모르겠지만,..

원래는 "프론트엔드에서 데이터를 페칭할 때 리액트 쿼리를 효과적으로 구조화하기 위해 레포지토리 패턴, 어댑터 패턴, 데코레이터를 활용하는 아키텍처"인데, 내가 워낙 이름 짓는데 소질도 없고 하여 적용되는 패턴들의 앞글자를 따 RAD 아키텍처라 부르고 있다.레포지토리 패턴은 데이터 액세스를 추상화하여, 컴포넌트가 서버와 직접적으로 상호작용하지 않도록 한다. 어댑터 패턴은 서버에서 반환되는 데이터 구조를 클라이언트에서 필요로 하는 형태로 변환하고, 데코레이터는 각 메서드에 직접적으로 어댑터를 적용한다. 이를 도표로 나타내면 아래와 같다. RAD 아키텍처는 Query 흐름과 Mutation 흐름을 분리하여 설계한다. 다만 근본적인 구조 자체는 동일하다 할 수 있기에 이 포스트에서는 ─ 분량이 너무 늘어날까봐 ..

[ data fetching on react.js ] 에서 나는 Fetcher ➠ Query ➠ DomainQuery로 이어지는 클래스의 상속 관계 끝에 뜬금없이 useAdaptor라는 훅을 끼워넣었다. 이는 일반적인 훅의 규칙을 따르기 위함이었다. useQuery나 useMutation와 같은 커스텀 훅을 호출하기 위해서는 반드시 추가적인 커스텀 훅이 필요하다는 것이 이 바닥의 상식이다.그러나 나는 [ Breaking the Rules of Hooks ] 포스트를 통해 실제로는 커스텀 훅을 호출하기 위해 반드시 추가적인 커스텀 훅이 필요한 것은 아니며 ─ 각각의 규칙이 제시된 기저 이유를 깊게 이해한다는 전제 하에 ─ 클래스 내부에서도 훅을 사용할 수 있는 우회적인 방법이 존재한다는 사실을 알게되었다...

기존 자바스크립트 사용자들은 객체의 속성 접근을 감지하거나 동작을 변경하기 위해 Object.defineProperty() 같은 방법을 사용했다. 그러나 여기에는 동적 속성 추가나 함수 호출과 같은 동작을 탐지하는 데 어려움이 있었다. 이를 해결하기 위해 자바스크립트에 Proxy 처리기가 도입되었다. 이 클래스는 get, set, apply 등 다양한 트랩(trap)을 제공하여 객체의 속성 접근, 값 변경, 삭제, 함수 호출 등의 동작을 자유롭게 제어할 수 있도록 한다. 아마도 이것이 Proxy 처리기에 대한 일반적인 인식일 것이다. 나도 큰 틀에서는 이러한 인식에 동의한다. 사소한 문제가 하나 있다면, 나는 '객체의 속성 접근을 감지하거나 동작을 변경'해야할 필요를 느끼지 못했다는 것이다. 더 자세히 ..

우선 밝혀두자면 이 포스트는 단 하나의 궁금증으로부터 출발했다. '어떻게 input 태그는 state 없이 ─ 그리하여 리랜더링 없이 ─ value 값을 변경하지?' 보통은 input:value에 state를 달아 제어 컴포넌트로 만들지만, 그렇게 하지 않아도 input은 멀쩡히 동작한다. 당장 리액트 커뮤니티에서 가장 광범위하게 사용되는 form 관리 라이브러리 중 하나인 react-hook-form만 하더라도 ref를 기반으로 동작하니까. state 없이도 DOM이 변경되는지를 확인해보기 위해 아래와 같은 테스트 코드를 작성해보았다. 버튼을 누르면 input:value의 값을 div의 innerText로 박아버리는 아주 간단한 동작을 처리한다.export default function Page() {..

이전에 [ 분배 법칙에서의 타입 추론 컨텍스트 ] 포스트를 통해 나는 타입스크립트에서 분배 법칙이 일어날 때 그 컨텍스트가 유지된다는 것을 확인했고, 이를 기반으로 복잡한 조건부 타입에서도 원하는 타입 추론을 이끌어낼 수 있다는 점을 알게 되었다. 그런데 Caro-Kann 다음 버전의 persist migration을 처리하기 위한 MigrationPipe 타입을 설계하는 중에 한 가지 이상한 현상을 발견하게 되었다. 내가 만든 상태 관리 라이브러리 Caro-Kann은 persist 버전 migration을 아래와 같이 처리하고 있다. persist 버전이 몇 개 없다면 괜찮겠지만, 버전이 조금만 늘어나도 정확한 migration을 담보할 수 없는 상황이다. 게다가 이전 버전들이 어떤 구조로 되어있는지 ..

프론트엔드 개발을 하다 보면 컴포넌트의 props로 number 타입을 받을 때가 많다. 하지만 단순히 number 타입만 지정하면 값의 범위를 제한할 수 없다는 점이 아쉽다. 예를 들어, 페이지네이션의 currentPage는 1 이상의 값만 허용해야 하고, 슬라이더의 value는 최소/최대 값을 벗어나지 않아야 한다. 이를 보완하기 위해 TypeScript의 타입 시스템을 활용해 특정 범위 내의 숫자만 허용하는 유틸리티 타입 IsInRange를 만들어야겠다고 생각했다. 처음에는 아래와 같이 재귀적으로 타입을 호출하며 범위 내에 특정 숫자 리터럴 타입이 존재하는지를 검사했다. 이러한 방법은 논리적으로 문제가 없지만, 실제로는 몇 가지 하자가 존재한다. 우선 범위가 1000이 넘어가버리면 콜스택이 폭발해버..

유니온 타입의 분배 법칙TypeScript에서 제네릭 타입의 자리에 유니온 타입이 오게 되면, 타입 연산 ─ 주로 조건부 타입, 맵드 타입, 템플릿 리터럴 타입, 스프레드 연산 등 ─ 과 결합될 때 분배 법칙(distributive law)이 적용된다. 이는 제네릭 타입이 유니온 타입을 받을 경우, 개별 요소에 대해 조건부 타입이 각각 평가된다는 의미이다. 예를 들어, 다음과 같은 조건부 타입을 고려해 보자. 위 코드에서 T에 "hello" | 42가 들어가면, 단순히 string과 비교하는 것이 아니라 각 요소가 개별적으로 평가된다. 이를 naked 타입이라고도 부른다.type Example = T extends string ? number : boolean;type Result = Example;//..