지난번 Void는 Vite 네이티브 배포 플랫폼이라는 글에서 "이게 자바스크립트의 Rails가 될 수 있을까"를 다뤘는데요. 그때는 직접 써보지 않고 개념만 파헤친 소개글이었습니다. 이번엔 다릅니다. TanStack Start + Cloudflare Workers + D1으로 운영 중이던 실서비스를 하루 만에 Void로 컷오버하면서 직접 부딪힌 기록이에요. 결론부터 말씀드리면 코드 변경은 거의 없었고, 빌드는 3배 빨라졌고, 그리고 베타 제품답게 문서에 없는 지뢰를 다섯 개나 밟았습니다. 💥 이 글은 그 지뢰들을 어떻게 역공학으로
Void 라우팅에서 데이터를 읽어 오는 로더는 자세히 봤는데요. 정작 데이터를 바꾸는 쪽은 "로더 대신 action을 내보낸다"는 한 줄로 넘어갔습니다. 사실 폼을 다루는 일은 읽기보다 손이 많이 가죠. 입력값을 검증하고, 에러를 화면에 표시하고, 제출 중에는 버튼을 막고, 성공하면 목록을 새로고침하고… 이번 글에서는 Void가 이 과정을 useForm 하나로 어떻게 묶어주는지 살펴보겠습니다. 액션으로 데이터 바꾸기 데이터를 읽을 때 로더를 썼다면, 바꿀 때는 액션을 씁니다. 페이지의 .server.ts에서 action을 내보내면
Void: Vite 네이티브 배포 플랫폼에서 데이터베이스를 소개할 때 "로컬에서는 SQLite, 프로덕션에서는 Cloudflare D1로 매핑된다"는 한 줄로 짚고 넘어갔는데요. 이번엔 그 데이터베이스 레이어를 제대로 들여다볼게요. 스키마는 어떻게 정의하고, 마이그레이션은 어떻게 굴리고, 쿼리는 어떻게 날리는지까지 차근차근 살펴보겠습니다. Void 라우팅에서 API 핸들러에 insertUserSchema로 입력을 검증하는 예제를 봤는데, 그 검증기가 어디서 오는지도 이 글에서 채워집니다. 로컬은 SQLite, 프로덕션은 D1 Voi
Void: Vite 네이티브 배포 플랫폼에서 프로젝트 구조를 훑어볼 때 pages/와 routes/ 디렉토리를 잠깐 스쳐 지나갔는데요. 사실 이 두 디렉토리가 Void로 앱을 만드는 거의 모든 것을 담당합니다. 화면을 그리는 일도, API를 여는 일도 결국 "어떤 파일을 어디에 두느냐"로 결정되거든요. 이번 글에서는 Void의 라우팅을 제대로 파헤쳐볼게요. 파일 하나가 어떻게 URL이 되는지, 서버에서 가져온 데이터가 어떻게 화면 컴포넌트로 흘러가는지, API 핸들러는 어떻게 쓰고 입력 검증과 미들웨어는 어떻게 거는지까지 차근차근
Vite+가 로컬 개발 도구를 하나로 통합했다면, 이번에는 배포까지 먹으러 왔습니다. VoidZero가 내놓은 Void는 Vite 앱에 플러그인 하나를 추가하고 void deploy 한 방이면 데이터베이스, 인증, KV 스토리지, 큐까지 갖춘 풀스택 애플리케이션이 Cloudflare Workers 위에 올라가는 배포 플랫폼입니다. "자바스크립트에 드디어 Rails 순간이 온 건가, 아니면 그냥 Cloudflare 종속에 리본을 달아놓은 건가?" 궁금해서 Void가 뭘 하는 건지 직접 파헤쳐봤습니다. Vite+와 Void의 관계 먼저
React로 풀스택 앱을 만들 때 어떤 프레임워크를 쓰시나요? 아마 Next.js를 먼저 떠올리실 텐데요. Next.js가 사실상 표준처럼 자리 잡긴 했지만 쓰다 보면 아쉬운 점도 있습니다. 타입 안전성이 중간중간 끊긴다거나, 캐싱 동작이 예상과 다르게 돌아간다거나, 배포할 때 특정 플랫폼에 묶이는 느낌이 든다거나요. 그런 분들에게 TanStack Start가 반가울 겁니다. TanStack Query와 TanStack Table로 유명한 TanStack 생태계에서 나온 풀스택 React 프레임워크인데요. "엔드투엔드 타입 안전성"
예전에 RedwoodJS로 풀스택 웹 앱 만들기라는 글에서 RedwoodJS를 소개해드린 적이 있는데요. React, GraphQL, Prisma를 하나로 묶어서 풀스택 앱을 빠르게 만들 수 있게 해주는 프레임워크였죠. 그 글 마지막에 잠깐 언급했던 RedwoodSDK가 2025년 3월 드디어 v1.0으로 정식 출시되었습니다. RedwoodSDK는 기존 RedwoodJS의 후속작이라기보다는 완전히 새로운 프레임워크에 가깝습니다. GraphQL과 Prisma 중심이었던 기존 접근 방식을 버리고, React Server Componen
Bun이 Node.js를 잇는 차세대 자바스크립트 런타임으로 급 부상하면서, Bun을 위해서 탄생한 웹 프레임워크인 Elysia도 큰 관심을 받고 있습니다. 이번 포스팅에서는 Elysia의 주요 특징과 사용법, 그리고 Elysia가 다른 웹 프레임워크와 어떻게 차별화되는지에 대해서 살펴보겠습니다. Elysia란? Express 프레임워크가 Node.js 생태계에서 대표 웹 프레임워크를 담당하고 있다면 Elysia는 Bun 생태계에서 비슷한 역할과 인지도를 갖고 있는 하고 있는 웹 프레임워크입니다. 물론 간단한 웹 서버를 개발할 때는
Node.js로 웹 서버를 만들 때 오랫동안 Express가 사실상 표준이었는데요. 그런데 최근 몇 년 사이에 Cloudflare Workers, Deno, Bun 같은 새로운 런타임들이 등장하면서 상황이 달라지고 있습니다. Express는 Node.js에 특화되어 있어서 다른 런타임에서 그대로 쓸 수 없거든요. 이런 흐름 속에서 Hono가 주목받고 있습니다. Hono는 웹 표준(Web Standards) API 위에 만들어진 경량 웹 프레임워크로, 같은 코드가 Bun이든 Deno든 Cloudflare Workers든 어디서나 돌아
이번 글에서는 NestJS에서 API의 버전을 체계적으로 관리하는 방법에 대해서 배워보도록 하겠습니다. API Versioning이란? REST API와 같은 서버 애플리케이션을 운영하다 보면, 부득이하게 클라이언트에 큰 영향을 줄 수 있는 위험한 변경을 해야 할 때가 있는데요. API Versioning, 즉 버전 관리를 통해서, 우리는 서버 측 API 변경에 따른 클라이언트의 영향을 최소화하고, API의 호환성과 안정성을 높일 수 있습니다. 버전 관리가 이루어지는 API는 보통 클라이언트에게 v1, v2, v3... 이런 식으로
최근에 웹 개발에 대해서 얘기할 때 메타 프레임워크(Meta Framework)라는 용어를 한 번쯤 써보셨거나 적어도 들어보셨을텐데요. 하지만 자주 쓰이는 용어임에도 불구하고 막상 메타 프레임워크가 뭔지 설명해보려고 하면 쉽지 않은 것 같죠? 이번 글에서는 요즘 유행하는 메타 프레임워크가 전통적인 프레임워크와 어떻게 다르며 왜 필요한지에 대해서 알아보았습니다. 그리고 현재 시장에 어떤 메타 프레임워크가 주목받고 있는지도 간단히 살펴보겠습니다. 메타 프레임워크의 특징 우리가 기존에 프레임워크를 생각할 때는 보통 어떤 프로그래밍 언어를
이번 글에서는 가드(Guard)를 활용하여 NestJS 앱을 위험한 요청으로 부터 효과적으로 보호하는 방법에 대해서 배워보도록 하겠습니다. 가드(Guard)란? NestJS에서 가드(guard)란 애플리케이션의 최전선에서 말그대로 애플리케이션을 보호하는 역할을 담당하는데요. NestJS로 들어오는 요청은 컨트롤러(controller) 단에 도달하기 전에 반드시 가드를 거쳐가도록 되어 있습니다. 가드를 이용하면 컨트롤러가 요청을 처리하기 전에 안전하지 않은 요청을 효과적으로 차단할 수 있습니다. 따라서 애플리케이션 보안을 위해서 필수
어떤 웹 프로젝트를 하든 브라우저의 내장 스타일에 영향을 최소화하면서 일관적인 UI를 구현하는 것은 매우 중요한 고려사항인데요. 이번 포스팅에서는 Tailwind에서 제시하고 있는 이러한 CSS 초기화 문제에 대한 해답인 Preflight에 대해서 알아보겠습니다. Preflight란? Preflight는 Tailwind에서 가장 근간이 되는 기본 스타일시트(stylesheet)이며 Tailwind로 스타일한 웹 페이지가 어느 브라우저에서 열든 일관적으로 보이도록 해주는데요. Tailwind를 사용하는 것을 "비행"이라고 비유하여 T
Tailwind가 좋다는 소문을 듣고 막상 써보려고 해도 초기 설정에서 어려움을 겪을 수 있는데요. tailwindcss 패키지 뿐만 아니라 postcss, autoprefixer와 같은 추가적인 패키지 설치도 필요한데다가, tailwind.config.js와 postcss.config.js 등 설정이 다소 복잡하게 다가올 수 있기 때문입니다. 이러한 Tailwind의 진입 장벽을 느끼시는 분들을 위해서 이번 포스팅에서는 Play CDN을 사용해서 번거로운 초기 설정을 건너띄고 좀 더 간편하게 Tailwind를 써볼 수 있는 방법에
Tailwind는 최근 웹 개발 분야에서 상당히 인기를 끌고 있는 차세대 CSS 프레임워크인데요. 워낙 호볼호가 많이 갈리다보니 개발자 커뮤니티에서 단골 논쟁거리가 되기도 합니다. Tailwind에 대한 첫 번째 포스팅으로 이번 글에서는 Tailwind에 대한 기본 개념과 기존에 우리가 스타일링해온 방식과 비교해서 무엇이 다른지에 대해서 간략하게 알아보겟습니다. Tailwind란? Tailwind는 쉽게 말해 엄청나게 많은 유틸리티(utility) 클래스로 이루어진 CSS 프레임워크입니다. Tailwind가 제공하는 유틸리티 클래스
유지보수가 용이하고 안정적으로 동작하는 NestJS API를 개발하려면 각각의 엔드포인트가 잘 작동하는지 확인하는 것이 필수적입니다. 이번 글에서는 Jest와 Supertest를 활용하여 효과적으로 NestJS 앱을 테스트하는 방법에 대해서 알아보겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요. 터미널에서 NestJS CLI 도구의 nest new 명령어를 실행하여 새로운 프로젝트를 구성하도록 하겠습니다. NestJS CLI를 설치하고 NestJS 프로젝트를 구성하는 기본적인
NestJS 앱을 개발,테스트, 운영 등 다양한 환경에 배포하려면 어느 환경에 배포하느냐에 따라서 다르게 설정되야하는 값들이 생기기 마련이죠? 이번 포스팅에서는 NestJS 앱에서 이렇게 환경 별로 달라지는 설정 값들을 어떻게 효과적으로 관리할 수 있는지 알아보겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요. 터미널에서 NestJS CLI 도구의 nest new 명령어를 실행하여 새로운 프로젝트를 구성하도록 하겠습니다. NestJS CLI를 설치하고 NestJS 프로젝트를 구
최근에 ORM으로 Prisma를 선택하는 자바스크립트 또는 타입스크립트 프로젝트가 부쩍 많아진 느낌입니다. 이번 포스팅에서는 차세대 ORM 프레임워크로 각광받고 있는 Prisma에 대해서 함께 알아볼까요? Prisma란? Prisma는 자바스크립트와 타입스크립트 커뮤니티에서 주목받고 있는 차세대 ORM(Object Relational Mapping) 프레임워크입니다. 데이터베이스와 상호작용하는 응용 애플리케이션을 개발할 때, 프로그래머가 직접 SQL을 작성하지 않아도 되므로, 개발 생산성을 높여주는 측면에서 기존에 사용되던 Sequ
마이크로서비스(microservices) 아키텍처나 분산 시스템 환경에서는 모든 서비스가 정상적으로 살아서 동작하는지를 검사하는 것이 매우 중요합니다. 이를 위해서 각 서비스에 생존 여부(liveness)와 가용 여부(readiness)를 응답해주는 HTTP 엔드포인트(endpoint)가 필요하기 마련인데요. 이번 포스팅에서는 NestJS 앱에서 이러한 엔드포인트(endpoint)를 어떻게 구현할 수 있는지에 대해서 알아보도록 하겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요
로깅(logging)은 애플리케이션에서 발생하는 각종 이벤트에 대한 기록을 남기고 문제 발생 시 원인을 파악하는데 핵심적인 역할을 하는데요. 이번 포스팅에서는 NestJS 앱에서 어떻게 로거(logger)를 사용하고 커스터마이징(customizing)할 수 있는지 알아보겠습니다. 실습 프로젝트 구성 먼저 간단한 실습을 위해서 NestJS 프로젝트가 하나 필요할 것 같은데요. 터미널에서 NestJS CLI 도구의 nest new 명령어를 실행하여 새로운 프로젝트를 구성하도록 하겠습니다. NestJS CLI를 설치하고 NestJS 프로