드디어 시리즈의 마지막 편입니다. 1편부터 7편까지 GraphQL 명세의 본문 여섯 개 장을 차례로 읽어왔는데요. 그동안 곳곳에서 "이건 September 2025에서 새로 들어왔다", "자세한 건 마지막 편에서"라며 미뤄둔 이야기들이 있었습니다. 이번 편에서 그 약속들을 한자리에 모아 갚으려고 합니다. 1편에서 짚었듯 September 2025 에디션은 2021년 10월 이후 4년 만의 정식 개정판입니다. 그동안 쌓인 변경 제안이 한꺼번에 반영됐는데요. 흥미로운 건 핵심 신규 기능들을 나란히 놓고 보면, 하나의 방향을 가리키고 있
지난 편에서 쿼리가 실행되어 데이터가 채워지는 과정까지 따라왔는데요. 이제 그 결과를 클라이언트에게 어떤 모양으로 돌려줄지를 정하는 마지막 단계, 명세 제7장 응답(Response) 차례입니다. 우리가 GraphQL을 쓸 때마다 마주하는 그 { "data": ... } JSON이 왜 항상 그렇게 생겼는지, 에러는 왜 별도의 배열로 따로 담기는지가 이번 편에서 분명해집니다. 응답은 명세에서 가장 짧은 장에 속하지만, 클라이언트 코드를 작성할 때 매일 부딪히는 부분이라 정확히 알아두면 두고두고 도움이 됩니다. 응답의 최상위에는 세 개의
지난 편에서 검증을 통과한 쿼리는 이제 실제로 데이터를 채워 넣을 준비가 됐습니다. 그 일을 다루는 것이 명세 제6장 실행(Execution) 인데요. GraphQL 명세에서 가장 흥미로운 동작들이 바로 이 장에 숨어 있습니다. 특히 "왜 필드 하나가 실패했는데 부모 객체까지 통째로 null이 되지?" 같은, 실무에서 한 번쯤 당황했을 동작의 정체가 여기서 밝혀집니다. 이번 편에서는 서버가 쿼리를 어떻게 한 필드씩 실행하는지, query와 mutation의 실행 순서가 왜 다른지, 그리고 에러가 났을 때 null이 어떻게 번지는지를
GraphiQL에서 존재하지 않는 필드를 입력하면, 실행하기도 전에 빨간 밑줄이 그어지면서 "그런 필드는 없다"고 알려주는 걸 보셨을 텐데요. 서버에 요청을 보내지도 않았는데 어떻게 틀렸다는 걸 알았을까요? 바로 GraphQL이 쿼리를 실행하기 전에 한 단계를 더 거치기 때문입니다. 그 단계가 이번 편의 주제인 검증(Validation) 입니다. 지난 편에서 본 인트로스펙션으로 스키마 정보를 손에 쥐면, 어떤 쿼리가 그 스키마에 맞는지 안 맞는지를 실행 없이도 판단할 수 있습니다. 명세 제5장은 바로 이 "맞는 쿼리"의 조건을 규칙
GraphiQL이나 Apollo Studio 같은 도구를 써보셨다면, 필드 이름을 한 글자만 입력해도 가능한 필드 목록이 주르륵 뜨는 경험을 하셨을 텐데요. 신기하게도 도구는 우리가 쓰는 서버의 스키마를 미리 다 알고 있는 것처럼 동작합니다. 누가 그 정보를 알려준 걸까요? 답은 GraphQL 서버 자신입니다. GraphQL 스키마는 자기 자신에 대한 정보를 GraphQL 쿼리로 되물을 수 있도록 설계되어 있는데요. 이 능력을 인트로스펙션(Introspection) 이라고 부르고, 명세 제4장이 이걸 다룹니다. 지난 편에서 본 타입
지난 편에서 우리가 작성하는 쿼리 문서의 문법을 살펴봤는데요. 그런데 쿼리는 혼자서는 아무 의미가 없습니다. user(id: "1") { name }이라는 요청이 말이 되려면, 서버 쪽에 "User라는 타입이 있고, 거기에 name이라는 필드가 있다"는 약속이 미리 정의되어 있어야 하니까요. 그 약속이 바로 스키마(schema) 이고, 스키마를 이루는 재료가 이번 편의 주제인 타입 시스템(Type System) 입니다. 명세 제3장은 GraphQL에서 가장 분량이 많고 중요한 장입니다. 서버가 어떤 타입들을 조합해 스키마를 짤 수
지난 편에서 GraphQL 명세가 어떤 문서이고 왜 읽어야 하는지 함께 살펴봤는데요. 이번 편부터는 본격적으로 명세 본문으로 들어갑니다. 첫 번째 본문 장은 제2장 Language, 그러니까 우리가 클라이언트에서 작성해 서버로 보내는 그 쿼리 텍스트의 문법을 다루는 장입니다. 평소에 별생각 없이 { user { name } } 같은 쿼리를 작성하셨겠지만, 이 짧은 텍스트 안에도 명세가 엄밀하게 정의한 문법 규칙이 빼곡히 들어 있는데요. 이번 편에서는 GraphQL 문서가 어떤 부품들로 조립되는지, 연산부터 디렉티브까지 하나씩 분해해
GraphQL로 API를 몇 번 만들어보셨다면 쿼리를 작성하고, 스키마를 정의하고, 리졸버를 붙이는 일에는 꽤 익숙하실 텐데요. 그런데 혹시 흔히 "스펙"이라고도 부르는 GraphQL 공식 명세(specification) 를 직접 펼쳐본 적 있으신가요? 아마 대부분은 "그런 게 있다는 건 아는데, 실무에서 Apollo만 잘 쓰면 되지 않나?"라고 생각하셨을 것 같습니다. 😅 저도 오랫동안 그랬습니다. 그런데 막상 명세를 읽어보니, 평소에 "왜 이렇게 동작하지?" 하고 넘어갔던 수많은 질문에 대한 답이 거기 다 적혀 있더라고요. 마
현대 소프트웨어 개발에서 HTTP 기반 API를 생각하면 우리는 크게 두 가지 기술을 떠올리게 되죠? REST와 GraphQL. 역사가 오래된 REST는 비교적 간단한 백엔드 시스템이나 개발된 지 시간이 좀 지난 레거시 시스템에서 많이 사용되고 있습니다. 반면에 GraphQL은 관계가 복잡한 데이터를 다루는 API를 개발하거나 BFF(Backend for Frontend) 또는 API Orchestration(오케스트레이션)을 위해 많이 채택되고 있습니다. 만약 이 두 대표적인 API 기술을 유기적으로 통합할 수 있다면 얼마나 좋을
GraphQL을 사용하다 보면 스키마를 관리하는 일이 점점 중요해지는데요. 팀원이 늘어나고 서비스가 커지면서 "이 필드 바꿔도 기존 클라이언트에 문제 없을까?", "지금 운영 중인 스키마가 정확히 뭐였지?" 같은 고민이 생기기 마련이잖아요? 😅 이럴 때 큰 도움이 되는 도구가 바로 Apollo에서 만든 Rover CLI입니다. 이번 글에서는 Rover CLI의 설치부터 주요 명령어, CI/CD 파이프라인 연동까지 쭉 다뤄보겠습니다. Rover CLI란? Rover는 Apollo GraphQL에서 제공하는 공식 CLI 도구입니다.
풀스택 웹 애플리케이션을 처음부터 끝까지 만들려면 생각보다 결정해야 할 것이 많죠. 프론트엔드 프레임워크는 뭘 쓸지, API는 REST로 할지 GraphQL로 할지, 데이터베이스는 어떻게 연결할지, 인증은 어떤 방식으로 구현할지... 이런 고민을 하다 보면 정작 비즈니스 로직을 작성하기도 전에 지쳐버리는 경우가 많은데요. RedwoodJS는 이런 문제를 해결하려고 만들어진 풀스택 자바스크립트 프레임워크입니다. GitHub의 공동 창업자인 Tom Preston-Werner가 만들었는데, Jekyll이나 Semantic Versioni
![[GraphQL] React Apollo로 Subscription 호출](/_astro/java-script.E7jj1V9w_1BAgJN.webp)
Subscription GraphQL에는 query와 mutation 그리고 subscription 이렇게 총 3가지 operation type이 있습니다. 이 중에 query는 데이터 조회를 위해서 필수적으로 사용되고, mutation은 데이터 변경을 위해서 많이 사용되고 있습니다. query와 mutation 대비 다소 생소한 subscription은 주로 실시간(real-time) 애플리케이션을 구현하기 위해서 사용되는데요. subscription도 기본적으로 query처럼 데이터를 조회를 위해서 사용되지만 작동 방식에서 큰
Subscription GraphQL에는 query와 mutation 그리고 subscription 이렇게 총 3가지 operation type이 있습니다. 이 중에 query는 데이터 조회를 위해서 필수적으로 사용되고, mutation은 데이터 변경을 위해서 많이 사용되고 있습니다. query와 mutation 대비 다소 생소한 subscription은 주로 실시간(real-time) 애플리케이션을 구현하기 위해서 사용되는데요. subscription도 기본적으로 query처럼 데이터를 조회를 위해서 사용되지만 작동 방식에서 큰
서버 애플리케이션을 개발할 때 사용자 사용자 인증(authentication)과 인가(Authorization)는 데이터 보안을 위해서 매우 핵심적인 기능입니다. 따라서 GraphQL API를 설계하거나, GraphQL 서버를 개발할 때도 사용자 인증/인가 부분에 대해서 여러 가지 고려가 필요합니다. 이번 포스팅에서는 Apllo Server를 이용하여 GraphQL 서버의 사용자 인증과 인가를 구현해보도록 하겠습니다. HTTP 인증 방식 HTTP 인증 방법에는 여러 가지가 있는데, GraphQL 스팩에서는 어떤 특별한 인증 방법을
GraphQL 서버에서 클라이언트로 부터 요청받은 쿼리(Query)나 뮤테이션(Mutation)을 실행하다가 오류가 발생할 수 있습니다. 이런 경우, GraphQL 서버에서 해당 오류에 대한 정보를 응답해줘야 클라이언트에서도 그에 상응하는 화면 처리를 할 수가 있을 것입니다. 이번 포스팅에서는 Apollo Server로 개발된 GraphQL 서버에서 어떻게 오류 처리를 해야하는지 알아보도록 하겠습니다. 오류 발생 시 응답 결과 GraphQL 서버에서 오류가 발생할 경우, Apollo Server는 HTTP 응답 바디의 errors
지난 포스팅에서는 Apollo Hooks라는 새로운 방법을 통해 React 앱에서 어떻게 GraphQL API를 호출할 수 있는지 간단히 살펴보았습니다. 이번 포스팅에서는 지난 포스팅에서 다뤘던 useQuery() 함수 뿐만 아니라 useMuation() 함수까지 사용해서 간단한 노트(Note) 앱을 React로 작성해보도록 하겠습니다. Apollo Hooks가 생소하신 분들은 아래 포스팅를 통해 먼저 기본 개념을 잡으시고 이 포스팅로 돌아오시기를 추천드립니다. [GraphQL/React] Apollo Hooks 소개/사용법 기존에
지난 달, Apollo Client에서 공개되어 현재 뜨거운 반응을 얻고 있는 Apollo Hooks에 대해서 알아보겠습니다. Apollo Client가 생소하신 분들은 아래 포스팅를 먼저 보시고 이 포스팅로 돌아오시는 것을 추천드립니다. [GraphQL] Apollo Client 사용법 Apollo Hooks? Apollo Hooks는 Apollo Client로 React 앱을 개발할 때, GraphQL API를 호출할 수 있는 새로운 방법입니다. 기존에는 react-apollo 패키지에서 제공하는 <Query/>나 <Mutati
지난 포스팅에서 SchemaLink를 이용하여 서버 없이 클라이언트에서 GraphQL API를 호출하는 방법에 대해서 알아보았습니다. 이번 포스팅에서는 로컬에서 직접 스키마를 작성하지 않고 원격 서버로 부터 스키마를 가져오는 몇 가지 방법에 대해서 알아보겠습니다. 패키지 설치 예제 프로젝트에서 필요한 GraphQL과 Apollo Client 관련 패키지를 설치하고 시작하겠습니다. 여기서 graphql-tools 패키지가 가장 중요한데, 스키마 생성을 위해 makeExecutableSchema(), introspectSchema(),
GraphQL 서버 없이도 클라이언트에서 GraphQL API를 호출할 수 있도록 도와주는 Aollo Client의 SchemaLink에 대해서 알아보겠습니다. 일반적인 Apollo Client 생성 일반적으로 Apollo Client를 사용할 때는 다음과 같이 GraphQL 서버로 HTTP 요청을 보내기 위해서 HttpLink를 사용합니다. 이렇게 HttpLink를 사용할 때는 반드시 연동할 GraphQL API의 endpoint를 가진 GraphQL Server가 어딘가에 떠 있어야 합니다. Apollo Client를 이용해서
GraphQL API를 호출할 때 사용하는 클라이언트 라이브러리인 Apollo Client에 대해서 알아보겠습니다. 기본적으로 HTTP 기반으로 동작하는 GraphQL API를 호출할 때 반드시 Apollo Client와 같은 전용 클라이언트 라이브러리가 필요한 것은 아닙니다. GraphQL API를 별다른 라이브러리 없이 최대한 간단하게 호출하는 방법에 대해서 관련 포스팅를 참고바라겠습니다. 패키지 설치 프로젝트에 Apollo Client를 사용할 때 필요한 5개의 패키지를 설치합니다. pacakge.json 이 중, apollo