GraphQL: 프로덕션에서 배운 교훈

2020년입니다. Your 팀 단일 페이지 애플리케이션을 구축하거나 적어도 일반 다중 페이지 애플리케이션 내에 리치 컴포넌트를 포함하는 쪽으로 점점 더 기울고 있습니다. [GraphQL](https://graphql.org/)은 이제 [2년이 넘었습니다](https://en.wikipedia.org/wiki/GraphQL). JavaScript 생태계 표준이 성숙했다고 볼 수 있습니다. 저희는 조금 모험을 하고 싶었기 때문에 일반적인 JSON API를 포기하고 바로 뛰어들었는데, 그 결과는 다음과 같습니다.

GraphQL 서버가 필요합니다.

대부분의 프레임워크에서 웹 개발에는 JSON API를 구축하는 도구가 이미 있습니다. 경로 구조를 구축하고 일부 GET 및 POST를 쉽게 수락한 다음 JSON 응답을 출력할 수 있습니다. Ruby on Rails에는 특별한 프로젝트 설정 스위치는 일반적인 HTML 렌더링 기능을 없애고 그 자리에 API를 위한 탄탄한 기반을 마련합니다. 그 결과 최신 도구를 사용하는 숙련된 개발자는 말 그대로 몇 분 만에 백엔드를 구축할 수 있습니다.

GraphQL은 그렇지 않습니다. 다음과 같은 서버 라이브러리가 있지만 다양한 언어를 사용하더라도 생태계에 적합한 것이 무엇인지 파악해야 하기 때문에 시작부터 속도 저하가 발생합니다. 개인적인 의견으로는 프로젝트에 도입할 수 있는 라이브러리를 설명할 때 "서버"라는 용어를 사용하는 것도 마음에 들지 않습니다.

엔드포인트는 하나뿐입니다.

수년에 걸쳐 우리는 API 구조에 대한 특정 사고 방식에 익숙해졌습니다. 가장 기본적인 수준에서는 단순히 REST 관행을 따랐습니다. 즉, 앱에서 논리 모델당 여러 개의 엔드포인트를 만드는 것이었습니다. 이는 API 작성자와 소비자 모두에게 이해하기 쉬운 구조입니다. 또한 백엔드에서 범위가 잘 지정된 메서드를 생성하여 다음과 같은 추론이 가능합니다. 코드 API 자체에 관한 것만큼이나 쉽습니다. 이 구조는 다음과 같은 목적으로 네임스페이스를 쉽게 지정할 수도 있습니다. API 버전 관리.

GraphQL은 일반적으로 단일 엔드포인트만 사용합니다. /graphql. API에 대한 모든 요청은 해당 엔드포인트에 POST 요청으로 도착하며, 거기서부터 클라이언트가 원하는 것을 파악하고 적절하게 응답하는 것은 GraphQL 서버의 책임입니다.

언뜻 보기에는 다루기 어렵게 느껴질 수 있습니다. 단일 엔드포인트로 JSON API의 모든 작업을 수행한다고 상상해 보세요! 그러나 API가 성숙해지고 일부 기능이 다른 기능으로 대체됨에 따라 곧 의미가 없어지기 시작합니다. 클래식 API의 사용 중단은 일반적으로 네임스페이스 수준에서 이루어지며, 다음에서 이동합니다. v1 에 v2. GraphQL은 단일 필드 사용 중단까지 훨씬 더 많은 제어 기능을 제공합니다. REST API 소비자에게 더 이상 이름 필드를 사용하여 fancy_name 대신! 처음에는 불편하게 느껴졌던 기능이 사실은 최고의 기능 중 하나라는 것이 밝혀졌습니다.

모든 것이 입력됩니다.

JSON에는 입력할 수 있는 방식이 그리 많지 않습니다. 문자열, 숫자, 배열, 객체가 있을 뿐입니다. 그 외에는 운이 없는 것입니다. 이와 대조적으로 GraphQL에서는 모든 것이 유형으로 시작하고 유형으로 끝나며, 심지어 루트 쿼리와 변이도 바로 유형입니다. GraphQL DSL은 서버와 클라이언트 모두에서 유형 검사를 시행하여 모든 종류의 불쾌한 돌발 상황을 방지합니다.

이는 특히 TypeScript를 사용하든 Flow와 같은 대체품을 사용하든, 점점 더 많은 SPA가 자체적으로 유형 검사를 하고 있기 때문에 매우 중요합니다. GraphQL을 사용하면 기본값 외에 복잡하고 복합적인 유형을 쉽게 도입할 수 있으며, 백엔드와 프론트엔드 모두에서 개발자에게 빠르게 익숙해질 수 있습니다.

자세히 읽어보세요: JavaScript 테스트...루비로?!

문서가 기본 제공됩니다.

기존 JSON API에서는 문서가 뒷전으로 밀릴 수 있습니다. 그렇지 않더라도 선택할 수 있는 방법은 많습니다. 다음과 같은 체계를 사용하나요? OpenAPI? 그런 다음 Swagger와 같은 도구를 사용하여 사람이 읽을 수 있는 형태로 변환할까요? 아니면 그냥 마크다운 파일을 어딘가에 덤프할까요? 이 문제는 여러 번 해결되었지만 여전히 문서를 작성하고 업데이트하고 배포하기 위해 팀의 의식적인 생각과 노력이 필요합니다. API에 특정 사용자 역할만 액세스할 수 있는 섹션이 여러 개 있는 경우에는 훨씬 더 복잡한 문제가 됩니다.

대부분의 서버가 사용자의 유형과 요청을 문서화할 수 있도록 허용하기 때문에 GraphQL 문서화는 1급 시민입니다. 2018년 초부터 GraphQL 스키마 정의 언어가 공식 사양의 일부가 되었기 때문에 GraphQL API를 문서화하는 방법은 정확히 한 가지가 있습니다. 또한 GraphQL을 사용하면 그래프의 특정 부분에 대한 가시성을 정의할 수 있으므로 액세스해서는 안 되는 사용자는 액세스할 수 없는 부분에 대한 문서를 볼 수 없도록 자동으로 차단됩니다. 결정을 내리고 명확한 가이드라인을 마련한 것은 팀에게 큰 도움이 되었습니다.

작업에는 두 가지 유형만 있습니다.

HTTP의 GET, POST, PUT, PATCH 및 DELETE와 달리 GraphQL에는 두 가지 유형의 작업만 있습니다: 쿼리와 변경입니다. 가장 큰 차이점은 변경은 시스템의 상태를 변경할 수 있고 변경할 수 있으며 쿼리는 수동적으로 데이터를 읽어오기만 한다는 점입니다.

저는 이 부분에 대해 아직 고민 중이라는 것을 인정하겠습니다. 저는 리소스와 상호 작용하고 작업에 정확히 맞는 도구를 사용할 수 있는 HTTP의 수많은 동사를 좋아합니다. GraphQL을 사용하면 HTTP 동사 중 하나가 정확히 맞지 않는 까다로운 경우를 쉽게 처리할 수 있지만, 특정 변이가 실제로 어떤 영향을 미칠지 생각해야 하는 불이익이 발생합니다. 또한 내장된 표준 명명 규칙이 없기 때문에 내부 스타일 가이드를 작성해야 하거나 일관성이 없는 엉망진창을 만들 위험이 있다는 점도 지적할 수 있습니다.

클라이언트가 거의 필요합니다.

바닐라 JavaScript에서는 HTTP를 통해 REST API와 상호 작용하는 것이 매우 쉬우며, 최신의 fetch API를 사용하세요. 이와는 대조적으로 GraphQL의 경우 정말 괜찮은 성능을 원한다면 클라이언트 라이브러리를 사용해야 합니다. 바닐라 JavaScript만 사용하여 GraphQL API와 상호 작용하는 것은 불가능하지 않습니다. 결국 POST 요청일 뿐이기 때문입니다. 그러나 일반적인 API 호출에 대한 요청 캐싱과 같은 오래된 웹 기술만 사용하는 것은 일반적으로 POST 요청이 캐시되지 않기 때문에 작동하지 않습니다.

모든 합리적인 GraphQL 클라이언트는 클라이언트 측 결과 캐싱 메커니즘과 더 많은 기능을 구현합니다. 이 모든 선택 사항 덕분에 엔트리 레벨에서 GraphQL 클라이언트의 구성을 직접 롤링하는 것은 완전히 당황스러운 작업입니다. GraphQL을 처음 시작할 때는 특히 다음 사항을 살펴볼 것을 권장합니다. 아폴로-부스트 매우 합리적인 기본값이 제공되기 때문입니다.

클라이언트가 데이터를 선택

API에서 데이터 목록을 가져왔는데 관련 모델에 대한 중요한 필드가 누락된 경험은 누구나 있을 것입니다. 그런 다음 N+1개의 요청을 포함하는 해킹을 구현하고, 이를 빠르게 추가하는 백엔드 개발자에게 투덜대기도 합니다. 하지만 잘 구현된 GraphQL API를 사용하면 원하는 만큼 데이터를 깊이 파고들 수 있기 때문에 일반적으로는 이런 일이 발생하지 않습니다. 이 배치에서 주문에 포함된 고객의 주소를 확인해야 하나요? 적어도 이론상으로는 문제가 없습니다.

예측하기 어려운 복잡성

백엔드 쪽에서 GraphQL을 설계할 때는 클라이언트가 그래프를 얼마나 깊이 파고들 수 있을지 생각하기 어려울 수 있습니다. 그래프의 사용량을 계측하고 관찰하는 방법에는 여러 가지가 있으며, 프론트엔드 동료들이 잠시 동안 놀게 한 후에는 데이터 저장소에서 다소 상상력이 풍부한 읽기를 수행하는 긴 쿼리를 보기 시작할 수 있습니다. REST API에서는 한 번의 요청으로 액세스할 데이터의 범위를 쉽게 알 수 있으므로 이를 제어하기가 더 쉽습니다. 종종 이러한 복잡성을 놓치면 프로덕션 환경에 배포한 후에 큰 어려움을 겪을 수 있습니다. 또한 스스로 파놓은 이 구멍에서 어떻게 빠져나올 수 있는지도 명확하지 않은 경우가 많습니다.

번호가 매겨진 페이지가 정말 어렵습니다.

이것은 정말 혀를 내두를 만한 불만입니다. GraphQL의 의도된 페이지 매김 메커니즘의 작동 방식을 보면 GraphQL이 Facebook을 위해 설계되었다는 것을 확실히 느낄 수 있습니다. 소위 연결이라고 하는 것은 기본적으로 그래프 가장자리의 끝없는 흐름이며, 탐색은 보다 고전적인 페이지 대신 커서를 통해 이루어집니다. 페이스북 스타일의 끝없는 게시물 피드에 어떻게 적용되는지 쉽게 알 수 있지만, 예를 들어 42페이지로 이동할 수 있는 깔끔하게 페이지가 지정된 목록을 원한다면 훨씬 더 어려움을 겪게 될 것입니다. 물론 이 문제를 해결할 수 있는 방법이 있지만, 이는 해결 방법일 뿐입니다.

다시 할 수 있을까요?

위에 나열된 모든 불만 사항과 차이점을 고려하면 GraphQL을 실험이 실패로 돌아가 곧바로 REST API로 돌아간 것으로 생각하실 수도 있습니다. 그렇지 않습니다. 오히려 조직 전체의 프로젝트에서 GraphQL을 더 광범위하게 사용하기 위해 노력하고 있습니다. GraphQL은 우리의 업무를 더 쉽고 더 좋게 만들어준 훌륭한 기술입니다. 하지만 처음에는 어떤 성장통을 겪게 될지 완전히 깨닫지 못한 채 GraphQL에 투자했습니다.

GraphQL이 자신에게 적합하다고 생각하신다면 과감히 도전해 보시기 바랍니다. 안전하게 실패할 수 있는 충분한 시간과 여유를 가지면 머지않아 그 혜택을 누리게 될 것입니다!

또한 읽어보세요:

– 원격 개발자를 효과적으로 관리하는 방법은 무엇인가요? CTO를 위한 가이드

– Python 대 루비? 제품 개발에 어떤 기술을 사용해야 할까요?

– 나만의 마켓플레이스를 구축하고 개발하기 위한 빠른 가이드입니다. 알아야 할 사항은 무엇인가요?