Spring Boot -> GraphQL — 라우팅과 코드베이스 분석서론1편에서는 REST와 GraphQL의 근본적인 패러다임 차이 — 라우팅 키, 데이터 결정권, Gateway의 진화 — 를 다뤘다. 이번 편에서는 한 단계 더 들어간다."Controller가 없는데 요청이 어떻게 Resolver까지 도달하는가?"의 내부 동작,"GraphQL인데 왜 GET 요청이 보이는가?"의 비밀(APQ와 3계층 캐싱),그리고 Spring 개발자가 NestJS + GraphQL 코드베이스를 처음 열었을 때 어떤 순서로 파일을 읽어야 하는가에 대한 정리1. Controller 없이 어떻게 라우팅할까? — GraphQL 엔진의 AST 파싱Spring의 라우팅 복기Spring에서 요청이 처리되는 내부 흐름을 먼저 복기하자...

Spring Boot 개발자가 GraphQL을 만났을 때 — REST vs GraphQL 패러다임 시프트서론: 왜 이 글을 쓰는가Java/Spring Boot 기반의 REST API 환경에서 학습하다가,Node.js + NestJS + GraphQL(Apollo Federation) 기반의 MSA 환경으로 넘어오게 되었다. 가장 먼저 부딪힌 것은 패러다임의 충돌이었다.Controller가 없는데 요청이 어떻게 처리되는지, URL이 하나뿐인데 라우팅은 어떻게 되는지, Gateway가 URL이 아니라 "타입"을 보고 분기한다는 게 무슨 뜻인지 — 기존의 학습 방향성이 전혀 통하지 않았다.이 글은 Spring Boot의 REST API에 익숙한 백엔드 개발자가 GraphQL로 전환할 때 겪는 핵심적인 패러다임..

NestJS MSA 로컬 개발 환경 구축 트러블슈팅 기록들어가며NestJS 기반 마이크로서비스 아키텍처(MSA)의 로컬 개발 환경을 처음부터 구축하면서 겪은 트러블슈팅을 정리합니다.5개의 NestJS 서비스 + Apollo Federation Gateway + Elasticsearch를 로컬에서 완전히 기동하는 것이 목표였고, Docker Compose로 MySQL, PostgreSQL, Redis, Elasticsearch 컨테이너를 구동하는 구성입니다.내부 정보(DB 호스트, 계정, 인프라 구조 등)는 모두 제외하고,다른 개발자에게도 도움이 될 일반적인 트러블슈팅 패턴만 정리했습니다.1. DB 이름 불일치 — .env와 Docker Compose 설정 확인문제Unknown database 'my_ap..