Home | Relay
Relay documentation landing page
relay.dev
Relay는 GraphQL로 데이터를 가져오고 업데이트할 수 있는 React용 데이터 관리 라이브러리이다.
기본적으로 뛰어난 성능을 제공하면서 코드의 안정성과 유지보수를 유지하기 위한 수년간의 학습을 구현한다.
Relay는 데이터 불러오기에 React 컴포넌트의 composability를 제공한다. 각 컴포넌트는 자체적으로 필요한 데이터를 선언하고, Relay는 이를 효율적인 pre-load 쿼리로 결합한다. 설계의 모든 측면은 컴포넌트를 작성하는 자연스러운 방식이 가장 성능이 좋도록 하는 것이다.
Features
- 선언적 데이터: 각 컴포넌트에 필요한 데이터를 선언하기만 하면 Relay가 로딩상태를 처리한다.
- co-location과 composability: 각 컴포넌트는 자체적으로 필요한 데이터를 선언하고 Relay는 이를 효율적인 쿼리로 결합하낟. 다른 화면에서 컴포넌트를 재사용하면 쿼리가 자동으로 업데이트된다.
- pre-fetching: 릴레이는 코드를 분석하여 코드가 다운로드되거나 실행되기도 전에 쿼리 fetching을 실행할 수 있도록 한다.
- UI patterns: 릴레이는 로딩상태, 페이지 매김, 리페칭, 낙관적 업데이트, 롤백 및 올바르게 구현하기 까다로운 기타 일반적인 UI 동작을 구현한다.
- 일관된 업데이트: 릴레이는 정규화된 데이터 저장소를 유지하므로 동일한 데이터를 관찰하는 컴포넌트가 다른 쿼리로 데이터에 도달하더라도 동기화 상태를 유지할 수 있도록 한다.
- Streaming and deferred data: 쿼리의 일부를 선언적으로 지연시키면 데이터가 스트리밍됨에 따라 릴레이가 UI를 점진적으로 다시 렌더링한다.
- Great DX: relay는 graphql스키마에 대한 자동완성 및 go-to-definition을 제공
- Type Safety: relay는 타입 정의를 생성하므로 실수를 런타임이 아닌 정적으로 포착할 수 있다.
- manage Local data: 서버 상태와 로컬 상태에 동일한 api 제공
- Hyper-optimized runtime: relay는 끊임없이 최적화된다. JIT 친화적인 런타임은 예상되는 페이로드를 정적으로 결정하여 수신 데이터를 더 빠르게 처리한다.
Stack
Relay는 웹과 React Native에서 작동하며, 두 화녕 모두에서 메타에서 광범위하게 사용된다. 프레임워크에 구애받지 않으며 리액트라우터, CRA등과 함께 작동한다. 타입스크립트와 플로우 모두에서 작동한다.
Relay는 GraphQL과 완전히 연결되어 있으므로 GraphQL을 사용할 수 없는 경우 적합한 선택이 아니다.
Relay는 데이터를 가져오고 관리하는 UI에 구애받지 않은 레이어와 로딩상태, 페이징, UI 패러다임을 처리하는 React전용 레이어가 있다. 주로 리액트와 함께 사용할 때 지원되지만, 필요한 경우 React 외부에서 Relay 데이터에 엑세스할 수도 있습니다. Relay의 React 관련 부분은 Suspense를 기반으로 하므로 이전 버전의 React를 사용하는 경우 몇 가지 제한이 있다.
GraphQL and Relay
이 섹션은 GraphQL, React 및 스택의 다른 부분과 관련하여 Relay의 위치를 파악하기 위한 개요이다. 모든 세부 사항을 이해하려고 애쓰지말고 요점만 파악한 다음 다음 섹션으로 넘어가서 코드 작업을 시작하게쇼. 훨씬 더 구체적인 내용은 듀토리얼 전반에 걸쳐 예제를 살펴보면서 설명합니다.
GraphQL은 서버에서 데이터를 쿼리하고 수정하기 위한 언어이다. GraphQL의 독특한 점은 고정된 API 엔드포인트가 아니라 서버가 클라이언트가 필요한 데이터 조합을 요청하는데 사용할 수 있는 옵션을 제공한다는 것이다. 따라서 프론트엔드 개발자는 데이터 요구 사항이 변경될 때마다 새로운 엔드포인트를 작성하고 배포할 필요가 없으므로 더 빠르게 움직일 수 있다. 또한 클라이언트의 새 버전이 출시될 때 이전 버전과의 호환성을 위해 추가 필드를 남기지 않고 필요한 데이터만 요청할 수 있다는 의미이기도 하다.
GraphQL은 모든 종류의 백엔드에서 데이터를 쿼리할 수 있는 통합 인터페이스를 제공한다. 데이터가 관계형 SQL 데이터베이스, 그래프 지향 데이터베이스 또는 여러 마이크로 서비스에 있든, GraphQL 서버는 여러 백엔드에서 데이터를 수집하여 단일 응답으로 클라이언트에 보낼 수 있으므로 클라이언트에서 각 서비스에 대한 별도의 쿼리를 실행하는 것보다 더 효율적이다.
기존 HTTP API에는 각각 고정된 정보 집합으로 응답하는 URL이 있다.
Request:
GET /person?id=24601
Response:
{"id": "24601", "name": "Jean Valjean", "age": 64, "occupation": "Mayor"}
GraphQL에서는 클라이언트가 원하는 특정 정보를 요청하면 서버는 요청된 정보만 응답한다.
Request:
query {
person(id: "24601") {
name
occupation
}
}
Response:
{
"person": {
"name": "Jean Valjean",
"occupation": "Mayor"
}
}
클라이언트가 요청한 필드만 응답에 포함되어 있다는 점에 유의하자.
이름에서 알 수 있듯이 GraphQL은 데이터를 그래프로 요청한다. 그래프는 노드와 엣지로 구성된다.
GraphQL을 사용하면 한 노드에서 다른 노드까지 이러한 에지를 따라가며 방문하는 각 노드에 대한 정보를 요청할 수 있다. 예를 들어 위에서는 한 사람에서 도시로 이동해서 해당 도시에 대한 정보를 얻는다.
즉, 여러 요청을 차례로 보내는 대신 한 번의 요청으로 한 화면에 대한 모든 데이터를 효율적으로 가져올 수 있다는 뜻이다. UI의 각화면에 대해 별도의 엔드포인트를 작성하고 유지 관리할 필요 없이 이를 달성할 수 있다.
대신 GraphQL 서버는 어떤 종류의 노드가 있는지, 어떻게 연결되어 있는지, 각 노드에 어떤 정보가 포함되어 있는지를 설명하는 스키마를 제공한다. 그런 다음 이 스키마에서 원하는 정보를 골라 선택하면 된다.
이 튜토리얼의 예제 앱은 뉴스피드 앱이므로 스키마는 다음과 같은 유형으로 구성된다.
- Story: 뉴스피드 스토리를 나타내며 제목, 이미지, 게시한 사람 또는 조직에 대한 에지와 같은 필드가 있다.
- Person: 이름, 이메일, 친구목록(다른 사람에 대한 에지)등의 정보가 포함된다.
- Viewer: 앱을 보는 사람을 나타내며 뉴스피드 스토리 목록과 같은 정보를 포함한다.
- Image: 이미지 자체에 대한 URL과 텍스트 설명이 포함된다.
GraphQL언어에는 스키마 지정을 위한 타입시스템과 언어가 포함되어 있다. 다음은 예제 앱의 스키마 정의에서 발췌한 내용이다. 모든 세부 사항에 대해 걱정하지 말고 일반적인 아이디어를 얻으면 된다.
// A newsfeed story. It has fields, some of which are scalars (e.g. strings
// and numbers) and some that are edges that point to other nodes in the graph,
// such as the 'thumbnail' and 'poster' fields:
type Story {
id: ID!
category: Category
title: String
summary: String
thumbnail: Image
poster: Actor
}
// An Actor is an entity that can do something on the site. This is an
// interface that multiple different types can implement, in this case
// Person and Organization:
interface Actor {
id: ID!
name: String
profilePicture: Image
}
// This is a specific type that implements that interface:
type Person implements Actor {
id: ID!
name: String
email: String
profilePicture: Image
location: Location
}
// The schema also lets you define enums, such as the category
// of a newsfeed story:
enum Category {
EDUCATION
NEWS
COOKING
}
쿼리 외에도 GraphQL을 사용하면 서버에 데이터를 업데이트하도록 요청하는 Mutation을 보낼 수 잇다. 쿼리가 HTTP GET요청과 유사하다면 mutation은 POST 요청과 동일하다. POST와 마찬가지로 서버가 업데이트된 데이터를 응답하도록 한다. GraphQL에는 실시간 업데이트를 위한 개방형 연결을 허용하는 구독도 있다. (GraphQL은 일반적으로 HTTP를 통해 구현되므로 쿼리 및 mutation은 GET및 POST와 유사할 뿐만 아니라 그렇게 전송될 수도 있다.)
GraphQL에 대해 이야기했으니 이제 릴레이에 대해서 이야기해보자. 코드를 살펴보기 전에 몇 가지 다른 부분을 간략하게 살펴보자.
릴레이는 클라이언트를 위한 데이터 관리 라이브러리로, GraphQL를 지향하지만 이를 최대한 활용할 수 있는 매우 구체적인 방식으로 사용한다.
최상의 성능을 위해 앱이 각 화면이나 페이지의 시작 부분에서 개별 컴포넌트가 자체 요청을 발행하는 대신 단일 요청을 발행하기를 원할 것이다. 하지만 이 방식은 컴포넌트와 화면을 서로 연결하기 때문에 유지 보수에 큰 문제가 발생한다. 특정 컴포넌트에 추가 데이터가 필요한 경우 해당 컴포넌트가 사용되는 모든 화면을 찾아서 해당 화면의 쿼리에 새 필드를 추가해야한다. 반면에 특정 필드의 필요성을 제거하면 모든 쿼리에서 해당 필드를 다시 제거해야 하는데, 이번에는 해당 필드가 다른 컴포넌트에서 사용되고 있지 않다고 확신할 수 있을까? 이렇게 큰 화면에 전체에 걸친 쿼리를 유지 관리하기 어려워진다.
Relay의 고유한 강점은 각 컴포넌트가 로컬에서 자체 데이터 요구 사항을 선언하도록 하고 이러한 요구 사항을 더 큰 쿼리로 연결함으로써 이러한 절충점을 피할 수 있다는 점이다. 이렇게 하면 성능과 유지보수성을 모두 확보할 수 있다.
Relay는 컴파일러를 통해 자바스크립트 코드에서 GraphQL fragment를 스캔한다음 이러한 조각을 완전한 쿼리로 연결하여 이를 수행한다.
컴파일러 외에도 Relay에는 GraphQL의 fetching및 처리를 관리하는 런타임 코드가 있다. 이 코드는 검색된 모든 데이터의 로컬 캐시(스토어라고 함)를 유지 관리하고 각 컴포넌트에 속한 데이터를 제공한다.
중앙 집중식 스토어의 장점은 데이터가 업데이트될 때 일관성을 유지할 수 있다는 것이다. 예를 들어 UI에 누군가가 자신의 이름을 수정할 수 있는 방법이 있는 경우 한 곳에서 업데이트하면 해당 사용자의 이름을 표시하는 모든 컴포넌트가 처음에 데이터를 검색할 때 다른 쿼리를 사용했더라도 새로운 정보를 볼 수 있다. 이는 릴레이가 데이터가 들어오는대로 데이터를 정규화하여 단일 그래프 노드에 대해 보이는 모든 데이터를 한 곳으로 병합하므로 동일한 노드의 복사본이 여러개 있지 않기 때문이다.
실제로 Relay는 단순히 데이터를 쿼리할 뿐만 아니라 최적 업데이트와 롤백을 지원하는등 쿼리 및 업데이트의 전체 라이프사이클을 제공한다. pagination, refetching등 UI를 만드는데 필요한 모든 기본 작업을 수행할 수 있다. Store의 데이터가 업데이트될 때마다 Relay는 특정 데이터를 표시하는 컴포넌트만 효율적으로 다시 렌더링한다.
GraphQL은 데이터를 그래프로 모델링하고 서버에서 해당 데이터를 쿼리(및 데이터 업데이트)하기 위한 언어이다. Relay는 각 React 컴포넌트와 함께 배치된 개별 조각에서 쿼리를 작성할 수 있는 GraphQL용 React기반 클라이언트 라이브러리이다. 데이터가 쿼리된 후 Relay는 일관성을 유지하고 데이터가 업데이트되면 컴포넌트를 다시 렌더링한다.