Falcor와 GraphQL의 차이점은 무엇입니까?


163

GraphQL은 형식 시스템, 쿼리 언어 및 실행 의미 체계, 정적 유효성 검사 및 형식 검사로 구성되며 각각 아래에 설명되어 있습니다. 이러한 각 구성 요소를 안내하기 위해 다양한 GraphQL 조각을 설명하기 위해 설계된 예제를 작성했습니다.

-https : //github.com/facebook/graphql

Falcor를 사용하면 가상 JSON 그래프를 통해 모든 원격 데이터 소스를 단일 도메인 모델로 나타낼 수 있습니다. 클라이언트의 메모리 또는 서버의 네트워크를 통해 데이터의 위치에 관계없이 동일한 방식으로 코딩합니다.

- http://netflix.github.io/falcor/

Falcor와 GraphQL의 차이점은 무엇입니까?


5
자파르가 릴레이 / GraphQL 및 Falcor / JSON 그래프의 차이에 대해 이야기 포드 캐스트 확인 youtu.be/WL54eYbTJUw?t=53m55s
gdi2290

답변:


131

내가 보았던 각도 공기 에피소드 26 : FalcorJS 및 각도 2자파르 Husain은 어떻게 대답 GraphQL는 비교 FalcorJS . 이것은 요약입니다 (단편화).

  • FalcorJS와 GraphQL은 동일한 문제 (데이터 쿼리, 데이터 관리)를 다루고 있습니다.
  • 중요한 차이점은 GraphQL은 쿼리 언어이고 FalcorJS는 그렇지 않다는 것입니다.
  • FalcorJS에 리소스를 요청할 때는 유한 한 일련의 값을 명시 적으로 요구합니다. FalcorJS는 예를 들어 범위와 같은 것을 지원 genres[0..10]합니다. 그러나 개방형 쿼리는 지원하지 않습니다 (예 :) genres[0..*].
  • GraphQL은 다음을 기준으로 설정됩니다. true, 정렬 순서 등 모든 레코드를 제공하십시오. 이러한 의미에서 GraphQL 쿼리 언어는 FalcorJS보다 강력합니다.
  • GraphQL을 사용하면 강력한 쿼리 언어가 있지만 서버에서 해당 쿼리 언어를 해석해야합니다.

Jafar는 대부분의 애플리케이션에서 클라이언트에서 서버로 이동하는 쿼리 유형이 동일한 형태를 공유한다고 주장합니다. 따라서 get 및 set과 같이 구체적이고 예측 가능한 작업을 수행하면 캐시를 활용할 수있는 더 많은 기회가 노출됩니다. 또한 많은 개발자가 REST 아키텍처에서 간단한 라우터를 사용하여 요청을 매핑하는 데 익숙합니다.

마지막 토론은 GraphQL과 함께 제공되는 전력이 복잡성을 능가하는지 여부를 해결합니다.


82

나는 이제 두 라이브러리로 앱을 작성했으며 Gajus의 게시물에있는 모든 것에 동의 할 수 있지만 프레임 워크를 사용하는 데 가장 중요한 몇 가지 다른 것을 발견했습니다.

  • 아마도 가장 큰 실질적인 차이점은 GraphQL에서이 시점까지 수행 한 대부분의 예제와 작업이 GraphQL을 Relay와 통합하는 데 집중되어 있다는 것입니다. ReactJS 위젯을 데이터 요구 사항과 통합하는 Facebook의 시스템입니다. 반면에 FalcorJS는 위젯 시스템과 별도로 작동하는 경향이 있습니다. 즉, 비 React / Relay 클라이언트에 통합하는 것이 더 쉬울 수 있으며 위젯 데이터 종속성을 위젯과 일치시키는 측면에서 자동으로 덜 수행됩니다.
  • 클라이언트 측 통합에서 융통성이있는 FalcorJS의 단점은 서버가 어떻게 작동해야하는지에 대해 매우 의견이 많을 수 있다는 것입니다. FalcorJS는 실제로 "HTTP를 통한이 쿼리 호출"기능을 가지고 있습니다. Jafar Husain은 그것에 대해 많이 이야기하지 않는 것 같습니다. 일단 포함하면 클라이언트 라이브러리가 서버 정보에 반응하는 방식은 다음과 같습니다. GraphQL / Relay는 구성 계층을 추가합니다. FalcorJS에서 영화에 대한 값을 반환하면 반환 값에 'movie'가 더 좋은 반면 GraphQL에서는 쿼리가 'film'을 반환하더라도 클라이언트 쪽 데이터 저장소에 'movie'로 넣어야한다고 설명 할 수 있습니다. '. -이것은 Gajus가 언급 한 힘 대 복잡성 절충의 일부입니다.
  • 실질적으로 GraphQL과 Relay는 더욱 발전된 것으로 보입니다. Jafar Husain은 Netflix 프론트 엔드의 다음 버전이 FalcorJS에서 적어도 부분적으로 실행될 것이라고 언급했지만 Facebook 팀은 3 년 이상 생산에서 일부 버전의 GraphQL / Relay 스택을 사용하고 있다고 언급했습니다.
  • GraphQL 및 Relay와 관련된 오픈 소스 개발자 커뮤니티가 번성하고있는 것 같습니다. GraphQL과 Relay에 대한 많은 관심을 끄는 지원 프로젝트가 있지만 FalcorJS를 개인적으로 거의 찾지 못했습니다. 또한 릴레이의 기본 github 저장소 ( https://github.com/facebook/relay/pulse )는 FalcorJS의 github 저장소 ( https://github.com/netflix/falcor/pulse ) 보다 훨씬 더 활동적 입니다. 처음 Facebook 리포지토리를 가져 왔을 때 예제가 깨졌습니다. github 문제를 열었고 몇 시간 내에 해결되었습니다. 반면에 FalcorJS에서 열린 github 이슈는 2 주 동안 공식적인 응답이 없었습니다.

1
GraphQL (2012)은 React and Relay 이전에 사용되어 왔으므로 첫 번째 포인트가 완전히 정확하지 않을 수 있습니다.
Burgi

당신이 옳을 수도 있습니다. 나는 페이스 북이 아니기 때문에 실제로는 역사에 대해 말할 수 없습니다. 내 의견은 현재 페이스 북의 문서 및 대화 상태에서 더 많이 온다. 그들은 동반자 ( facebook.github.io/react/blog/2015/02/20/… ) 로 세계에 소개 되었고 둘 다 꽤 길을 되돌아 왔습니다. 나는 2015 년 초에 작성된 의견에서 Relay에 대해 모호한 핸드 웨이브가 3 년 전으로 되돌아 간 것을 보았습니다. 그러나 나는 특별한 지식이 없다.
오버 클럭

25

GraphQL의 엔지니어 중 한 명인 Lee Byron 은 hashnode에서 AMA를 수행 했습니다.이 질문에 대한 대답은 다음과 같습니다.

  • Falcor는 Observables, GraphQL 값만 반환합니다. Netflix가 Falcor를 어떻게 사용하고 싶었는지에 대해서는이 점이 의미가 있습니다. 여러 요청을하고 데이터가 준비되면 제시하지만 클라이언트 개발자는 Observables와 직접 작업해야합니다. GraphQL은 요청 / 응답 모델이며 사용하기 쉬운 JSON을 반환합니다. 릴레이는 일반 값만 사용하면서 Falcor가 제시하는 역 동성을 일부 추가합니다.
  • 시스템을 입력하십시오. GraphQL은 타입 시스템의 관점에서 정의되었으므로 GraphiQL, 코드 생성기, 오류 감지 등과 같은 흥미로운 도구를 많이 만들 수있었습니다. Falcor는 훨씬 더 역동적입니다. 이런 종류의 것.
  • 네트워크 사용량. GraphQL은 원래 저급 네트워크의 저가형 장치에서 Facebook의 뉴스 피드를 운영하도록 설계되었으므로 대기 시간을 최소화하기 위해 단일 네트워크 요청으로 필요한 모든 것을 선언 할 수 있도록 많은 시간이 소요됩니다. 반면에 Falcor는 종종 추가 데이터를 수집하기 위해 여러 번 왕복을 수행합니다. 이것은 시스템의 단순성과 네트워크의 제어 사이의 절충 일뿐입니다. Netflix의 경우 매우 낮은 엔드 장치 (예 : Roku 스틱)도 처리하지만 네트워크는 비디오를 스트리밍하기에 충분할 것이라고 가정합니다.

편집 : Falcor는 실제로 배치 요청을 할 수 있으므로 네트워크 사용량에 대한 의견이 정확하지 않습니다. @PrzeoR에게 감사합니다


4
NOT TRUE-> "" "Falcor는 종종 추가 데이터를 수집하기 위해 여러 번의 왕복을 수행합니다. 이것은 시스템의 단순성과 네트워크 제어 간의 절충 일뿐입니다." "". Falcor Batch 기능을 확인하기 만하면 Relay보다 동일하거나 더 좋습니다.
PrzeoR

1
@PrzeoR 수정 해 주셔서 감사합니다! 게시물을 수정했습니다!
YasserKaddour

당신은 환영 :-) 여기에 자세한 내용은 FalcorJS 검사 관련이 있습니다 reactjs.co/2016/02/03/...
PrzeoR을

위대한 기사가 실제로 Falcor 불행히도 나는 스칼라 개발자 오전 스칼라와 그 문제에 대한 모든 다른 언어로 어떤 Falcor 구현이없는, 중대하다, 그러나이 상그리아는 스칼라에서 훌륭한 GraphQL 구현
YasserKaddour


21

업데이트 : 나는 내 게시물에서 주요 내용에 대한 보완적인 것으로 당신과 공유하고 싶은 매우 유용한 의견을 발견했습니다. 여기에 이미지 설명을 입력하십시오

예제가 부족하면 awesome-falcorjs 저장소를 사용자가 찾을 수 있으며 Falcor의 CRUD 사용법에 대한 다른 예제가 있습니다. https://github.com/przeor/awesome-falcorjs ... 두 번째로 " Falcor를 포함하는 Full Stack React 개발 마스터 링 (사용 방법을 배우는 좋은 방법) :

여기에 이미지 설명을 입력하십시오

아래의 원래 게시물 :

FalcorJS ( https://www.facebook.com/groups/falcorjs/ )는 Relay / GraphQL에 비해 훨씬 간단합니다.

GraphQL + Relay의 학습 곡선은 거대합니다. 여기에 이미지 설명을 입력하십시오

짧은 요약에서 : Falcor로 가십시오. 예산이 많고 팀에 학습 시간이 많을 때까지 다음 프로젝트에서 Falcor를 사용하고 RELAY + GRAPHQL을 사용하십시오.

GraphQL + Relay에는 효율적으로 사용해야하는 거대한 API가 있습니다. Falcor는 작은 API를 가지고 있으며 JSON에 익숙한 모든 프론트 엔드 개발자가 쉽게 이해할 수 있습니다.

자원이 한정된 AGILE 프로젝트가 있다면-> FalcorJS로 가십시오!

내 주장 : FalcorJS는 풀 스택 자바 스크립트에서 500 % 이상 효율적입니다.

또한 내 프로젝트에 FalcorJS 스타터 키트를 게시했습니다 (+ 더 많은 스택 팔코의 예제 프로젝트). https://www.github.com/przeor

기술적 세부 사항에 대해 더 자세히 살펴 보려면 다음을 수행하십시오.

1) Falcor를 사용하는 경우 프런트 엔드와 백엔드 모두에서 사용할 수 있습니다.

'falcor'에서 falcor를 가져옵니다.

그런 다음에 따라 모델을 작성하십시오.

... 백엔드에서 사용하기 쉬운 두 개의 라이브러리가 필요합니다 .a) falcor-express-한 번만 사용하십시오 (예 : app.use ( '/ model.json', FalcorServer.dataSourceRoute (() => new NamesRouter ())) ). 출처 : https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

b) falcor-router-SIMPLE 경로를 정의 합니다 (예 : route : '_view.length' ). 출처 : https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

Falcor는 학습 곡선 측면에서 케이크 한 조각입니다.

FB의 lib보다 훨씬 간단한 문서를 볼 수 있으며 " falcorjs (netflix falcor)에 관심을 가져야하는 이유 "기사도 확인하십시오 .

2) Relay / GraphQL은 거대한 엔터프라이즈 도구와 유사합니다.

예를 들어, 별도로 이야기하는 두 가지 문서가 있습니다.

a) 릴레이 : https://facebook.github.io/relay/docs/tutorial.html- 컨테이너-경로-루트 컨테이너-준비 상태-돌연변이-네트워크 계층-바벨 릴레이 플러그인-GRAPHQL

  • GraphQL 릴레이 사양
  • 객체 식별
  • 연결
  • 돌연변이
  • 추가 자료
  • API 참조

  • 계전기

  • 릴레이 컨테이너
  • 릴레이 경로
  • Relay.RootContainer
  • 릴레이 .QL
  • 릴레이 돌연변이
  • Relay.PropTypes
  • 릴레이 상점
  • 인터페이스

  • RelayNetworkLayer

  • RelayMutationRequest
  • RelayQueryRequest

b) GrapQL : https://facebook.github.io/graphql/

  • 2 언어
  • 2.1 소스 텍스트
  • 유니 코드
  • 2.1.2 공백
  • 2.1.3 라인 터미네이터
  • 주석
  • 중요하지 않은 쉼표
  • 어휘 토큰
  • 무시 된 토큰
  • 구두점
  • 2.1.9 이름
  • 2.2 쿼리 문서
  • 2.2.1 조작
  • 2.2.2 선택 세트
  • 필드
  • 인수
  • 필드 별칭
  • 2.2.6 단편
  • 2.2.6.1 타입 조건
  • 인라인 조각
  • 입력 값
  • 2.2.7.1Int 값
  • 플로팅 값
  • 부울 값
  • 문자열 값
  • 2.2.7.5 가치
  • 리스트 값
  • 입력 객체 값
  • 변수
  • 2.2.8.1 단편 내에서의 다양한 사용
  • 입력 유형
  • 2.2.10 지시어
  • 2.2.10.1Fragment 지시어
  • 3 타입 시스템
  • 3.1 유형
  • 스칼라
  • 3.1.1.1 내장 스칼라
  • 3.1.1.1.1Int
  • 플로트 3.1.1.1.2
  • 3.1.1.1.3 문자열
  • 부울
  • 3.1.1.1.5ID
  • 3.1.2 객체
  • 3.1.2.1 객체 필드 인수
  • 3.1.2.2 객체 필드 비추천
  • 3.1.2.3 객체 유형 검증
  • 3.1.3 인터페이스
  • 인터페이스 유형 검증
  • 3.1.4 연합
  • 3.1.4.1 유니온 타입 검증
  • 3.1.5 이수
  • 입력 객체
  • 3.1.7 목록
  • Null이 아닌
  • 3.2 지시어
  • 3.2.1 @ 건너 뛰기
  • 3.2.2@include
  • 3.3 시작 유형
  • 4 검사
  • 4.1 일반 원칙
  • 4.1.1 명명 규칙
  • 4.1.2 문서
  • 4.1.3 지원 중단
  • 4.1.4 유형 이름 검사
  • 4.2 스키마 내성
  • 4.2.1 "__ Type"타입
  • 4.2.2 종류 종류
  • 4.2.2.1 스칼라
  • 4.2.2.2 객체
  • 4.2.2.3 연합
  • 4.2.2.4 인터페이스
  • 4.2.2.5 이넘
  • 4.2.2.6 입력 객체
  • 4.2.2.7 목록
  • 널이 아닌
  • 4.2.2.9 조합리스트와 널이 아닌 것
  • 4.2.3 __ 필드 유형
  • 4.2.4 __InputValue 타입
  • 5 검증
  • 5.1 작동
  • 5.1.1 명명 된 작업 정의
  • 5.1.1.1 작업 이름 고유성
  • 5.1.2 익명 연산 정의
  • 5.1.2.1 고독한 익명 작업
  • 5.2 분야
  • 5.2.1 객체, 인터페이스 및 공용체 유형의 필드 선택
  • 5.2.2 필드 선택 병합
  • 리프 필드 선택
  • 5.3 인수
  • 인자 이름
  • 인자 고유성
  • 인수 값 유형 정확성
  • 5.3.3.1 호환 가능한 값
  • 5.3.3.2 필수 인수
  • 5.4 조각
  • 5.4.1 조각 선언
  • 5.4.1.1Fragment 이름 고유성
  • 5.4.1.2Fragment Spread Type 존재
  • 복합 유형에 대한 5.4.1.3Fragments
  • 5.4.1.4Fragments를 사용해야합니다
  • 펼치기
  • 5.4.2.1Fragment spread target defined
  • 5.4.2.2Fragment spread는 사이클을 형성해서는 안됩니다
  • 5.4.2.3Fragment spread 가능
  • 5.4.2.3.1 객체 범위의 객체 확산
  • 5.4.2.3.2 객체 범위의 추상 스프레드
  • 5.4.2.3.3 추상 범위의 객체 확산
  • 5.4.2.3.4 추상 범위의 추상 스프레드
  • 5.5 값
  • 5.5.1 입력 객체 필드 고유성
  • 5.6 지시어
  • 5.6.1 지시어 정의
  • 5.7 변수
  • 5.7.1 가변 고유성
  • 5.7.2 가변 기본값이 올바르게 입력되었습니다
  • 변수는 입력 유형입니다
  • 5.7.4 모든 변수 사용 정의
  • 사용 된 모든 변수
  • 5.7.6 모든 변수 사용이 허용됩니다
  • 6 실행
  • 6.1 요청 평가
  • 6.2 강제 변수
  • 6.3 운영 평가
  • 6.4 선택 세트 평가
  • 6.5 그룹화 된 필드 세트 평가
  • 필드 항목
  • 6.5.2 정상 평가
  • 시리얼 실행
  • 에러 처리
  • 6.5.5 무효
  • 7 응답
  • 7.1 직렬화 형식
  • 7.1.1JSON 직렬화
  • 7.2 응답 형식
  • 7.2.1 데이터
  • 7.2.2 오류
  • 부록 : 표기법
  • A.1 문맥이없는 문법
  • A.2Lexical 및 Syntaxtical Grammar
  • A.3 문법 표기법
  • A.4 문법 시맨틱
  • A.5 알고리즘
  • 부록 : 문법 요약
  • B.1 무시 된 토큰
  • B.2Lexical 토큰
  • B.3Query 문서

그것은 당신의 선택입니다 :

단순하고 짧고 문서화 된 Falcor JS VERSUS GraphQL & Relay와 같은 길고 고급 문서화가 된 기업용 고급 도구

앞에서 말했듯이 JSON 사용 아이디어를 이해하는 프론트 엔드 개발자라면 Falcor 팀의 JSON 그래프 구현이 풀 스택 개발 프로젝트를 수행하는 가장 좋은 방법입니다.


13
주관적인 답변. 기술적 비교는 포함되지 않습니다. 주석으로 더 적합합니다.
Gajus

2
@GajusKuizinas 주관적인 대답? 둘 다의 문서를 확인하십시오. ;-) Falcor가 더 빠르고 배우기 쉽다고 말하고 있습니다. 사실입니다. 과대 광고 ;-)
PrzeoR

2
그것은 단지 의견 일 뿐이며 질문에 전혀 대답하지 않습니다.
Michał Miszczyszyn

14
이것은 기술의 학습 곡선이 반드시 주관적이지 않고 쉽게 측정 될 수있는 것은 아니라고 여기에 큰 해답이라고 생각합니다. 사실은 여기에 제시되어 명확한 결론을 도출 할 수 있습니다. 실제 세계에서 심각한 전문가들은 이러한 사실을 고려합니다. 이것은 모든 공개 질문이며, 이와 같은 답변으로부터 분명히 이익을 얻습니다.
bmaggi

2
@MorgenCheng에 동의합니다. 지난 2 주 동안 GraphQL / Relay, Cashay, Redux 및 Falcor를 평가하는 과정을 진행했으며, PrzeoR에 100 % 동의합니다. Relay와 GraphQL은 훌륭한 기술이지만 훨씬 더 많은 두뇌를 필요로하며 초보자를 구하기가 더 어렵습니다. 상당한 양의 학습이 수반됩니다. Falcor의 단점은 완전한 CRUD 기반 앱에 대한 예제가 부족하다는 것입니다. 그리고 PostgreSQL 및 RethinkDB 프로젝트가 JsonGraph를 뱉어내는 것을보고 싶습니다.
Dom

5

즉, Falcor 또는 GraphQL 또는 Restful은 동일한 문제를 해결합니다. 데이터를 효과적으로 쿼리 / 조작 할 수있는 도구를 제공하십시오.

차이점은 데이터 표시 방식에 있습니다.

  • Falcor는 데이터를 매우 큰 가상 JSON 트리로 생각하기를 원하며 get , setcall to read, write 데이터를 사용합니다.
  • GraphQL은 데이터를 사전 정의 된 유형이 지정된 객체 그룹으로 생각하고 쿼리돌연변이 를 사용 하여 데이터를 읽고 씁니다.
  • Restful은 데이터를 리소스 그룹으로 생각하고 HTTP 동사를 사용하여 데이터를 읽고 씁니다.

사용자에게 데이터를 제공해야 할 때마다 클라이언트-> 쿼리-> {레이어가 쿼리를 데이터 ops로 변환}-> 데이터로 좋아합니다.

GraphQL, Falcor 및 JSON API (및 ODdata)로 어려움을 겪은 후 자체 데이터 쿼리 레이어를 작성했습니다 . GraphQL과 비교하면 더 간단하고 배우기 쉬우 며 더 동등합니다.

다음에서 확인하십시오.
https://github.com/giapnguyen74/nextql

또한 실시간 쿼리 / 돌연변이를 위해 featherjs와 통합됩니다. https://github.com/giapnguyen74/nextql-feathers


2

간단하지만 중요한 차이점에서 시작하면 GraphQL 은 쿼리 기반이지만 Falcor 는 그렇지 않습니다!

그러나 그들은 어떻게 당신을 도와 줍니까?

기본적으로 그들은 데이터를 관리하고 쿼리하는 데 도움이되지만 GraphQL 에는 req / res 모델이 있으며 데이터를 JSON 으로 반환합니다 . 기본적으로 GraphQL 의 아이디어는 모든 데이터를 단일 목표로 얻는 단일 요청을 가지고 있습니다 ... 정확한 요청을 통해 정확한 응답을 얻을 수 있습니다. 따라서 3G 네트워크와 같은 저속 인터넷 및 모바일 장치에서 실행할 수 있습니다. 따라서 모바일 사용자가 많거나 어떤 이유로 요청이 적고 응답 속도가 빠른 경우 , GraphQL 사용 ... Faclor 가 이것과 너무 멀지 않은 동안 읽으십시오 ...

반면, Netflix의 Falcor 는 일반적으로 모든 데이터를 단일 요청으로 개선하려고 시도하는 경우에도 모든 데이터를 검색하도록 추가 요청 (일반적으로 두 번 이상)을 요청합니다. Falcor 는 쿼리에 더 제한적이며 사전에 없습니다. 범위 등의 정의 된 쿼리 도우미

그러나 더 명확하게하기 위해 각각이 어떻게 자신을 소개하는지 봅시다.

GraphQL, API의 쿼리 언어

GraphQL은 API에 대한 쿼리 언어이며 기존 데이터로 쿼리를 수행하기위한 런타임입니다. GraphQL은 API의 데이터에 대한 완전하고 이해하기 쉬운 설명을 제공하고, 고객에게 필요한 것을 정확히 요구할 수있는 기능을 제공하며, 시간이 지남에 따라 API를보다 쉽게 ​​발전시키고 강력한 개발자 도구를 제공합니다.

GraphQL 쿼리를 API로 보내고 필요한 것을 정확히 얻으십시오. GraphQL 쿼리는 항상 예측 가능한 결과를 반환합니다. GraphQL을 사용하는 앱은 서버가 아닌 데이터를 제어하기 때문에 빠르고 안정적입니다.

GraphQL 쿼리는 한 리소스의 속성에 액세스 할뿐만 아니라 이들 리소스 사이의 참조를 원활하게 따릅니다. 일반적인 REST API는 여러 URL에서로드해야하지만 GraphQL API는 단일 요청으로 앱에 필요한 모든 데이터를 가져옵니다. 느린 모바일 네트워크 연결에서도 GraphQL을 사용하는 앱은 빠를 수 있습니다.

GraphQL API는 엔드 포인트가 아닌 유형 및 필드의 관점에서 구성됩니다. 단일 엔드 포인트에서 데이터의 모든 기능에 액세스하십시오. GraphQL은 유형을 사용하여 앱이 가능한 것을 요청하고 명확하고 유용한 오류를 제공하도록합니다. 앱은 유형을 사용하여 수동 구문 분석 코드 작성을 피할 수 있습니다.


효율적인 데이터 가져 오기를위한 JavaScript 라이브러리 인 Falcor

Falcor를 사용하면 가상 JSON 그래프를 통해 모든 원격 데이터 소스를 단일 도메인 모델로 나타낼 수 있습니다. 클라이언트의 메모리 또는 서버의 네트워크를 통해 데이터의 위치에 관계없이 동일한 방식으로 코딩합니다.

JavaScript와 유사한 경로 구문을 사용하면 원하는 때에 원하는만큼 데이터에 쉽게 액세스 할 수 있습니다. get, set 및 call과 같은 익숙한 JavaScript 작업을 사용하여 데이터를 검색합니다. 데이터를 알고 있다면 API를 알고있는 것입니다.

Falcor는 그래프에서 참조를 자동으로 순회하고 필요에 따라 요청합니다. Falcor는 모든 네트워크 통신을 투명하게 처리하여 기회를 일괄 처리하고 중복 제거 요청을 처리합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.