Jaka jest różnica między Falcor a GraphQL?

GraphQL składa się z systemu typów, języka zapytań i semantyki wykonywania, statycznej walidacji i introspekcji typów, każdy opisany poniżej. Aby poprowadzić Cię przez każdy z tych komponentów, napisaliśmy przykład mający na celu zilustrowanie różnych części GraphQL.

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

Falcor umożliwia reprezentowanie wszystkich zdalnych źródeł danych jako modelu pojedynczej domeny za pośrednictwem wirtualnego wykresu JSON. Kodujesz w ten sam sposób bez względu na to, gdzie znajdują się dane, czy to w pamięci na kliencie, czy przez sieć na serwerze.

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

Jaka jest różnica między Falcor i GraphQL (w kontekście Relay)?

Ja obejrzałem odcinek Air kątowa 26: FalcorJS i kątowa 2 gdzie Jafar Husain odpowiedzi jak GraphQL porównuje do FalcorJS . Oto podsumowanie (parafrazowanie):

• FalcorJS i GraphQL rozwiązują ten sam problem (wysyłanie zapytań do danych, zarządzanie danymi).
• Ważną różnicą jest to, że GraphQL jest językiem zapytań, a FalcorJS nie.
• Kiedy prosisz FalcorJS o zasoby, bardzo wyraźnie prosisz o skończoną serię wartości. FalcorJS obsługuje takie rzeczy, jak zakresy, np genres[0..10]. Nie obsługuje jednak zapytań otwartych, np genres[0..*].
• GraphQL jest oparty na ustawieniach: podaj mi wszystkie rekordy, które są prawdziwe, uporządkuj według tego itp. W tym sensie język zapytań GraphQL jest potężniejszy niż FalcorJS.
• Dzięki GraphQL masz potężny język zapytań, ale musisz interpretować ten język zapytań na serwerze.

Jafar twierdzi, że w większości aplikacji typy zapytań przechodzących od klienta do serwera mają ten sam kształt. Dlatego posiadanie określonych i przewidywalnych operacji, takich jak pobieranie i ustawianie, zapewnia więcej możliwości wykorzystania pamięci podręcznej. Ponadto wielu programistów jest zaznajomionych z mapowaniem żądań za pomocą prostego routera w architekturze REST.

Końcowa dyskusja dotyczy tego, czy moc oferowana przez GraphQL przeważa nad złożonością.

Napisałem teraz aplikacje w obu bibliotekach i zgadzam się ze wszystkim w poście Gajusa, ale odkryłem kilka innych rzeczy, które są najważniejsze w moim własnym wykorzystaniu frameworków.

• Prawdopodobnie największą praktyczną różnicą jest to, że większość przykładów i przypuszczalnie prac wykonanych do tej pory w GraphQL koncentrowała się na integracji GraphQL z Relay - systemem Facebooka do integracji widżetów ReactJS z ich wymaganiami dotyczącymi danych. Z drugiej strony FalcorJS ma tendencję do działania niezależnie od systemu widgetów, co oznacza, że ​​zarówno integracja z klientem innym niż React / Relay może być łatwiejsza, jak i że zrobi mniej automatycznie, jeśli chodzi o dopasowanie zależności danych widgetów do widgetów.
• Drugą stroną elastyczności FalcorJS w integracji po stronie klienta jest to, że można bardzo wyrazić opinię na temat tego, jak serwer powinien działać. FalcorJS faktycznie ma bezpośrednią możliwość „Wywołaj to zapytanie przez HTTP” - chociaż Jafar Husain nie wydaje się mówić o tym zbyt wiele - a po ich uwzględnieniu sposób, w jaki biblioteki klienckie reagują na informacje o serwerze, jest dość podobny, z tym wyjątkiem, że GraphQL / Relay dodaje warstwę konfiguracji. W FalcorJS, jeśli zwracasz wartość dla filmu, wartość zwracana lepiej brzmi „film”, podczas gdy w GraphQL możesz opisać, że nawet jeśli zapytanie zwraca „film”, powinieneś umieścić to w magazynie danych po stronie klienta jako „film ”. - to część kompromisu między mocą a złożonością, o którym wspomniał Gajus.
• Z praktycznego punktu widzenia GraphQL i Relay wydają się być bardziej rozwinięte. Jafar Husain wspomniał, że następna wersja nakładki Netflix będzie działała przynajmniej częściowo na FalcorJS, podczas gdy zespół Facebooka wspomniał, że używają jakiejś wersji stosu GraphQL / Relay w produkcji od ponad 3 lat.
• Wydaje się, że społeczność programistów open source wokół GraphQL i Relay kwitnie. Istnieje wiele projektów wspierających, które cieszą się dużym zainteresowaniem, związanych z GraphQL i Relay, podczas gdy osobiście znalazłem bardzo niewiele projektów związanych z FalcorJS. Również podstawowe repozytorium github dla Relay ( https://github.com/facebook/relay/pulse ) jest znacznie bardziej aktywne niż repozytorium github dla FalcorJS ( https://github.com/netflix/falcor/pulse ). Kiedy po raz pierwszy ściągnąłem repozytorium Facebooka, przykłady były zepsute. Otworzyłem problem na githubie i został naprawiony w ciągu kilku godzin. Z drugiej strony, sprawa github, którą otworzyłem na FalcorJS, nie doczekała się oficjalnej odpowiedzi od dwóch tygodni.

Lee Byron, jeden z inżynierów stojących za GraphQL, przeprowadził AMA na hashnode , oto jego odpowiedź na to pytanie:

• Falcor zwraca Observables, a GraphQL tylko wartości. Ze względu na to, jak Netflix chciał używać Falcor, ma to dla nich duży sens. Wysyłają wiele żądań i prezentują dane tak, jak są gotowe, ale oznacza to również, że programista klienta musi pracować bezpośrednio z Observables. GraphQL jest modelem żądania / odpowiedzi i zwraca kod JSON, który jest banalnie łatwy w użyciu. Relay dodaje z powrotem część dynamizmu, który prezentuje Falcor, zachowując tylko zwykłe wartości.
• System typów. GraphQL jest zdefiniowany w kategoriach systemu typów, co pozwoliło nam zbudować wiele interesujących narzędzi, takich jak GraphiQL, generatory kodu, wykrywanie błędów itp. Falcor jest znacznie bardziej dynamiczny, co jest cenne samo w sobie, ale ogranicza możliwości tego rodzaju rzeczy.
• Wykorzystanie sieci. GraphQL został pierwotnie zaprojektowany do obsługi kanału informacyjnego Facebooka na urządzeniach z niższej półki, nawet w słabszych sieciach, więc robi wszystko, abyś mógł zadeklarować wszystko, czego potrzebujesz w jednym żądaniu sieciowym, aby zminimalizować opóźnienia. Z drugiej strony Falcor często wykonuje wiele podróży w obie strony, aby zebrać dodatkowe dane. To tak naprawdę kompromis między prostotą systemu a kontrolą sieci. W przypadku Netflix radzą sobie również z bardzo niskimi urządzeniami końcowymi (np. Roku Stick), ale założenie jest takie, że sieć będzie wystarczająco dobra do strumieniowego przesyłania wideo.

Edycja: Falcor rzeczywiście może grupować żądania , przez co komentarz dotyczący wykorzystania sieci jest niedokładny. Dzięki @PrzeoR

AKTUALIZACJA: Pod moim postem znalazłem bardzo przydatny komentarz, którym chcę się z wami podzielić jako uzupełnienie głównej treści:

Jeśli chodzi o brak przykładów, repozytorium awesome-falcorjs może być przydatne, istnieją różne przykłady użycia CRUD Falcor: https://github.com/przeor/awesome-falcorjs ... Po drugie, jest książka o nazwie „ Mastering Full Stack React Development ”, który obejmuje również Falcor (dobry sposób, aby nauczyć się go używać):

ORYGINALNY POST PONIŻEJ:

FalcorJS ( https://www.facebook.com/groups/falcorjs/ ) jest znacznie prostszy w działaniu w porównaniu z Relay / GraphQL.

Krzywa uczenia się dla GraphQL + Relay jest OGROMNA:

W moim krótkim podsumowaniu: Idź po Falcor. Używaj Falcor w swoim następnym projekcie, aż będziesz mieć duży budżet i dużo czasu na naukę dla swojego zespołu, a następnie użyj RELAY + GRAPHQL.

GraphQL + Relay ma ogromne API, w którym musisz być skuteczny. Falcor ma małe API i jest bardzo łatwe do zrozumienia dla każdego programisty front-end, który zna JSON.

Jeśli masz projekt AGILE z ograniczonymi zasobami -> wybierz FalcorJS!

MOJA SUBIEKTYWNA opinia: FalcorJS jest o 500% + łatwiejszy do działania w javascript z pełnym stosem.

Opublikowałem również kilka zestawów startowych FalcorJS w moim projekcie (+ więcej przykładowych projektów full-stack Falcor): https://www.github.com/przeor

Aby uzyskać więcej szczegółów technicznych:

1) Kiedy używasz Falcor, możesz używać zarówno na front-endzie, jak i backendzie:

importować falcor z „falcor”;

a następnie zbuduj swój model na podstawie.

... potrzebujesz również dwóch bibliotek, które są proste w użyciu na zapleczu: a) falcor-express - używasz go raz (np. app.use ('/ model.json', FalcorServer.dataSourceRoute (() => nowy NamesRouter ())) ). Źródło: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

b) falcor-router - tam definiujesz PROSTE trasy (np. route: '_view.length' ). Źródło: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

Falcor to bułka z masłem, jeśli chodzi o krzywą uczenia się.

Możesz również zapoznać się z dokumentacją, która jest znacznie prostsza niż biblioteka FB, a także zapoznać się z artykułem " Dlaczego powinieneś przejmować się falcorjs (netflix falcor) ".

2) Relay / GraphQL jest bardziej prawdopodobnym narzędziem wielkiego przedsiębiorstwa.

Na przykład masz dwie różne dokumentacje, które oddzielnie mówią o:

a) Przekaźnik: https://facebook.github.io/relay/docs/tutorial.html - Kontenery - Trasy - Kontener główny - Stan gotowości - Mutacje - Warstwa sieciowa - Wtyczka Babel Relay - GRAPHQL

• Specyfikacja przekaźnika GraphQL
• Identyfikacja obiektu
• Połączenie
• Mutacje
• Dalsze czytanie

• ODNIESIENIE DO API

• Przekaźnik

• RelayContainer
• Relay.Route
• Relay.RootContainer
• Relay.QL
• Przekaźnik. Mutacja
• Relay.PropTypes
• Przekaźnik Sklep

• INTERFEJSY

• RelayNetworkLayer

• RelayMutationRequest
• RelayQueryRequest

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

• 2 Język
• 2.1 Tekst źródłowy
• 2.1.1 Unicode
• 2.1.2 Biała przestrzeń
• 2.1.3 Terminatory linii
• 2.1.4 Uwagi
• 2.1.5 Nieistotne przecinki
• 2.1.6 Tokeny leksykalne
• 2.1.7 Zignorowane tokeny
• 2.1.8 Wykrętaki
• 2.1.9 Nazwy
• 2.2 Dokument zapytania
• 2.2.1 Operacje
• 2.2.2 Zestawy selekcji
• 2.2.3 Pola
• 2.2.4Argumenty
• 2.2.5 Alias ​​pola
• 2.2.6 Fragmenty
• 2.2.6.1 Warunki typu
• 2.2.6.2 Fragmenty w linii
• 2.2.7 Wartości wejściowe
• 2.2.7.1 Wartość Int
• 2.2.7.2 Wartość zmienna
• 2.2.7.3 Wartość logiczna
• 2.2.7.4 Wartość ciągu
• 2.2.7.5 Wartość liczbowa
• 2.2.7.6 Wartość listy
• 2.2.7.7 Wprowadzanie wartości obiektów
• 2.2.8 Zmienne
• 2.2.8.1 Zmienne użycie w ramach fragmentów
• 2.2.9 Typy wejść
• 2.2.10Dyrektywy
• 2.2.10.1 Dyrektywy fragmentaryczne
• 3 System typów
• 3.1 Rodzaje
• 3.1.1 Skalary
• 3.1.1.1 Wbudowane skalary
• 3.1.1.1.1 Int
• 3.1.1.1.2 Float
• 3.1.1.1.3 Ciąg
• 3.1.1.1.4Boolean
• 3.1.1.1.5ID
• 3.1.2 Przedmioty
• 3.1.2.1 Argumenty pola obiektu
• 3.1.2.2 Wycofanie pola obiektu
• 3.1.2.3 Walidacja typu obiektu
• 3.1.3 Interfejsy
• 3.1.3.1 Weryfikacja typu interfejsu
• 3.1.4 Związki
• 3.1.4.1 Walidacja typu unii
• 3.1.5 Enum
• 3.1.6 Obiekty wejściowe
• 3.1.7 Listy
• 3.1.8 Brak wartości Null
• 3.2 Dyrektywy
• 3.2.1@skip
• 3.2.2@include
• 3.3 Typy początkowe
• 4Introspection
• 4.1 Zasady ogólne
• 4.1.1 Konwencje nazewnictwa
• 4.1.2 Dokumentacja
• 4.1.3 Wycofanie się
• 4.1.4 Introspekcja nazw typów
• 4.2 Introspekcja schematu
• 4.2.1Typ „__Type”
• 4.2.2 Rodzaje typów
• 4.2.2.1Skalar
• 4.2.2.2 Przedmiot
• 4.2.2.3Union
• 4.2.2.4 Interfejs
• 4.2.2.5 Enum
• 4.2.2.6 Obiekt wejściowy
• 4.2.2.7 Lista
• 4.2.2.8 Brak wartości zerowej
• 4.2.2.9 Łączenie listy i wartości niezerowej
• 4.2.3 Typ __Field
• 4.2.4Typ __InputValue
• 5 Walidacja
• 5.1 Operacje
• 5.1.1 Definicje nazwanych operacji
• 5.1.1.1 Niepowtarzalność nazwy operacji
• 5.1.2 Definicje anonimowych operacji
• 5.1.2.1 Samodzielna anonimowa operacja
• 5.2 Pola
• 5.2.1 Wybór pól dla typów obiektów, interfejsów i unii
• 5.2.2 Scalanie wyboru pola
• 5.2.3 Wybór pól liści
• 5.3 Instrumenty
• 5.3.1 Nazwy instrumentów
• 5.3.2 Wyjątkowość instrumentu
• 5.3.3 Poprawność typów wartości instrumentów
• 5.3.3.1 Zgodne wartości
• 5.3.3.2 Wymagane argumenty
• 5.4 Fragmenty
• 5.4.1 Deklaracje fragmentów
• 5.4.1.1 Niepowtarzalność nazwy fragmentu
• 5.4.1.2 Istnienie typu spreadu fragmentowego
• 5.4.1.3Fragmenty w typach złożonych
• 5.4.1.4 Fragmenty muszą być używane
• 5.4.2 Fragmentowe spready
• 5.4.2.1 Zdefiniowano cel rozproszenia fragmentów
• 5.4.2.2 Spready fragmentaryczne nie mogą tworzyć cykli
• 5.4.2.3 Rozprzestrzenianie się fragmentów jest możliwe
• 5.4.2.3.1 Rozpiętości obiektów w zakresie obiektów
• 5.4.2.3.2 Abstrakcyjne rozrzuty w zakresie obiektu
• 5.4.2.3.3 Spready obiektów w zakresie abstrakcyjnym
• 5.4.2.3.4 Abstrakcyjne spready w zakresie abstrakcyjnym
• 5.5 Wartości
• 5.5.1 Unikalność pola obiektu wejściowego
• 5.6 Dyrektywy
• 5.6.1 Dyrektywy są zdefiniowane
• 5.7 Zmienne
• 5.7.1 Zmienna niepowtarzalność
• 5.7.2 Zmienne wartości domyślne są poprawnie wpisywane
• 5.7.3 Zmienne to typy danych wejściowych
• 5.7.4 Zdefiniowane wszystkie zastosowania zmiennych
• 5.7.5 Wszystkie używane zmienne
• 5.7.6 Wszystkie zastosowania zmiennych są dozwolone
• 6 Wykonanie
• 6.1 Ocena wniosków
• 6.2 Zmienne wymuszające
• 6.3 Operacje oceniające
• 6.4 Ocena zbiorów wskazań
• 6.5 Ocena zgrupowanego zestawu pól
• 6.5.1 Wpisy polowe
• 6.5.2 Normalna ocena
• 6.5.3 Wykonanie seryjne
• 6.5.4 Obsługa błędów
• 6.5.5 Nieważność
• 7Response
• 7.1 Format serializacji
• 7.1.1 Serializacja JSON
• 7.2 Format odpowiedzi
• 7.2.1Dane
• 7.2.2 Błędy
• Dodatek: Konwencje zapisu
• A.1 Gramatyka bezkontekstowa
• A.2 Gramatyka leksykalna i syntaktyczna
• A.3 Notacja gramatyczna
• A.4 Semantyka gramatyki
• A.5 Algorytmy
• B Dodatek: Podsumowanie gramatyki
• B.1 Ignorowane żetony
• B.2 Tokeny leksykalne
• B.3 Dokument zapytania

To Twój wybór:

Prosty słodki i krótki dokumentowany Falcor JS VERSUS Ogromne narzędzie klasy korporacyjnej z długą i zaawansowaną dokumentacją, taką jak GraphQL i Relay

Jak powiedziałem wcześniej, jeśli jesteś programistą front-end, który ma pojęcie o używaniu JSON, to implementacja grafów JSON od zespołu Falcor jest najlepszym sposobem na wykonanie projektu deweloperskiego z pełnym stosem.

Krótko mówiąc, Falcor, GraphQL lub Restful rozwiązują ten sam problem - zapewniają narzędzie do efektywnego przeszukiwania danych / manipulowania nimi.

Różnią się tym, jak prezentują swoje dane:

• Falcor chce, abyś traktował ich dane jako bardzo duże wirtualne drzewo JSON i używa get , set i call do odczytu i zapisu danych.
• GraphQL chce, abyś myślał o swoich danych jako o grupie predefiniowanych typów obiektów i używa zapytań i mutacji do odczytu i zapisu danych.
• Restful chce, abyś traktował swoje dane jako grupę zasobów i używa czasowników HTTP do odczytywania i zapisywania danych.

Ilekroć musimy podać dane użytkownikowi, otrzymujemy coś podobnego: klient -> zapytanie -> {warstwa tłumaczy zapytanie na operacje danych} -> dane.

Po zmaganiach z GraphQL, Falcor i JSON API (a nawet ODdata) napisałem własną warstwę zapytań o dane . Jest prostszy, łatwiejszy do nauczenia i bardziej równoważny z GraphQL.

Sprawdź to na:
https://github.com/giapnguyen74/nextql

Integruje się również z featherjs w celu wyszukiwania / mutacji w czasie rzeczywistym. https://github.com/giapnguyen74/nextql-feathers

OK, po prostu zacznij od prostej, ale ważnej różnicy, GraphQL jest oparty na zapytaniach, a Falcor nie!

Ale jak ci pomagają?

Zasadniczo oboje pomagają nam zarządzać danymi i wyszukiwać je, ale GraphQL ma model wymagań / rozdzielczości i zwraca dane jako JSON , w zasadzie idea w GraphQL polega na tym, że ma jedno żądanie, aby uzyskać wszystkie dane w jednym celu ... Ponadto, mają dokładną odpowiedź, mając dokładną prośbę, Więc coś, co działa na wolnym internecie i urządzeniach mobilnych, takich jak sieci 3G ... Więc jeśli masz wielu użytkowników mobilnych lub z jakiegoś powodu, chciałbyś mieć mniej żądań i szybszą odpowiedź użyj GraphQL ... Podczas gdy Faclor nie jest zbyt daleko od tego, więc czytaj dalej ...

Z drugiej strony Falcor firmy Netflix zwykle mają dodatkowe żądanie (zwykle więcej niż raz), aby pobrać wszystkie dane, chociaż próbują ulepszyć je do jednego wymagania ... Falcor jest bardziej ograniczony do zapytań i nie ma -definiowane pomocniki zapytań, takie jak zakres i itp ...

Ale aby uzyskać więcej wyjaśnień, zobaczmy, jak każdy z nich się przedstawia:

GraphQL, język zapytań dla Twojego API

GraphQL to język zapytań dla interfejsów API i środowisko wykonawcze do wypełniania tych zapytań za pomocą istniejących danych. GraphQL zapewnia pełny i zrozumiały opis danych w Twoim API, daje klientom możliwość zadawania dokładnie tego, czego potrzebują i nic więcej, ułatwia ewolucję API w czasie i udostępnia zaawansowane narzędzia programistyczne.

Wyślij zapytanie GraphQL do swojego API i uzyskaj dokładnie to, czego potrzebujesz, nic więcej i nic mniej. Zapytania GraphQL zawsze zwracają przewidywalne wyniki. Aplikacje korzystające z GraphQL są szybkie i stabilne, ponieważ kontrolują otrzymywane dane, a nie serwer.

Zapytania GraphQL mają dostęp nie tylko do właściwości jednego zasobu, ale także płynnie podążają za referencjami między nimi. Podczas gdy typowe interfejsy API REST wymagają ładowania z wielu adresów URL, interfejsy API GraphQL pobierają wszystkie dane potrzebne aplikacji w jednym żądaniu. Aplikacje korzystające z GraphQL mogą być szybkie nawet przy wolnych połączeniach z siecią komórkową.

Interfejsy API GraphQL są zorganizowane pod względem typów i pól, a nie punktów końcowych. Uzyskaj dostęp do wszystkich możliwości swoich danych z jednego punktu końcowego. GraphQL używa typów, aby upewnić się, że aplikacje pytają tylko o to, co jest możliwe, i zapewniają jasne i pomocne błędy. Aplikacje mogą używać typów, aby uniknąć pisania kodu ręcznego analizowania.

Falcor, biblioteka JavaScript do wydajnego pobierania danych

Falcor umożliwia reprezentowanie wszystkich zdalnych źródeł danych jako modelu pojedynczej domeny za pośrednictwem wirtualnego wykresu JSON. Kodujesz w ten sam sposób bez względu na to, gdzie znajdują się dane, czy to w pamięci na kliencie, czy przez sieć na serwerze.

Składnia ścieżek podobna do JavaScript ułatwia dostęp do dowolnej ilości lub tak małej ilości danych, jak chcesz i kiedy chcesz. Pobieranie danych odbywa się za pomocą znanych operacji JavaScript, takich jak pobieranie, ustawianie i wywoływanie. Jeśli znasz swoje dane, znasz swoje API.

Falcor automatycznie przechodzi przez odniesienia na twoim wykresie i wysyła żądania w razie potrzeby. Falcor w przejrzysty sposób obsługuje całą komunikację sieciową, oportunistycznie grupując i usuwając żądania.