GraphQL Relay와 스키마 작업에 대한 심층 가이드

graphql relay 시작하기 소개 이 가이드에서는 relay가 무엇인지, 스키마와 함께 작업하는 방법, back4app에서 graphql을 사용하는 방법을 배울 수 있습니다 전제 조건 아직 튜토리얼은 아니지만, 편안하게 읽기 위해서는 다음이 필요합니다 기본 javascript 지식 graphql에 대한 기본 이해 만약 없다면, graphql js 가 시작하기에 완벽한 장소입니다 relay relay는 facebook 엔지니어링 팀이 개발한 graphql 클라이언트로, 데이터 중심 애플리케이션을 구축할 때 성능을 위해 설계되었습니다 더 정확히 말하자면, relay는 클라이언트 측에서 graphql 데이터를 선언적으로 가져오고 관리하기 위한 프레임워크로, 애플리케이션의 성공을 돕기 위해 엄격한 규칙을 사용합니다 facebook과 같은 복잡한 애플리케이션을 지원하기 위해 확장성을 염두에 두고 구축되었습니다 graphql과 relay의 궁극적인 목표는 즉각적인 ui 반응 상호작용을 제공하는 것입니다 graphql을 사용하는 주요 장점 중 하나는 예를 들어 애플리케이션 페이지를 구축하는 데 필요한 모든 데이터를 단일 쿼리로 가져올 수 있다는 것입니다 물론 이것은 좋습니다(서버에 대한 왕복을 줄일 수 있습니다) 하지만 그와 함께 문제가 발생합니다 애플리케이션의 다양한 부분에서 이 구성 요소를 재사용할 때 동일한 구성 요소에 대해 서로 다른 쿼리를 사용할 수 있습니다 이러한 문제를 피하기 위해 relay는 중요한 개념인 콜로케이션(colocation)을 사용합니다 콜로케이션 relay를 사용할 때 구성 요소와 그 데이터 요구 사항이 함께 존재합니다 구성 요소의 데이터 요구 사항은 그 안에 선언됩니다 즉, 모든 구성 요소는 자신이 필요한 데이터를 선언합니다 relay는 각 구성 요소가 렌더링될 때 필요한 데이터를 갖도록 보장합니다 콜로케이션 개념 뒤에 있는 relay 구조는 컨테이너입니다 가장 일반적인 것은 relay 프래그먼트 컨테이너입니다 컨테이너는 각 구성 요소를 렌더링할 때 필요한 데이터를 충족하려고 시도하는 구성 요소입니다 컨테이너는 graphql 프래그먼트를 사용하여 데이터 의존성을 선언합니다 모든 구성 요소는 자신의 프래그먼트 컨테이너를 가집니다 컨테이너는 데이터를 직접 가져오지 않고, 렌더링할 때 필요한 데이터의 사양만 선언합니다 데이터는 서버 측에서 가져옵니다 relay는 렌더링이 발생하기 전에 데이터가 사용 가능하도록 보장합니다 relay는 이러한 컨테이너로 데이터 트리를 구성하며, 중복을 무시하고 서버에서 데이터를 가져옵니다 개념을 예제로 설명해 보겠습니다 프래그먼트는 graphql 유형의 필드 선택입니다 relay는 프래그먼트, 페이지네이션 및 리패치 컨테이너와 함께 작동합니다 가장 일반적인 것은 프래그먼트 컨테이너입니다 아래에 graphql의 프래그먼트를 보고, 그 다음에 relay에서 동일한 것을 보십시오 1 query health { 2 health 3 } 1 type homeprops = { 2 query home query; 3 }; 4&#x9; 5 const home = ({query} homeprops) => { 6 return ( 7 \<view> 8 \<text>api health {query health ? 'health' 'not health' }\</text> 9 \</view> 10 ); 11 }; 12&#x9; 13 const homefragment = createfragmentcontainer(home, { 14 query graphql` 15 fragment home query on query { 16 health 17 } 18 `, 19 }); 20&#x9; 21 export default createqueryrenderermodern(homefragment, home, { 22 query graphql` 23 query homequery { 24 home query 25 } 26 `, 27 hidesplash true, 28 }); 첫 번째 코드에서는 이 쿼리를 재사용 가능한 조각으로 나눌 수 있는 graphql 버전을 볼 수 있습니다 다음 코드에서는 조각과 데이터를 동일한 구성 요소에서 함께 보여주는 relay 버전을 볼 수 있습니다 위치 지정은 데이터 정의와 뷰 정의가 함께 존재한다는 것을 의미합니다 위치 지정에는 몇 가지 이점이 있습니다 우리는 필요한 날짜를 정확히 선언하기만 하면 됩니다 이는 데이터를 과도하게 가져오는 것이 어렵다는 것을 의미하며, 이는 우리의 애플리케이션을 개선하고, 데이터를 과소하게 가져오는 것이 어렵기 때문에 누락된 데이터로 인한 오류를 방지합니다 또 다른 중요한 개념은 데이터 마스킹으로, 이는 구성 요소가 요청한 데이터에만 접근할 수 있음을 의미합니다 데이터 마스킹은 의존성 오류를 방지하는 데 도움이 됩니다 또한, 구성 요소는 사용하는 데이터가 변경될 때만 업데이트됩니다 쿼리 렌더러 모던 더 나은 이해를 위해 공식 쿼리 렌더러 문서 https //relay dev/docs/en/query renderer html#docsnav 를 살펴보는 것을 권장합니다 조각 컨테이너를 기반으로 relay는 이를 읽고 보유한 데이터를 기반으로 서버에 요청을 합니다 하지만, 이 요청은 어떻게 발생할까요? 여기서 쿼리 렌더러 모던이 등장합니다 쿼리 렌더러 모던은 조각 컨테이너를 읽고 서버에 요청을 하며 데이터를 구성 요소에 반환하는 구성 요소입니다 모든 루트 구성 요소는 이 요청을 수행하는 쿼리 렌더러 모던을 가집니다 위의 예에서는 우리가 읽어야 할 조각만 전달하도록 추상화를 가지고 있으며, 나머지 작업은 createqueryrenderermodern 내부에서 수행됩니다 문서의 다음 단계에서는 위의 순수 예제를 기반으로 한 추상화를 이해하기 위해 createqueryrenderermodern을 입력할 것입니다 아래는 query render modern의 순수 예제입니다 1 export default function artistrenderer({artistid}) { 2 return ( 3 \<queryrenderer 4 environment={environment} 5 query={graphql` 6 query queryrenderersartistquery($artistid string!) { 7 # the root field for the query 8 artist(id $artistid) { 9 # a reference to your fragment container 10 artistheader artist 11 } 12 } 13 `} 14 variables={ {artistid} } 15 render={({error, props}) => { 16 if (error) { 17 return \<div>{error message}\</div>; 18 } else if (props) { 19 return \<artist artist={props artist} />; 20 } 21 return \<div>loading\</div>; 22 }} 23 /> 24 ); 25 } query renderer modern은 hoc 컴포넌트 다시 말해, 요청할 데이터가 있는 컨테이너를 소유한 컴포넌트를 감싸고, relay 환경으로 요청을 수행하며, 데이터를 아래로 전달하여 컴포넌트에 반환합니다 자동 타입 생성 relay와 함께 작업하면 애플리케이션을 타입 안전하게 구축할 수 있습니다 우리가 말했듯이 모든 컴포넌트는 자신의 데이터의 소유자가 될 것입니다 따라서 relay compiler를 실행하면 모든 데이터 프래그먼트를 읽고 graphql 스키마와 확인을 수행합니다 relay 컴파일러의 모든 검사가 통과하면, 생성된 타입은 generated 라는 폴더에 생성됩니다 이 폴더는 루트 컴포넌트 폴더 안에 생성됩니다 아래 예제를 참조하세요 구성 요소 홈 api 상태 확인 1 const home = ({query} homeprops) => { 2 return ( 3 \<view> 4 \<text>api health {query health ? 'health' 'not health' }\</text> 5 \</view> 6 ); 7 }; 8&#x9; 9 const homefragment = createfragmentcontainer(home, { 10 query graphql` 11 fragment home query on query { 12 health 13 } 14 `, 15 }); 16&#x9; 17 export default createqueryrenderermodern(homefragment, home, { 18 query graphql` 19 query homequery { 20 home query 21 } 22 `, 23 hidesplash true, 24 }); 홈 구성 요소의 유형을 포함하는 생성된 폴더 생성된 유형 이후에는 구성 요소에서 유형을 가져오고 조합하기만 하면 됩니다 1 import {home query} from " / generated /home query graphql"; 2 3 type homeprops = { 4 query home query; 5 }; 유형은 facebook의 유형을 위한 핵심 언어인 flow로 생성됩니다 그러나 라이브러리를 사용하면 typescript로 생성할 수 있습니다 이는 react native와 함께 작업하는 데 가장 일반적입니다 요약하자면, relay 컴파일러를 사용하면 런타임 전에 데이터 구현을 확인할 수 있습니다 이는 버그를 방지하고 애플리케이션 품질과 개발 시간을 개선하는 데 도움이 됩니다 쿼리에서는 n개의 서로 다른 구성 요소에서 중복 데이터를 피할 수 있습니다 중복 데이터가 있는지 확인합니다 중복이 있으면 불필요한 부분을 제거합니다 이는 쿼리의 페이로드 크기를 줄이고 애플리케이션의 성능을 더욱 향상시킬 것입니다 개발 쿼리에서는 n개의 서로 다른 구성 요소에서 중복 데이터를 피할 수 있습니다 중복 데이터가 있는지 확인합니다 중복이 있으면 불필요한 부분을 제거합니다 이는 쿼리의 페이로드 크기를 줄이고 애플리케이션의 성능을 더욱 향상시킬 것입니다 서버 측 back4app에서 back4app은 프로젝트에서 사용할 수 있는 준비된 relay 호환 graphql api를 생성합니다 back4app이 생성하는 것은 서버 측에서 직접 구축할 필요가 없습니다 인프라 back4app 대시보드에서 클래스, 유형 및 데이터베이스에 필요한 모든 것을 포함한 완전한 데이터 모델을 생성할 수 있습니다 서버를 직접 설정하고 유지 관리하는 것에 대해 걱정할 필요가 없습니다 데이터 모델을 back4app에 생성한 후, 우리는 graphql을 사용하여 프론트엔드에서 소비하는 데 필요한 모든 것을 생성할 것입니다 graphql api 스키마를 살펴보겠습니다 스키마 스키마 파일은 모든 graphql 애플리케이션의 핵심입니다 클라이언트 측에서 사용할 수 있는 전체 서버를 설명합니다 relay는 쿼리 문자열을 확인하고 / generated /mycomponent graphql에 나타나도록 생성된 파일을 사용하여 스키마 파일을 사용합니다 이는 자동 유형 생성 주제에서 언급한 바와 같습니다 relay 컴파일러를 사용하려면 graphql 서버의 api를 설명하는 graphql 또는 json graphql 스키마 파일이 필요합니다 이러한 파일은 서버의 진실의 로컬 표현이며 수정되지 않습니다 모든 graphql 스키마는 쿼리 유형, 변이 유형 및 구독 유형으로 구성될 수 있습니다 프론트엔드에서 relay에 의해 소비되는 스키마로 작업하려면 백엔드의 몇 가지 핵심 개념이 필요합니다 노드 인터페이스와 연결 이 독서를 더 쉽게 추상화할 수 있도록 노드 인터페이스와 relay 연결에 대해 읽어보는 것을 추천합니다 노드 인터페이스 노드 인터페이스는 id를 통해 데이터를 가져오는 데 도움을 주기 위해 graphql의 모든 유형을 구현합니다 이는 서버에서 데이터를 더 쉽게 가져오고 업데이트할 수 있도록 하기 위한 구현입니다 따라서 각 유형의 각 데이터는 고유한 id를 가지며, 이를 글로벌 고유 id라고 하며, 노드 인터페이스에 의해 구현됩니다 노드를 사용함으로써 relay는 중첩 쿼리를 피하고 이를 사용하여 가져오기 및 다시 가져오기를 수행합니다 이는 구현하기 어려우며 약간의 작업이 필요하지만, 우리는 이미 이를 여러분을 위해 구축했습니다! 페이지네이션 프론트엔드와 백엔드에서 데이터를 구성하는 데 relay가 도움을 줄 수 있도록 구성되도록 구축되었습니다 페이지네이션 작업을 위해 우리는 연결을 가지고 있습니다 이러한 연결은 우리가 가져오고 있는 유형의 노드를 구현하며, 표준 모델을 가지고 있어 서버 측에서 페이지네이션 구현을 용이하게 합니다 다행히도, 다시 말하지만, 우리는 이미 프론트엔드에서 사용할 수 있도록 구축했습니다 결론 이 가이드에서는 relay가 무엇인지, 그 주요 개념과 작동 방식을 소개했습니다 또한 back4app이 graphql 서버 생성을 자동화하고 graphql api와 함께 작업할 수 있는 완전한 데이터베이스를 제공하는 방법을 볼 수 있었습니다 요약하자면, 전체 백엔드는 이미 back4app에 의해 구축되었습니다 대시보드에서 유형을 생성하고 생성된 스키마를 기반으로 소비를 시작하기만 하면 됩니다 다음 섹션에서는 프론트엔드에서 이 스키마를 처리하는 방법과 relay를 사용하기 위한 환경을 준비하는 방법을 설명하겠습니다 또한 graphql 요리책 https //www back4app com/docs/parse graphql/graphql getting started , 이를 통해 대시보드에서 더 많은 개념을 이해하는 데 도움을 받을 수 있습니다