Node.js

들어가며 지난 글에서 Plan 도메인의 CRUD API를 모두 구현했다. 이제 과제를 시작하기 전에 진행했었던 Playwright MCP를 에이전트에 붙여 E2E테스트 자동화 하는 과정을 현재 앱에 적용하여 보겠다. Playwright Playwright는 마이크로소프트에서 만든 브라우저 자동화 도구다. 원래는 웹 페이지를 자동으로 클릭하고, 폼을 채우고 스크린샷을 찍는 등의 E2E 테스트를 위해 만들어졌다. Selenium이나 Puppeteer 같은 도구와 비슷하지만 다음과 같은 몇 가지 장점이 있다. 빠른 실행 속도 - 다른 도구들보다 빠르다 안정적인 테스트 - 요소가 나타날 때까지 자동으로 기다려준다 다양한 브라우저 지원 - Chromium, Firefox, WebKit 모두 지원 API 테스트 가능 - 브라우저 없이도 HTTP 요청을 보낼 수 있다 플레이라이트는 request fixture라는 걸 제공해서, 실제 브라우저를 띄우지 않고도 API 테스트를 할 수 있다. ...

들어가며 지난 글에서 환경변수 관리와 데이터베이스 플러그인 설정까지 마쳤다. 이제 비즈니스 로직을 구현할 차례다. 스프링에서는 Controller, Service, Repository로 계층을 나눠서 개발했었는데 fastify에서도 비슷한 구조를 유지하려고 했다. Controller 대신 Routes라고 부르고, DTO 클래스 대신 Zod 스키마를 사용하는 등 약간의 차이점은 있었다. 이번 글에서는 Plan 도메인의 CRUD API를 node.js 환경으로 전환했던 과정을 정리해보려고 한다. Zod를 사용하여 스키마 작성 핵심로직, 라우트 등을 먼저 구현하기 전에 스프링 코드와 대칭되는 DTO를 작성했다. 라우트 내부에서 schema 블럭에 요청DTO의 형식을 정할 수도 있지만 Zod라는 것을 사용해봤다. ...

들어가며 지난 글에서 prisma를 설치하고 마이그레이션까지 성공했다. 이제 실제로 애플리케이션에서 데이터베이스를 사용할 수 있도록 연동 작업을 진행해야 한다. 스프링 부트에서는 application.yml에 데이터베이스 설정만 해두면 자동으로 연결이 되고, 생성자 주입으로 Repository를 주입받아 사용하면 끝이었다. 하지만 fastify는 그런 자동화가 없다. 모든 걸 직접 설정해야 한다고 한다. 이번 글에서는 환경변수를 타입 안전하게 관리하고, prisma를 fastify 플러그인으로 등록하는 과정을 정리해보려고 한다. 환경변수 관리의 문제 기존에는 server.ts에서 이렇게 환경변수를 사용하고 있었다. const PORT = Number(process.env.PORT) || 3000; 문제는 이렇게 사용하면 ...

들어가며 이전 포스팅에서 프로젝트 환경 셋업을 진행한데 이어, 데이터베이스 연동을 해보려고한다. 스프링에서는 jpa와 hibernate를 사용해서 엔티티 관리가 비교적 편했는데, node 생태계에서는 어떤 ORM이 좋을지 고민이 많았다. TypeORM도 고려했지만 이전에 잠깐이나마 회사에서 prisma를 사용해보기도 했고, 타입 안정성과 직관적인 스키마 작성 방식이 마음에 들어서 prisma로 결정했다. 이번 글에서는 prisma를 처음 설정하면서 겪었던 시행착오와 해결 과정을 공유하려고 한다. Prisma 초기 설정 패키지 설치 Prisma를 사용하려면 두 가지 패키지가 필요하다. npm install prisma @prisma/client prisma: CLI 도구 및 스키마 관리 @prisma/client: 실제 쿼리를 실행하는 클라이언트 Prisma 초기화 설치가 끝나면 초기화 명령어를 실행한다. ...

들어가며 최근 스프링부트로 구현된 REST API 프로젝트를 node.js, fastify 환경으로 마이그레이션 하고, 클로드 코드 및 코파일럿 등의 에이전트에 PlayWright MCP서버를 연동하여 E2E 테스트를 자동화하는 과제를 진행하게 되었다. 과제 진행을 하면서, 새롭게 학습하고 그 과정 속에서 힘들었던 부분 등을 기록하고자 한다. 이번 글에서는 본격적인 마이그레이션 작업에 앞서, Node.js + TypeScript + Fastify 기반의 프로젝트 환경을 세팅한 과정을 정리해보려고 한다. 목표 기존 Spring Boot 프로젝트는 전형적인 레이어드 아키텍처로 구성되어 있다. Controller -> Service -> Repository -> Entity (JPA) 이 구조를 최대한 유지하면서 node 환경으로 옮기는 게 우선적인 목표다. 다만 스프링의 의존성 주입이나 자동 설정 같은 편의 기능이 없으니 그 부분을 어떻게 해결할지 고민이 많았다. ...