Eve Porcello와 함께하는 스매싱 팟캐스트 에피소드 31: GraphQL이란?

이 에피소드에서는 GraphQL에 대해 이야기합니다. 그것은 무엇이며 몇 가지 일반적인 API 문제를 어떻게 해결합니까? 나는 그것을 알아보기 위해 전문가인 Eve Porcello와 이야기를 나눴다.

메모 표시

• 트위터의 이브
• 이브즈 컴퍼니 문 하이웨이
• O'Reilly에서 GraphQL 배우기
• GraphQL Wilderness를 통해 길을 발견하십시오 - 2021년 초에 시작되는 Eve의 GraphQL 워크샵

주간 업데이트

• Next.js 웹 사이트에서 온전한 상태로 저장된 MDX를 사용하는 방법
  저자 제이슨 렝스토프
• Google의 Dialogflow를 사용하여 대화형 NLP 지원 챗봇 구축
  Nwani Victor가 작성했습니다.
• UX 연구의 윤리적 고려 사항: 교육 및 검토의 필요성
  빅터 요코가 쓴
• 웹사이트를 대화하기 쉽게 만들기
  저자 프레더릭 오브라이언
• 복잡한 솔루션이 있을 때 간단한 UI를 디자인하는 방법
  저자 수잔 스카카

성적 증명서

Drew McLellan: 그녀는 소프트웨어 엔지니어, 강사, 저자이자 교육 및 커리큘럼 개발 회사인 Moon Highway의 공동 설립자입니다. 그녀의 경력은 기술 사양을 작성하고 웹 프로젝트를 위한 UX 디자인을 만들기 시작했습니다. 2012년 Moon Highway를 시작한 이후 그녀는 egghead.io 및 LinkedIn Learning을 위한 비디오 콘텐츠를 제작했으며 O'Reilly's Media를 위한 Learning React 및 Learning GraphQL 책을 공동 저술했습니다.

Drew: 그녀는 또한 자주 회의 연사로 활동하며 React Rally, GraphQL Summit 및 OSCON을 포함한 회의에서 발표했습니다. 그녀가 GraphQL의 전문가라는 것을 알고 있지만 그녀가 한때 북극곰에게 체스를 가르쳤다는 것을 알고 계셨습니까? 내 스매싱 친구, 이브 포첼로를 환영하십시오.

드류: 안녕 이브, 어때?

이브 포첼로: 굉장 하네요.

Drew: 제가 거기에서 언급했듯이 당신은 JavaScript와 React와 같은 분야의 교육자입니다. 하지만 저는 오늘 당신의 다른 전문 분야 중 하나인 GraphQL에 대해 이야기하고 싶었습니다. 우리 중 많은 사람들이 GraphQL에 대해 어느 정도는 들어보았지만 이것이 무엇인지, 무엇을 하는지, 특히 웹 스택에서 어떤 종류의 문제를 해결하는지 완전히 확신하지 못할 수도 있습니다.

Drew: 그렇다면 우리를 위한 무대를 마련해 주십시오. 만약 제가 프론트 엔드 개발자라면 GraphQL은 생태계에 어떤 역할을 하며 어떤 기능을 수행합니까?

이브: 네. GraphQL은 프론트 엔드와 백엔드 사이에 적합합니다. 그것은 둘 사이의 중간에 있는 종류이며 프론트 엔드 개발자와 백엔드 개발자에게 많은 이점을 제공합니다.

Eve: 프론트 엔드 개발자라면 모든 프론트 엔드 데이터 요구 사항을 정의할 수 있습니다. 따라서 예를 들어 React 구성 요소의 큰 목록이 있는 경우 쿼리를 작성할 수 있습니다. 그러면 해당 페이지의 데이터를 채우는 데 필요한 모든 필드가 정의됩니다.

Eve: 이제 백엔드 부분은 정말 소유가 되었습니다. 다양한 소스에서 많은 데이터를 수집할 수 있기 때문입니다. 그래서 우리는 REST API, 데이터베이스, 그리고 이 모든 다른 장소에 데이터를 가지고 있습니다. 그리고 GraphQL은 모든 데이터가 있는 곳의 혼란을 실제로 이해하기 위해 이 멋진 작은 오케스트레이션 계층을 제공합니다. 따라서 스택 전체에 있는 모든 사람에게 정말 유용합니다.

Drew: 기본적으로 API 기반 기술이겠죠? 프론트 엔드와 백엔드 사이에 위치하며 일종의 API를 제공합니다. 맞나요?

이브: 네, 맞습니다. 정확히.

Drew: 지난 10년 동안 API의 황금 표준은 휴식이었습니다. 따라서 클라이언트 측 앱이 있고 백엔드의 데이터로 채워야 하는 경우 REST API 엔드포인트를 빌드하고 이를 쿼리합니다. 그렇다면 그 모델은 어디에 속합니까? 그리고 언제 GraphQL이 와서 그것을 해결해야 할까요?

Eve: 글쎄요, GraphQL이 우리에게 정말로 도움이 되는 문제는 일종의 황금 문제인 것 같습니다. GraphQL이 제공하는 황금 솔루션은 REST를 사용하여 너무 많은 데이터를 가져오는 것입니다. 따라서 슬래시 사용자 또는 슬래시 제품이 있는 경우 경로에 도달할 때마다 모든 데이터가 반환됩니다.

Eve: GraphQL을 사용하면 원하는 데이터에 대해 조금 더 신중해질 수 있습니다. 따라서 개체에서 100개 필드가 4개만 필요한 경우 해당 필드를 정확히 찾아낼 수 있고 데이터를 장치에 로드하거나 제가 말해야 하는 모든 데이터를 장치에 로드할 필요가 없습니다. 특히 휴대전화의 경우 많은 추가 작업이 필요합니다.

Drew: 저는 과거에 원하는 데이터 목록을 전달하거나 추가 항목으로 되돌아오는 것을 보강할 수 있는 선택적 필드가 있는 REST API를 보고 작업한 적이 있습니다. 그리고 이것이 이 문제를 식별하는 것 같아요, 그렇죠? 즉, 매번 동일한 데이터를 항상 원하는 것은 아닙니다. 그렇다면 GraphQL은 데이터 측면에서 백엔드가 반환할 내용을 프런트 엔드가 지정할 수 있도록 하는 접근 방식을 공식화한 것입니까?

이브: 맞아요. 따라서 귀하의 쿼리는 귀하가 요청하는 방법, 필터링하는 방법, 어디서나 모든 종류의 정보를 파악하는 방법이 됩니다.

Eve: GraphQL을 정말 성공적으로 사용하기 위해 모든 REST API를 분해할 필요가 없다는 점도 중요하다고 생각합니다. 내가 본 가장 성공적인 GraphQL 구현은 REST API를 둘러싼 래퍼입니다. 그리고 GraphQL 쿼리는 실제로 어떤 데이터가 필요한지 생각할 수 있는 방법을 제공합니다. 그리고 귀하의 데이터 중 일부는 당사 사용자 및 제품, 예를 들어, 일부 데이터는 REST에서, 일부는 데이터베이스에서 제공될 수 있습니다.

Drew: 익숙한 시나리오는 웹사이트에 헤더를 표시하기 위해 사용자에 대한 정보를 반환하는 엔드포인트가 있을 수 있다는 것입니다. 사용자 이름과 아바타를 제공할 수 있습니다. 그리고 모든 페이지에서 이를 선별하고 데이터를 채우지만 앱의 다른 곳에서 전체 이름을 표시해야 하는 곳을 찾습니다.

Drew: 그래서 당신은 그것을 끝점에 추가하고 그것을 반환하기 시작합니다. 그런 다음 계정 관리 섹션을 수행하고 우편 주소가 필요합니다. 따라서 해당 끝점에서도 반환됩니다.

Drew: 그리고 당신이 그것을 알기도 전에, 그 끝점은 백엔드에서 합치는데 꽤 많은 비용이 들며 분명히 다운로드해야 할 많은 비용이 드는 전체 무거운 페이로드를 반환하고 있습니다.

Drew: 그리고 그것은 아바타를 보여주기 위해 모든 단일 페이지에서 선별되었습니다. 그래서 저는 그것이 시간이 지남에 따라 커지는 일종의 문제라고 생각합니다. 특히 큰 팀에서 너무 쉽게 빠지기 ​​쉬운 GraphQL은 그 문제의 맨 위에 있습니다. 그것은 그것을 해결하는 방법을 알고 있으며 그 해결을 중심으로 설계되었습니다.

이브: 맞아요. 그리고 네, GraphQL 스키마에 대한 전체 아이디어는 사실 GraphQL의 쿼리 언어 부분보다 이야기가 덜하다고 생각합니다. 하지만 특히 Schema가 API에 대해 이 멋진 유형 시스템을 제공한다고 생각합니다.

Eve: 따라서 팀의 모든 사람, 관리자, 프론트 엔드 개발자, 백엔드 개발자, 데이터를 실제로 다루는 모든 사람이 함께 모여 우리가 실제로 이 API에 제공하려는 데이터를 중심으로 통합할 수 있습니다. 그러면 모두가 그 소스가 무엇인지 알 수 있습니다. 사실, 그들은 그것을 기반으로 앱의 자신의 부분을 구축할 수 있습니다.

Eve: 그래서 거기에는 까다로운 스키마 관리 문제도 있습니다. 그러나 마이크로서비스에서 모놀리식으로 다시 이동하는 한 우리는 그렇게 하고 있지만 여전히 마이크로서비스에서 우리가 좋아하는 모든 이점을 얻고 있습니다.

Drew: 그리고 GraphQL 시스템을 설정하는 일반적인 방법은 기본적으로 하나의 경로가 있다는 것을 정확히 이해하고 있습니까? 가장 어려운 점은 이름을 지정하고 이 특정 쿼리가 있어야 하는 경로를 찾는 것입니다. 그것은 사용자와 제품을 반환하고 있습니다. 사용자에게 무언가를 베어야합니까, 아니면 제품에 무언가를 베어야합니까?

Drew: GraphQL을 사용하면 쿼리를 실행하고 적절한 응답을 받을 수 있는 엔드포인트가 하나뿐입니다.

이브: 맞아요. 응. 단일 엔드포인트입니다. 스키마의 모든 항목에 이름을 지정하고 있기 때문에 여전히 이름 지정 문제를 겪고 있는 것 같습니다. 하지만 마이크로서비스에 큰 투자를 한 많은 회사가 있다고 생각합니다. 모든 사람이 우리에게 어떤 엔드포인트를 갖고 있습니까? 그들은 어디에 있습니까? 어떻게 문서화됩니까? 그리고 GraphQL을 사용하면 API 작동 방식에 대해 알고 싶은 모든 것을 검색할 수 있는 한 곳, 한 종류의 사전이 있습니다.

Drew: 그래서 저는 다른 쿼리 언어에 매우 익숙합니다. SQL은 많은 웹 개발자가 알고 있는 쿼리 언어의 명백한 예입니다. 그리고 그 쿼리는 거의 명령과 같은 형태를 취합니다. 문자열이야, 그렇지, 어디에서, 무엇이든 이것을 선택하라. 쿼리는 GraphQL에서 어떤 형식을 취합니까?

Eve: 그것은 여전히 ​​기술 문자열이지만 그 논리가 어디에서 왔는지 정의하지 않습니다. 그리고 많은 논리가 서버로 다시 이동됩니다. 따라서 GraphQL 서버인 GraphQL API는 "이 데이터가 있는 곳에서 이 데이터를 가져와 이 매개변수를 기반으로 필터링합니다."라고 말하는 역할을 합니다.

Eve: 하지만 쿼리 언어에서는 매우 필드 지향적입니다. 따라서 검색하려는 모든 항목에 대한 필드를 추가하기만 하면 됩니다. 물론 이러한 쿼리에도 필터를 적용할 수 있습니다. 하지만 그 정보가 어디에서 왔는지에 대해서는 좀 덜 직접적인 것 같아요. 많은 기능이 서버에 내장되어 있습니다.

Drew: 따라서 쿼리에서 조합할 수 있습니다. 하나의 요청에서 다양한 유형의 데이터를 다시 가져오는 요청을 만들 수 있습니다. 맞나요?

이브: 네, 정말 맞습니다. 따라서 서버가 허용하는 만큼 많은 필드에 대한 쿼리를 보내고 모든 종류의 중첩 데이터를 가져올 수 있습니다. 하지만 이것이 실제로 작동하는 방식입니다. 우리는 필드에서 다양한 유형을 연결합니다. 그래서 내 사용자와 제품 아이디어를 재활용할 것이라고 생각하지만 사용자는 제품 목록을 반환하는 제품 필드를 가질 수 있습니다. 이들 모두는 다른 유형과도 연관되어 있습니다. 따라서 쿼리가 진행되기를 원하는 만큼 깊이 중첩될 수 있습니다.

Drew: 웹 애플리케이션에서 일반적인 보기에 대한 데이터를 검색하여 모든 종류의 일이 있을 수 있다는 의미인가요? 즉, 백엔드에 한 번만 요청하면 다른 작업을 수행할 필요 없이 한 번에 모든 것을 얻을 수 있습니다. 모두 하나이기 때문에 다른 끝점에 대한 쿼리?

이브: 네. 이것이 바로 전체 목표이며 단일 쿼리에 불과하고 원하는 모든 필드를 정의한 다음 하나의 응답으로 반환하는 것입니다.

Drew: 쿼리는 JSON 기반입니다. 맞나요?

Eve: 쿼리 자체는 텍스트 문자열이지만 일반적으로 JSON 데이터를 반환합니다. 따라서 필드가 있는 경우 내 JSON 응답이 정확히 일치하고 데이터 응답이 정확히 동일해 보이기 때문에 해당 쿼리를 보낼 때 무엇을 얻는지 명확합니다.

Drew: 많은 쿼리가 고객이나 제품과 같은 거의 맨 물체에 대한 것 같습니다. 백엔드에서 비즈니스 로직이 제어되는 더 복잡한 쿼리를 지정하는 방법이 있습니까? 사용자에 대한 팀 목록을 얻고 싶지만 해당 사용자가 팀의 관리자이고 팀 계획이 만료되지 않은 경우와 일상적인 웹 응용 프로그램 개발에서 직면하는 모든 종류의 실제 제약 조건만 가져오고 싶다고 가정해 보겠습니다. GraphQL로 이를 달성할 수 있습니까?

이브: 물론이죠. GraphQL의 정말 흥미롭고 강력한 점은 많은 로직을 서버로 옮길 수 있다는 것입니다. 복잡한 쿼리, 얻고자 하는 특정 유형의 사용자가 있는 경우 스키마에서 "복잡한 사용자 가져오기"라고 말하면 서버에 다음 위치에 함수가 있을 것입니다. 원하는 언어로 모든 논리를 작성할 수 있습니다. JavaScript는 가장 널리 사용되는 GraphQL 구현 언어이지만 전혀 사용할 필요가 없습니다. 따라서 Python, Go, C++, 무엇을 사용하든 이를 사용하여 GraphQL 서버를 구축할 수 있습니다. 하지만 네, 원하는 만큼 복잡한 쿼리를 정의할 수 있습니다.

Drew: 그러면 많은 비즈니스 로직을 새로운 유형의 객체로 캡슐화할 수 있을 것 같습니다. 공정한가요? 복잡한 사용자를 설정하고 나면 복잡한 사용자가 무엇인지 생각할 필요가 없지만 그 복잡한 사용자를 계속 사용하고 비즈니스 로직이 구현된다는 것을 알면 됩니다. 맞나요?

이브: 맞아요. 그래서 프론트 엔드 사람들이 이를 기반으로 프로토타입을 시작할 수 있기 때문에 이것이 프론트 엔드 사람들에게 정말 좋다고 생각합니다. 그런 다음 백엔드 팀은 해당 기능을 구현하여 작업을 수행할 수 있습니다. 그런 다음 해당 유형이 실제로 무엇이고 그들이 누구인지에 대한 일종의 공유된 이해가 있습니다. "해당 유형의 필드는 무엇입니까?" 그리고 모든 것은 스택 GraphQL이 작동하는 모든 곳에서 처리할 수 있습니다. 이것이 바로 프론트엔드나 백엔드 기술이 아닌 이유입니다. 그것은 정말로 둘 다의 종류이고 어느 쪽도 아닙니다.

Drew: 일종의 API와 프론트 엔드와 백엔드 간의 관계를 공식화하는 것처럼 들리므로 모두가 표준화된 예측 가능한 인터페이스를 얻게 됩니다.

이브: 맞아요.

Drew: 프론트 엔드와 백엔드가 다른 팀에서 소유하고 있는 조직에서는 전혀 드문 일이 아닙니다. 이 접근 방식을 사용하면 프런트 엔드에서 변경해야 할 사항이 달라질 수 있다고 생각합니다. 백엔드에서 작업하는 사람이 그에 상응하는 변경 작업을 수행할 필요 없이 데이터를 사용할 수 있습니다. 새 데이터가 필요한 경우 변경 작업을 수행할 필요 없이 거의 무한히 사용자 정의 가능한 이 API를 사용할 수 있습니다.

이브: 네, 맞습니다.

Drew: 그러면 GraphQL 서버가 응답 형식을 지정해야 합니까, 아니면 서버 측 논리에서 그렇게 해야 합니까?

Eve: GraphQL 서버는 두 가지를 정의합니다. 서버에 있는 스키마 자체를 정의한 다음 확인자 기능을 정의합니다. 어디에서나 데이터를 가져오는 기능입니다. 따라서 내가 GraphQL로 래핑하는 REST API가 있는 경우 리졸버는 해당 API에서 가져와 데이터를 필요한 대로 변환한 다음 해당 함수의 클라이언트에 반환합니다. 해당 서버에서도 원하는 모든 종류의 데이터베이스 기능을 사용할 수 있습니다. 따라서 여러 다른 위치에 데이터가 있는 경우 이 모든 데이터를 넣고 모든 논리를 디자인할 수 있는 정말 좋은 응집력 있는 지점입니다. 우리는 그것을 어떻게 변화시키고 싶습니까?”

Drew: 클라이언트가 "복잡한 사용자를 원합니다"라고 말하면 서버는 쿼리에서 이를 수신하고 "맞습니다. 복잡한 사용자 해석기를 검색하겠습니다."라고 말할 수 있습니다. 맞나요?

이브: 음-흠 (긍정적).

Drew: 이것이 기능입니다. 그런 다음 백엔드 팀이나 그 기능 내부에 로직을 작성하는 사람이 복잡한 사용자를 반환하는 데 필요한 모든 작업을 수행하도록 로직을 작성합니다.

이브: 맞아요.

Drew: 다른 API를 호출할 수도 있고, 데이터베이스를 쿼리할 수도 있고, 캐시에서 물건을 찾을 수도 있고, 거의 모든 것이 될 수도 있습니다.

이브: 거의 아무거나요. 그런 다음 함수에서 반환되는 값이 스키마의 요구 사항과 일치하고 반환되는 필드, 유형이 일치하는 한 모든 것이 훌륭하고 조화롭게 작동합니다.

Drew: 기본적으로 전체 API에서 일관된 응답 형식을 제공하는 것 같습니다. 당신은 그것이 어떻게 보이는지 디자인할 필요가 없습니다. 일관된 결과만 얻을 수 있습니다.

이브: 맞아요.

Drew: 큰 범위의 API 엔드포인트, 특히 대규모 팀에서 일관성을 유지하는 것이 정말 어려울 수 있기 때문에 꽤 승리할 수 있다고 생각합니다. 다양한 사람들이 다양한 일을 하고 있습니다. 아주 엄격한 거버넌스가 없으면 정말 빨리 복잡해질 수 있습니다. 그렇죠?

이브: 네, 절대적으로요. 그리고 Schema는 모든 것을 설명하는 아주 좋은 작은 문서라고 생각합니다. 쿼리를 보내려고 할 때마다 해당 스키마의 모든 필드를 볼 수 있는 자동 이점을 얻을 수 있습니다. 내부 쿼리를 보낼 수 있고 GraphQL 및 GraphQL Playground와 같은 모든 종류의 멋진 도구가 있기 때문입니다. API의 데이터와 상호 작용하는 데 사용할 수 있는 작은 도구입니다.

Eve: 하지만 REST API를 ping하는 것과 같이 Postman을 가지고 놀아본 적이 있다면 문서가 실제로 존재하지 않거나 찾기가 어렵거나 그런 것들이 많습니다. GraphQL은 API의 일부가 될 수 있는 모든 것을 설명할 수 있는 멋진 응집 레이어를 제공합니다.

Drew: 실제로 서버 측에서는 어떻게 작동합니까? 내 말은, 인프라의 일부로 GraphQL 서비스를 실행해야 하는 것 같은데, 어떤 형태를 취하나요? 자체 포트에서 실행되는 전체 서버입니까? 아니면 기존 Express 또는 Apache 또는 해당 서비스로 확인되는 경로가 있는 무엇이든 통합하는 라이브러리와 같습니까? 어떻게 구현합니까?

Eve: 네, 실제 서버입니다. 따라서 가장 인기 있는 GraphQL 구현은 Node.js 서버입니다. GraphQL이 사양으로 출시되었을 때 팀은 JavaScript로 이 참조 구현을 출시했습니다. 이 참조 구현은 팝업된 다른 모든 서버에 대한 지침 역할을 하는 일종의 노드 서버입니다. 하지만 예, 이러한 서버를 자체 인스턴스에서 실행할 수 있습니다. Lambda에 넣을 수 있습니다. Apollo Server Express와 Apollo Server Lambda가 있습니다. 실제로 이 작업을 실행하는 데 사용할 수 있는 모든 종류의 다양한 유형의 구현입니다.

Drew: 그래서 서버가 가지고 있는 스키마의 개념에 대해 간단히 언급했습니다.

이브: 네.

Drew: 이름을 확인자에 매핑하는 것보다 더 엄격하게 유형을 설명할 수 있는 기능을 제공합니다. 거기에 더 많은 관련이 있습니다.

이브: 네. 완전한 언어가 있습니다. 그래서 나는 사양을 참조했고 그것이 무엇인지 설명하지 않았습니다. GraphQL 자체는 쿼리 언어와 스키마 정의 언어를 설명하는 사양입니다. 따라서 고유한 구문이 있습니다. 이러한 유형을 정의하기 위한 자체 규칙이 있습니다.

Eve: 스키마 정의 언어를 사용할 때 기본적으로 해당 언어의 모든 기능을 사용하여 API의 일부인 유형에 대해 생각합니다. 그것은 또한 당신이 쿼리를 정의하는 곳이기도 합니다. 동사인 돌연변이는 액션과 같이 계정 로그인을 생성하는 것과 같은 것입니다. 그리고 또 다른 멋진 기능인 GraphQL 구독도 Schema에서 바로 정의할 수 있는 실시간 GraphQL입니다.

Eve: 네, 스키마가 정말 중요합니다. 그리고 저는 그것이 우리의 전체 스택 애플리케이션에 걸쳐 이러한 훌륭한 유형 적용을 제공한다고 생각합니다. 왜냐하면 해당 필드와 유형에서 벗어나기 시작하자마자 오류를 보기 시작하기 때문입니다. 스키마의 규칙을 따르고 있습니다.

Drew: TypeScript와 크로스오버가 있습니까? 거기에 둘 사이에 일종의 시너지가 있습니까?

이브: 물론이죠. 그래서 만약 당신이 GraphQL에 대해 많이 이야기하는 사람이라면 때때로 사람들이 당신에게 그것이 나쁘다고 말할 것이고, 당신이 그렇게 할 수 있을 때 공개적으로 당신에게 다가가서 GraphQL이 어떻게 좋지 않은지에 대해 이야기할 것입니다. 그러나 많은 경우 유형에서 얻을 수 있는 멋진 내용을 건너뜁니다. 따라서 TypeScript와의 시너지 효과가 있는 한 Schema의 유형을 사용하여 프런트 엔드 애플리케이션에 대한 유형을 자동 생성할 수 있습니다. 따라서 처음에 생성할 수 있을 뿐만 아니라 프런트 엔드 애플리케이션과의 뛰어난 상호 운용성을 제공할 뿐만 아니라 상황이 변경될 때 유형을 다시 생성한 다음 이러한 변경 사항을 반영하도록 빌드할 수 있기 때문에 큰 승리입니다. 네, 유형이 일종의 사실상의 규칙이 되기 시작하면서 그런 것들이 정말 잘 어울린다고 생각합니다.

Eve: ... JavaScript의 사실상의 규칙처럼, 그것들은 서로 잘 맞습니다.

Drew: TypeScript가 설계된 방식과 관련하여 일종의 지속적인 주제인 것 같습니다. 죄송합니다. TypeScript가 아닙니다. GraphQL은 프론트 엔드와 백 엔드 간의 상호 작용을 공식화하는 데 많은 부분이 있도록 설계되었습니다. 그리고 그것은 일관성을 만드는 것과 지금까지 많은 사람들에게 휴식과 함께 상당히 조잡한 경험이었던 것을 공식화하는 것 사이의 솔루션으로 오고 있습니다. 클라이언트 측 앱을 작성할 때 항상 염두에 두어야 할 한 가지는 코드가 검사를 받고 잠재적으로 수정될 수 있다는 것입니다. 그리고 클라이언트가 데이터를 요청할 수 있는 API를 갖는 것은 위험할 수 있습니다. 이제 원하는 필드를 지정할 수 있다면 위험할 수 있습니다. 전체 스택의 어느 부분에서 사용자의 승인을 처리하고 데이터에 대한 비즈니스 규칙이 시행되는지 확인하시겠습니까?

Eve: 서버에서 모든 것을 처리할 것입니다. 따라서 여러 가지 방식으로 발생할 수 있습니다. 일회성 전략을 사용할 필요는 없지만 확인자가 승인을 처리합니다. 따라서 이는 Auth0과 같은 서비스 또는 자체적으로 구축한 것과 같은 기존의 REST API를 래핑하는 것을 의미할 수 있습니다. 그것은 GitHub, Facebook 또는 Google 로그인과 같은 OAuth와 상호 작용하는 것을 의미할 수 있습니다. 그러나 종종 스키마에 직접 구축됩니다. 따라서 스키마는 로그인 돌연변이를 생성할 것이라고 말할 것입니다. 그런 다음 내 자격 증명과 함께 해당 변형을 보내고 서버에서 모든 자격 증명을 확인합니다. 따라서 클라이언트는 토큰을 전달하는 것과 비슷한 것에 대해 그다지 걱정할 필요가 없습니다. 그러나 대부분은 서버에 내장되어 있습니다.

Drew: 본질적으로 이는 현재 우리가 나머지 엔드포인트를 구축하는 방법과 비교할 때 실제로 변경되지 않습니다. 기술로 휴식을 취하십시오. 글쎄, 그것은 실제로 권한 부여를 다루지 않으며 우리는 미들웨어와 그것을 처리하는 서버에 물건을 가지고 있습니다. GraphQL도 마찬가지입니다. 당신은 그것을 처리합니다. 이를 위한 GraphQL 커뮤니티의 규칙이 있습니까? 일반적인 접근 방식이 있습니까? 아니면 사람들이 그것을 구현하기 위해 선택하는 방법에 대해 도처에 있습니까?

이브: 솔직히 여기저기서 그래요. 대부분의 경우 스키마에 구축하는 사람들을 보게 될 것이라고 생각합니다. 즉, 해당 유형과 권한이 부여된 사용자를 대표하는 사람들과 이러한 유형을 스키마 자체에 구축하는 일반 사용자를 비교하는 것입니다. 그러나 타사 솔루션을 사용하는 많은 사람들도 볼 수 있습니다. 나는 Auth0을 언급했다. 많은 사람들이 권한을 좀 더 집중하고 있는 회사, 특히 소규모 회사, 신생 기업 등에 위임할 것입니다. 그러나 더 큰 회사들이 이에 대한 솔루션을 만들기 시작하는 것도 보게 될 것입니다. 따라서 AWS, Amazon에는 GraphQL의 특징인 AppSync가 있으며 AppSync에 직접 구축된 작성자 롤이 있습니다. 그 모든 것에 대해 걱정할 필요가 없거나 최소한 그 작업을 위한 인터페이스를 제공할 수 있다는 것은 정말 멋진 일입니다. 따라서 이러한 생태계 도구 중 많은 수가 GraphQL에서 권한 부여가 매우 큰 주제라고 생각합니다. 그들은 일종의 필요성, 인증 솔루션에 대한 수요 및 그래프에서 인증을 처리하는 표준 접근 방식을 보았습니다.

Drew: 일종의 승인이 필요하지 않은 구현은 거의 없다고 생각합니다. 예, 상당히 일반적인 요구 사항이 될 것입니다. 우리는 특히 React와 View를 사용할 때 점점 더 컴포넌트화된 애플리케이션을 구축하고 있습니다. 그리고 느슨한 결합의 원칙은 주변 페이지에서 실행 중인 다른 항목을 반드시 알지 못하는 많은 구성 요소를 남깁니다. 그 결과 많은 구성 요소가 동일한 데이터를 쿼리하고 여러 요청을 하는 위험이 있습니까? 아니면 해결해야 하는 앱의 아키텍처 문제일 뿐입니까? 이를 처리하기 위한 잘 알려진 솔루션이 있습니까?

Eve: 글쎄요. 대부분의 경우 GraphQL이 100% 솔루션은 아니지만 거의 모든 GraphQL 쿼리가 HTTP를 통해 전송되기 때문이라고 생각합니다. 따라서 이러한 여러 요청이 발생하는 위치를 추적하려는 경우 애플리케이션에 나머지 데이터를 사용하는 사람들에게는 상당히 친숙한 문제일 것입니다. 따라서 Paulo Client Dev Tools 및 Urkel Dev Tools와 같은 프론트 엔드 개발자를 위한 도구가 있습니다. 이 페이지에는 어떤 검색어가 있습니까?” 그것은 무슨 일이 일어나고 있는지에 대한 정말 명확한 통찰력을 제공합니다. 그것에 대해 몇 가지 학파가 있습니다. 페이지의 모든 데이터에 대해 하나의 크고 거대한 쿼리를 생성합니까? 아니면 앱의 다른 부분에 대한 데이터를 로드하기 위해 더 작은 쿼리를 생성합니까? 두 가지 모두 상상할 수 있듯이 고유한 단점이 있습니다. 큰 쿼리가 있는 경우 더 많은 필드를 기다려야 하기 때문입니다.

Eve: 더 작은 쿼리가 있는 경우 필요한 데이터 간에 충돌이 있을 수 있습니다. 그러나 내 생각에는 너무 많은 접선을 벗어나지 않는 것이지만 이미 거기에 있습니다. 그래서 GraphQL 사양에 Deferred Directive라고 하는 것이 있으며 Deferred Directive는 일종의 2차적으로 콘텐츠를 로드하는 데 도움이 될 것입니다. 따라서 페이지 상단에 가장 먼저 로드하려는 매우 중요한 콘텐츠가 있다고 가정해 보겠습니다. 쿼리에 추가한 다음 모든 후속 필드는 이에 대한 지연 지시문을 가져옵니다. 필드에 추가할 작은 데코레이터일 뿐입니다. 그러면 "알겠습니다. 중요한 데이터를 먼저 로드하고 두 번째 데이터를 보류하고 두 번째 데이터를 로드합니다." 그리고 이것은 일종의 스트리밍 데이터의 모습을 프론트 엔드에 제공하여 인지된 성능과 상호 작용이 있게 합니다. 사람들은 페이지에 대해 모든 단일 필드가 로드되기를 기다리는 대신 데이터를 즉시 보고 있습니다. 예, 문제가 될 수 있습니다.

드류: 네. 우리는 뷰포트에 대해 너무 많이 이야기하고 싶지는 않지만 스크롤 없이 볼 수 있는 부분에 대한 모든 것이 있는 페이지를 설계할 수 있다고 생각합니다. 아래에. 그래서 우리는 데이터 쿼리에 대해 많은 이야기를 했습니다. API의 주요 작업 중 하나는 지속성을 위해 새 데이터와 수정된 데이터를 서버로 다시 보내는 것입니다. 앞서 돌연변이에 대해 간략하게 언급했습니다. 그것이 GraphQL이 서버에 데이터를 다시 쓰는 데 사용하는 용어입니까?

이브: 맞아요. 따라서 데이터에 적용하려는 모든 종류의 변경, 서버에 다시 쓰고 싶은 모든 것, 이는 돌연변이이며 모두 쿼리와 같으며 서버에서 작동하는 명명된 작업입니다. 그렇다면 우리가 사용자들이 할 수 있기를 바라는 모든 것이 무엇인지 생각해 볼 수 있습니까? 돌연변이가 있는 사람을 나타냅니다. 그런 다음 다시 서버에서 해당 항목을 작동시키는 모든 기능을 작성하십시오.

Drew: 그리고 그것이 데이터 쿼리만큼 간단합니까? 돌연변이를 호출하는 것이 그렇게 쉽습니까?

이브: 네. 쿼리 언어의 일부입니다. 그것은 거의 동일하게 보입니다. 유일한 차이점은 쿼리가 필터를 사용한다는 것입니다. 그래서 돌연변이는 쿼리 자체에서 필터처럼 보이는 것을 취했습니다. 그러나 이들은 실제로 데이터를 변경하는 책임이 있습니다. 이메일과 비밀번호가 변형과 함께 전송될 수 있으며 서버는 이를 수집한 다음 이를 사용하여 사용자에게 권한을 부여합니다.

Drew: 이전과 마찬가지로 백엔드에 리졸버를 생성하여 이를 처리하고 필요한 모든 작업을 수행합니다. 데이터를 작성할 때 한 가지 일반적인 경우는 변경 사항을 커밋한 다음 현재 상태의 종류를 얻기 위해 다시 쿼리하려는 것입니다. GraphQL에는 이를 위한 좋은 워크플로가 있습니까?

이브: 돌연변이 그 자체에 살고 있는 것 같아요. 따라서 스키마를 생성할 때 변형 작업을 생성하는 경우가 많습니다. 나는 로그인을 고수하고 이메일과 비밀번호를 입력합니다. 그리고 돌연변이 자체가 무언가를 반환했습니다. 따라서 Boolean과 같은 간단한 것을 반환할 수 있습니다. 이것은 잘 되거나 잘못되었거나 실제 유형을 반환할 수 있습니다. 그래서 종종 로그인 돌연변이와 같은 돌연변이를 보게 될 것입니다. 아마도 사용자를 반환할 것입니다. 따라서 일단 로그인하면 사용자에 대한 모든 정보를 얻을 수 있습니다. 또는 해당 사용자와 사용자가 로그인한 시간을 제공하는 사용자 정의 개체 유형을 만들 수 있으며 반환 개체에서 해당 트랜잭션에 대한 메타데이터를 조금 더 추가할 수 있습니다. . 다시 말하지만, 그것을 디자인하는 것은 당신에게 달려 있지만 그 패턴은 실제로 GraphQL에 구워져 있습니다.

Drew: 이 모든 것이 꽤 훌륭하게 들리지만 모든 기술적 선택에는 절충안이 따릅니다. GraphQL 사용의 단점은 무엇입니까? 정말 좋지 않은 선택이 될 시나리오가 있습니까?

Eve: GraphQL이 어려움을 겪을 수 있는 곳은 1:1 맵을 만드는 것입니다.

Eve: ... 고군분투는 테이블 형식 데이터의 일대일 맵을 만드는 것입니다. 예를 들어 여러분이 모든 종류의 서로 다른 필드가 있는 데이터베이스 테이블을 가지고 있다고 가정해 보겠습니다. 저는 잘 모르겠습니다. 특정 유형의 수천 개의 필드가 있습니다. 그런 유형의 데이터는 훌륭하게 표현될 수 있습니다. GraphQL을 사용하지만 때로는 해당 데이터에 대한 스키마를 생성하는 프로세스를 실행할 때 스키마에서 데이터베이스에서 겪었던 것과 동일한 문제가 남게 됩니다. 실제로 필요합니다. 그래서 저는 그런 장소들이 잠재적으로 문제가 있다고 생각합니다. 나는 데이터를 기반으로 자동 생성된 스키마를 가진 사람들과 이야기를 나눴고 그것은 백만 줄 길이의 스키마 또는 이와 유사한 것이 되었고 수천 줄의 스키마 코드가 되었습니다. 이것이 사람이 읽을 수 있는 문서로서 얼마나 유용한지와 같이 약간 까다로워지는 부분입니다.

이브: 네. 따라서 클라이언트를 다루는 모든 종류의 상황에서 모든 다른 유형의 데이터를 모델링하는 한 정말 적합합니다. 데이터 소스가 너무 크면 약간 까다로워집니다.

Drew: 따라서 현장에서 응답을 신중하게 선별하고 더 많은 수작업을 수행하는 곳이면 어디에서나 매우 강력한 결과를 얻을 수 있습니다. 하지만 방대한 스키마가 있어서 자동 생성을 하는 경우에는 다소 다루기 어려워질 수 있습니다.

이브: 네. 그리고 좋은 도구가 있기 때문에 사람들이 그것에 대해 듣고 동의하지 않는다고 생각합니다. 그러나 GraphQL이 정말 빛나는 곳은 서버에 논리를 추상화하고 프런트 엔드 개발자에게 구성 요소 또는 프런트 엔드 데이터 요구 사항을 정의할 수 있는 자유를 제공하고 실제로 팀으로 스키마를 관리하는 단계라고 생각합니다.

Drew: 결과의 페이지 매김을 처리하기 위해 쿼리 언어에 내장된 것이 있습니까? 아니면 필요에 따라 사용자 정의 구현이 필요한가요?

이브: 네. 페이지 매김, 먼저 스키마에 빌드하므로 이에 대한 페이지 매김을 정의할 수 있습니다. 커뮤니티에서 일종의 가이드라인이 등장했습니다. GraphQL이 처음인지 아닌지 살펴봐야 하는 좋은 예는 GitHub GraphQL API입니다. 그들은 기본적으로 GraphQL을 사용하여 공개 API의 v4용 API를 다시 만들었습니다. 따라서 실제 대기업에서 이를 대규모로 사용하는 방법을 살펴보기에 좋은 지점입니다. 많은 사람들이 큰 API를 실행하고 있지만 모든 사람에게 공개하지는 않습니다. 그래서 페이지 매김은 API에 정말 훌륭하게 내장되어 있으며 여러분이 생성한 처음 50개의 리포지토리를 반환할 수 있습니다. 또는 데이터의 아이디어를 기반으로 레코드를 반환하기 위해 커서 기반 페이지 매김을 사용할 수도 있습니다. 따라서 커서 기반 페이지 매김 및 첫 번째, 마지막 레코드와 같은 위치 페이지 매김은 일반적으로 사람들이 접근하는 방식이지만 많은 기술이 있습니다.

Drew: GraphQL을 사용할 때 알아야 할 큰 문제가 있습니까? 조직에 새 GraphQL 설치를 배포하려고 한다고 가정해 보겠습니다. 앞으로 GraphQL을 사용하여 모든 새 API 끝점을 구축할 것입니다. 무엇을 알아야 합니까? 수풀에 뭔가가 숨어 있습니까?

Eve: 덤불 속에 숨어, 항상 기술과 함께, 그렇지? GraphQL에 내장되어 있지는 않지만 번거로움 없이 구현할 수 있는 것 중 하나가 API 보안이라고 생각합니다. 예를 들어, 당신은 내가 거대한 쿼리를 가지고 있다고 언급했고, 우리는 권한을 가지고 이것에 대해 이야기했지만 누군가가 거대한 중첩 쿼리, 친구의 친구, 친구의 친구, 친구의 친구를 보낼 수 있는 API를 여는 것도 무섭습니다. , 체인 아래로. 그런 다음 기본적으로 사람들이 이러한 거대한 쿼리로 DDoS를 수행하도록 허용하고 있습니다. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. 전적으로.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. 이별의 말이 있나요?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. 감사합니다.