अपोलो: 9 महीने - सामान्य उड़ान

सभी को नमस्कार, मेरा नाम शिमोन लेवेन्सन है, मैं रामबलर ग्रुप से स्ट्रीम प्रोजेक्ट पर एक टीम के रूप में काम करता हूं और मैं अपोलो के साथ अपने अनुभव के बारे में बात करना चाहता हूं।

मैं समझाऊंगा कि "स्ट्रीम" क्या है। यह उद्यमियों के लिए एक स्वचालित सेवा है, जो आपको विज्ञापन में शामिल किए बिना ग्राहकों को इंटरनेट से व्यवसाय की ओर आकर्षित करने की अनुमति देती है, और लेआउट में विशेषज्ञ होने के बिना सरल साइटों को जल्दी से बना देती है।

स्क्रीनशॉट लैंडिंग पृष्ठ बनाने के लिए एक चरण दिखाता है।

शुरुआत क्या थी?

और शुरुआत में MVP, बहुत सारे ट्विग, jQuery और बहुत तंग समय सीमाएं थीं। लेकिन हम एक गैर-मानक तरीके से चले गए और एक नया स्वरूप बनाने का फैसला किया। रिडिजाइन "पैचेड स्टाइल" के अर्थ में नहीं है, लेकिन पूरी तरह से सिस्टम की समीक्षा करने का फैसला किया। और यह हमारे लिए एक अच्छा मंच था ताकि हम सही दृश्य को इकट्ठा कर सकें। आखिरकार, हम, विकास टीम, को इस का समर्थन करना जारी रखना चाहिए और इसके आधार पर अन्य कार्यों को लागू करना चाहिए, उत्पाद टीम द्वारा निर्धारित नए लक्ष्यों को प्राप्त करने के लिए।

हमारे विभाग ने पहले ही रिएक्ट का उपयोग करने में पर्याप्त विशेषज्ञता अर्जित कर ली है। मैं वेबपैक स्थापित करने में 2 सप्ताह खर्च नहीं करना चाहता था, इसलिए मैंने CRA (क्रिएट रिएक्ट ऐप) का उपयोग करने का निर्णय लिया। शैलियों के लिए स्टाइलिंग घटक लिया गया था, और जहां टाइपिंग के बिना - उन्होंने फ्लो लिया। उन्होंने राज्य प्रबंधन के लिए Redux लिया, लेकिन परिणामस्वरूप यह निकला कि हमें इसकी बिल्कुल भी आवश्यकता नहीं है, लेकिन बाद में इस पर और अधिक।

हमने एक साथ अपने संपूर्ण दृश्य को सामने रखा और महसूस किया कि हम कुछ भूल गए हैं। जैसा कि यह निकला, हम बैकएंड या इसके साथ बातचीत के बारे में भूल गए। जब आपने सोचा कि इस बातचीत को व्यवस्थित करने के लिए हम क्या उपयोग कर सकते हैं, पहली बात जो दिमाग में आई - बेशक, रेस्ट है। नहीं, हम आराम करने (मुस्कुराने) नहीं गए, लेकिन Restful API के बारे में बात करने लगे। सिद्धांत रूप में, कहानी परिचित है, लंबे समय तक फैलती है, लेकिन हम इसके साथ समस्याओं के बारे में भी जानते हैं। हम उनके बारे में बात करेंगे

पहली समस्या प्रलेखन है। बेशक, यह नहीं कहता है कि प्रलेखन को कैसे व्यवस्थित किया जाए। यहां एक ही स्वैगर का उपयोग करने का विकल्प है, लेकिन वास्तव में यह एक अतिरिक्त इकाई और प्रक्रियाओं की जटिलता का परिचय है।

दूसरी समस्या यह है कि एपीआई के संस्करण के लिए समर्थन को कैसे व्यवस्थित किया जाए।

तीसरा महत्वपूर्ण मुद्दा बड़ी संख्या में प्रश्न या कस्टम समापन बिंदु हैं जिन्हें हम पुरस्कृत कर सकते हैं। मान लीजिए हमें इन पदों के लिए - टिप्पणियों और इन टिप्पणियों के अधिक लेखकों के लिए पदों का अनुरोध करने की आवश्यकता है। क्लासिक रेस्ट में, हमें कम से कम 3 प्रश्न करने होंगे। हां, हम कस्टम समापन बिंदुओं को पुरस्कृत कर सकते हैं, और यह सब 1 अनुरोध तक कम किया जा सकता है, लेकिन यह पहले से ही एक जटिलता है।

चित्रण के लिए साशको स्टूबाइलो को धन्यवाद ।

निर्णय

और इस समय, फेसबुक ग्राफक्यूएल के साथ हमारी सहायता के लिए आता है। GraphQL क्या है? यह एक मंच है, लेकिन आज हम इसके एक हिस्से पर गौर करेंगे - यह आपके एपीआई के लिए क्वेरी भाषा है, बस एक भाषा है, और काफी आदिम है। और यह जितना संभव हो उतना सरल काम करता है - जैसा कि हम किसी प्रकार की संस्था से अनुरोध करते हैं, हम भी इसे प्राप्त करते हैं।

प्रश्न:

{ me { id isAcceptedFreeOffer balance } } 

उत्तर है:

 { "me": { "id": 1, "isAcceptedFreeOffer": false, "balance": 100000 } } 

लेकिन GraphQL केवल पढ़ने के बारे में नहीं है, यह डेटा बदलने के बारे में भी है। ऐसा करने के लिए, ग्राफ़िकल में म्यूटेशन हैं। म्यूटेशन उल्लेखनीय हैं कि हम एक सफल बदलाव के साथ बैकएंड से वांछित प्रतिक्रिया की घोषणा कर सकते हैं। हालांकि, कुछ बारीकियां हैं। उदाहरण के लिए, यदि हमारा उत्परिवर्तन ग्राफ की सीमा के बाहर डेटा को प्रभावित करता है।

एक उत्परिवर्तन का एक उदाहरण जिसमें हम एक मुफ्त प्रस्ताव का उपयोग करते हैं:

 mutation { acceptOffer (_type: FREE) { id isAcceptedFreeOffer } } 

जवाब में, हमें वही संरचना मिलती है जो अनुरोध की गई थी

 { "acceptOffer": { "id": 1, "isAcceptedFreeOffer": true } } 

ग्राफिंक बैकएंड के साथ इंटरेक्शन नियमित रूप से लाने के लिए किया जा सकता है।

 fetch('/graphql', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ query: '{me { id balance } }' }) }); 

GraphQL के फायदे क्या हैं?

जब आप इसके साथ काम करना शुरू करते हैं, तो इसकी सराहना की जा सकने वाली पहली और बहुत ही अच्छी बात यह है कि यह भाषा दृढ़ता से टाइप की जाती है और स्व-दस्तावेज होती है। सर्वर पर GraphQL स्कीमा डिजाइन करके, हम तुरंत कोड में सीधे प्रकार और विशेषताओं का वर्णन कर सकते हैं।

जैसा कि ऊपर बताया गया है, रेस्टफुल में एक संस्करण समस्या है। रेखांकन ने इसके लिए एक बहुत ही सुंदर समाधान लागू किया - पदावनत।

मान लीजिए हमारे पास एक फिल्म है, हम इसका विस्तार करते हैं, इसलिए हमारे पास एक निर्देशक है। और कुछ बिंदु पर हम निर्देशक को एक अलग प्रकार बनाते हैं। सवाल यह है कि आखिरी डायरेक्टर फील्ड का क्या करें? इसके दो उत्तर हैं: या तो हम इस क्षेत्र को हटा देते हैं, या हम इसे पदावनत कर देते हैं, और यह स्वतः ही दस्तावेज से गायब हो जाता है।

हम स्वतंत्र रूप से तय करते हैं कि हमें क्या चाहिए।

हम पिछली तस्वीर को याद करते हैं, जहां सब कुछ आरईएसटी के साथ चला गया, यहां हमारे पास सब कुछ एक अनुरोध में संयुक्त है और बैकएंड विकास से किसी भी अनुकूलन की आवश्यकता नहीं है। एक बार जब वे सभी इसे वर्णित करते हैं, और हम ट्विस्ट, ट्विस्ट, करतब दिखाते हैं।

लेकिन मरहम में एक मक्खी के बिना नहीं। सिद्धांत रूप में, दृश्यपटल पर GraphQL के लिए बहुत सारी कमियां नहीं हैं, क्योंकि यह मूल रूप से फ्रंटेंड समस्याओं को हल करने के लिए विकसित किया गया था। लेकिन बैकेंड इतनी आसानी से नहीं जा रहा है ... उन्हें एन + 1 जैसी समस्या है। उदाहरण के रूप में क्वेरी लें:

 { landings(_page: 0, limit: 20) { nodes { id title } totalCount } } 

एक सरल अनुरोध, हम 20 साइटों और हमारे पास मौजूद साइटों की संख्या का अनुरोध करते हैं। और बैकएंड में, यह 21 डेटाबेस प्रश्नों में बदल सकता है। यह समस्या ज्ञात है, हल है। नोड जेएस के लिए फेसबुक से एक dataloader पैकेज है। अन्य भाषाओं के लिए, आप अपने स्वयं के समाधान पा सकते हैं।

गहरी नेस्टिंग की समस्या भी है। उदाहरण के लिए, हमारे पास एल्बम हैं, इन एल्बमों में गाने हैं, और गीत के माध्यम से हम एल्बम भी प्राप्त कर सकते हैं। ऐसा करने के लिए, निम्नलिखित प्रश्न करें:

 { album(id: 42) { songs { title artists } } } 

 { song(id: 1337) { title album { title } } } 

इस प्रकार, हमें एक पुनरावर्ती क्वेरी मिलती है, जो हमें प्राथमिक रूप से एक आधार देती है।

 query evil { album(id: 42) { songs { album { songs { album { 

इस समस्या को भी जाना जाता है, नोड जेएस के लिए समाधान ग्राफक्यूएल गहराई सीमा है, अन्य भाषाओं के लिए भी समाधान हैं।

इस प्रकार, हमने ग्राफक्यूएल पर फैसला किया। यह एक पुस्तकालय चुनने का समय है जो ग्राफकॉल एपीआई के साथ काम करेगा। भ्रूण के साथ कुछ पंक्तियों में उदाहरण, जो ऊपर दिखाया गया है, केवल एक परिवहन है। लेकिन योजना और घोषणा के लिए धन्यवाद, हम सामने वाले प्रश्नों को कैश भी कर सकते हैं, और ग्राफकॉल बैकएंड के साथ अधिक से अधिक प्रदर्शन के साथ काम कर सकते हैं।

इसलिए हमारे दो मुख्य खिलाड़ी हैं- रिले और अपोलो।

रिले

रिले एक फेसबुक डेवलपमेंट है, वे इसका इस्तेमाल खुद करते हैं। जैसे ओकुलस, सर्कल सीआई, आरती और शुक्रवार।

रिले के पेशेवरों क्या हैं?

तत्काल प्लस यह है कि डेवलपर फेसबुक है। रिएक्ट, फ्लो और ग्राफकॉक फेसबुक के घटनाक्रम हैं, जिनमें से सभी एक दूसरे के अनुरूप पहेली हैं। हम गितुब पर सितारों के बिना कहां हैं, रिले के पास लगभग 11,000 हैं, अपोलो के पास तुलना के लिए 7600 हैं। रिले में जो ठंडी चीज है वह रिले-कंपाइलर है, एक उपकरण जो आपके प्रोजेक्ट के बिल्ड स्तर पर आपके ग्राफकॉल प्रश्नों का अनुकूलन और विश्लेषण करता है। । हम यह मान सकते हैं कि यह केवल रेखांकन के लिए ही है:

 #  Relay-compiler foo { # type FooType id ... on FooType { # matches the parent type, so this is extraneous id } } #  foo { id } 

रिले के विचार क्या हैं?

पहला माइनस * बॉक्स से बाहर SSR की कमी है। गितुब अभी भी एक मुद्दा खुला है। तारांकन के तहत क्यों - क्योंकि पहले से ही समाधान हैं, लेकिन वे तीसरे पक्ष के हैं, और इसके अलावा, काफी अस्पष्ट हैं।

फिर से, रिले एक विनिर्देशन है। तथ्य यह है कि ग्राफकॉल पहले से ही एक विनिर्देश है, और रिले एक विनिर्देशन पर एक विनिर्देश है।

उदाहरण के लिए, रिले पेजेशन को अलग तरह से लागू किया जाता है, यहाँ पर श्रापकर्ता दिखाई देते हैं।

 { friends(first: 10, after: "opaqueCursor") { edges { cursor node { id name } } pageInfo { hasNextPage } } } 

हम अब सामान्य ऑफ़सेट्स और सीमाओं का उपयोग नहीं करते हैं। फ़ीड में फ़ीड के लिए, यह एक महान विषय है, लेकिन जब हम सभी प्रकार के ग्रिड करना शुरू करते हैं, तो दर्द होता है।

फेसबुक ने रिएक्ट के लिए एक लाइब्रेरी लिखकर अपनी समस्या हल की। अन्य पुस्तकालयों के लिए समाधान हैं, उदाहरण के लिए- vue-relay । लेकिन अगर हम सितारों की संख्या और कमिट-एस पर ध्यान देते हैं, तो यहां भी, सब कुछ इतना सहज नहीं है और अस्थिर हो सकता है। उदाहरण के लिए, CRA बॉक्स के बाहर रिएक्ट ऐप बनाएं आपको रिले-कंपाइलर का उपयोग करने से रोकता है। लेकिन आप इस सीमा के आसपास प्रतिक्रिया-ऐप-rewired के साथ प्राप्त कर सकते हैं।

अपोलो

हमारा दूसरा उम्मीदवार अपोलो है । उनकी टीम उल्का द्वारा विकसित की गई। अपोलो इस तरह के प्रसिद्ध कमांड का उपयोग करते हैं जैसे: AirBnB, टिकटमास्टर, ओपनेंटेबल, आदि।

अपोलो के फायदे क्या हैं?

पहला महत्वपूर्ण प्लस यह है कि अपोलो को एक रूपरेखा अज्ञेय पुस्तकालय के रूप में विकसित किया गया था। उदाहरण के लिए, यदि हम अब कोणीय पर सब कुछ फिर से लिखना चाहते हैं, तो यह एक समस्या नहीं होगी, अपोलो इसके साथ काम करता है। और आप सब कुछ वेनिला में भी लिख सकते हैं।

अपोलो के पास शांत दस्तावेज हैं, सामान्य समस्याओं के लिए तैयार समाधान हैं।

एक और प्लस अपोलो - एक शक्तिशाली एपीआई। सिद्धांत रूप में, Redux के साथ काम करने वालों को यहां आम दृष्टिकोण मिलेंगे: ApolloProvider (जैसे Redux के लिए प्रोवॉक्स) है, और अपोलो के लिए स्टोर के बजाय इसे क्लाइंट कहा जाता है:

 import { ApolloProvider } from 'react-apollo'; import { ApolloClient } from './ApolloClient'; const App = () => ( <ApolloProvider client={ApolloClient}> ... </ApolloProvider> ); 

घटक के स्तर पर, हमारे पास कनेक्ट के रूप में ग्राफिकल एचओसी है। और हम Redux में MapStateToProps की तरह पहले से ही अंदर ग्राफ़िकल क्वेरी लिखते हैं।

 import { graphql } from 'react-apollo'; import gql from 'graphql-tag'; import { Landing } from './Landing'; graphql(gql` { landing(id: 1) { id title } } `)(Landing); 

लेकिन जब हम Redux में MapStateToProps करते हैं, तो हम स्थानीय डेटा उठाते हैं। यदि कोई स्थानीय डेटा नहीं है, तो अपोलो स्वयं उनके लिए सर्वर पर जाता है। बहुत सुविधाजनक प्रॉप्स घटक में ही गिर जाते हैं।

 function Landing({ data, loading, error, refetch, ...other }) { ... } 

यह है:
• डेटा;
• डाउनलोड स्थिति;
• यदि यह हुआ तो एक त्रुटि;
हेलिकॉप्टर जैसे कार्य फिर से लोड करने के लिए डेटा या fetchMore paginate करने के लिए। अपोलो और रिले दोनों के लिए एक विशाल प्लस भी है, जो कि ऑप्टिमिस्टिक यूआई है। यह आपको अनुरोध स्तर पर पूर्ववत / फिर से करने की अनुमति देता है:

 this.props.setNotificationStatusMutation({ variables: { … }, optimisticResponse: { … } }); 

उदाहरण के लिए, उपयोगकर्ता "लाइक" बटन पर क्लिक करता है, और "लाइक" तुरंत गिना जाता है। इस मामले में, पृष्ठभूमि में एक सर्वर अनुरोध भेजा जाएगा। यदि भेजने की प्रक्रिया के दौरान कुछ त्रुटि होती है, तो उत्परिवर्तित डेटा अपने आप ही मूल स्थिति में वापस आ जाएगा।

सर्वर साइड रेंडरिंग को अच्छी तरह से लागू किया गया है, हम क्लाइंट पर एक ध्वज सेट करते हैं और सब कुछ तैयार है।

 new ApolloClient({ ssrMode: true, ... }); 

लेकिन यहां मैं प्रारंभिक अवस्था के बारे में बात करना चाहूंगा। जब अपोलो इसे खुद के लिए पकाते हैं, तो सब कुछ अच्छी तरह से काम करता है।

 <script> window.__APOLLO_STATE__ = client.extract(); </script> const client = new ApolloClient({ cache: new InMemoryCache().restore(window.__APOLLO_STATE__), link }); 

लेकिन हमारे पास सर्वर साइड रेंडरिंग नहीं है, और बैकएंड एक विशिष्ट ग्राफक्यूएल क्वेरी को वैश्विक चर में धकेलता है। यहां आपको एक छोटी बैसाखी की आवश्यकता है, आपको एक ट्रांसफ़ॉर्म फ़ंक्शन लिखने की ज़रूरत है कि बैकएंड से ग्राफक्यूएल प्रतिक्रिया पहले से ही अपोलो के लिए आवश्यक प्रारूप में बदल जाएगी।

 <script> window.__APOLLO_STATE__ = transform({…}); </script> const client = new ApolloClient({ cache: new InMemoryCache().restore(window.__APOLLO_STATE__), link }); 

अपोलो का एक और प्लस यह है कि यह अच्छी तरह से अनुकूलन योग्य है। हम सभी Redux से मिडलवेयर को याद करते हैं, यहां सब कुछ समान है, केवल इसे लिंक कहा जाता है।

मैं अलग से दो लिंक नोट करना चाहूंगा: अपोलो-लिंक-स्टेट , जिसे Redux की अनुपस्थिति में स्थानीय स्थिति को संग्रहीत करने की आवश्यकता है, और अपोलो-लिंक-रेस्ट , यदि हम ग्राफ एपीआई को रेस्ट एपीआई पर लिखना चाहते हैं। हालांकि, बाद वाले के साथ आपको बेहद सावधान रहने की जरूरत है, क्योंकि कुछ समस्याएं उत्पन्न हो सकती हैं।

अपोलो में भी विपक्ष है

आइए एक उदाहरण देखें। एक अप्रत्याशित प्रदर्शन समस्या थी: सीमा पर 2,000 वस्तुओं का अनुरोध किया गया था (यह एक निर्देशिका थी), और प्रदर्शन समस्याएं शुरू हुईं। डिबगर में इसे देखने के बाद, यह पता चला कि अपोलो पढ़ने के दौरान बहुत सारे संसाधनों को खा जाता है, मुद्दा मूल रूप से बंद है, अब सब कुछ ठीक है, लेकिन ऐसा एक पाप था।

इसके अलावा, refetch बहुत ही अविश्वासी निकला ...

 function Landing({ loading, refetch, ...other }) { ... } 

ऐसा लगता है कि जब हम डेटा रि-रिक्वेस्ट करते हैं, तो इसके अलावा, यदि पिछला अनुरोध एक त्रुटि के साथ समाप्त हो जाता है, तो लोडिंग सही हो जाना चाहिए। लेकिन नहीं!

ऐसा होने के लिए, आपको InformOnNetworkStatusChange को निर्दिष्ट करने की आवश्यकता है: ग्राफिकल एचओसी में सही है, या स्थानीय स्तर पर रीफेक स्टेट को संग्रहीत करें।

अपोलो बनाम। रिले

इस प्रकार, हमें ऐसी तालिका मिली, हम सभी का वजन, गिना गया, और अपोलो के पीछे हमारा 76% था।

इसलिए हमने लाइब्रेरी को चुना और काम पर चले गए।

लेकिन मैं टूलकिन के बारे में और अधिक कहना चाहूंगा।

यहां सब कुछ बहुत अच्छा है, संपादकों के लिए विभिन्न ऐड-ऑन हैं, कहीं बेहतर, कहीं बदतर। अपोलो-कोडगेन भी है, जो उपयोगी फ़ाइलों को उत्पन्न करता है, उदाहरण के लिए, प्रवाह-प्रकार, और मूल रूप से ग्राफक्यूएल एपीआई से स्कीमा को खींचता है।

शीर्षक "पागल हाथ" या हमने घर पर क्या किया

पहली बात यह थी कि हमें मूल रूप से डेटा का अनुरोध करने की आवश्यकता थी।

 graphql(BalanceQuery)(BalanceItem); 

हमारे पास सामान्य स्थितियां हैं: लोडिंग, त्रुटि से निपटने। हमने अपना स्वयं का हौज (asyncCard) लिखा है, जो graqhql और asyncCard की संरचना के माध्यम से जुड़ा हुआ है।

 compose( graphql(BalanceQuery), AsyncCard )(BalanceItem); 

मैं अंशों के बारे में भी बात करना चाहूंगा। एक LandingItem घटक है और यह जानता है कि ग्राफकॉल एपीआई से इसे किस डेटा की आवश्यकता है। हमने खंड की संपत्ति निर्धारित की, जहां हमने लैंडिंग इकाई से फ़ील्ड निर्दिष्ट किए।

 const LandingItem = ({ content }: Props) => ( <LandingItemStyle> … </LandingItemStyle> ); LandingItem.fragment = gql` fragment LandingItem on Landing { ... } `; 

अब, घटक उपयोग स्तर पर, हम अंतिम अनुरोध में इसके टुकड़े का उपयोग करते हैं।

 query LandingsDashboard { landings(...) { nodes { ...LandingItem } totalCount } ${LandingItem.Fragment} } 

और मान लें कि इस लैंडिंग पृष्ठ पर स्थिति जोड़ने के लिए कोई कार्य उड़ान भरता है - कोई समस्या नहीं है। हम रेंडर और टुकड़े में एक संपत्ति जोड़ते हैं। और सब कुछ तैयार है। सभी महिमा में एकल जिम्मेदारी सिद्धांत।

 const LandingItem = ({ content }: Props) => ( <LandingItemStyle> … <LandingItemStatus … /> </LandingItemStyle> ); LandingItem.fragment = gql` fragment LandingItem on Landing { ... status } `; 

हमें और क्या समस्या थी?

हमारी साइट पर हमारे कई विजेट हैं, जिन्होंने उनके व्यक्तिगत अनुरोध किए।

परीक्षण के दौरान, यह पता चला कि यह सब धीमा हो जाता है। हमारे पास बहुत लंबी सुरक्षा जांच है, और प्रत्येक अनुरोध बहुत महंगा है। यह भी कोई समस्या नहीं है, अपोलो-लिंक-बैच-http है

 new BatchHttpLink({ batchMax: 10, batchInterval: 10 }); 

इसे निम्नानुसार कॉन्फ़िगर किया गया है: हम उन अनुरोधों की संख्या को पास करते हैं जिन्हें हम संयोजित कर सकते हैं और यह लिंक पहले अनुरोध के प्रकट होने के बाद कितनी देर तक प्रतीक्षा करेगा।
और यह इस तरह निकला: एक ही समय में सब कुछ लोड होता है, और एक ही समय में सब कुछ आता है। यह ध्यान देने योग्य है कि यदि इस विलय के दौरान कोई भी उपश्रेणी एक त्रुटि के साथ लौटती है, तो त्रुटि केवल उसके साथ होगी, और पूरे अनुरोध के साथ नहीं।

मैं अलग से बताना चाहूंगा कि आखिरी गिरावट पहले अपोलो से दूसरे तक एक अद्यतन थी

शुरुआत में अपोलो और रेडक्स थे

 'react-apollo' 'redux' 

फिर अपोलो अधिक मॉड्यूलर और विस्तार योग्य बन गया, इन मॉड्यूल को स्वतंत्र रूप से विकसित किया जा सकता है। वही अपोलो-कैश-इनमोरी।

 'react-apollo' 'apollo-client' 'apollo-link-batch-http' 'apollo-cache-inmemory' 'graphql-tag' ' 'react-apollo' 'apollo-client' 'apollo-link-batch-http' 'apollo-cache-inmemory' 'graphql-tag' 

यह ध्यान देने योग्य है कि Redux नहीं है, और जैसा कि यह निकला, यह सिद्धांत रूप में, आवश्यक नहीं है।

निष्कर्ष:

1. सुविधा-वितरण का समय कम हो गया है, हम कार्रवाई का वर्णन करने में समय बर्बाद नहीं करते हैं, Redux में कम करते हैं, और बैकएंड को कम स्पर्श करते हैं
2. एंटीफ्रेगैलिटी दिखाई दी क्योंकि एपीआई का स्थैतिक विश्लेषण आपको उन समस्याओं को कम करने की अनुमति देता है जब फ्रंटएंड एक चीज की उम्मीद करता है और बैकेंड पूरी तरह से अलग होता है।
3. यदि आप ग्राफकॉल के साथ काम करना शुरू करते हैं - अपोलो का प्रयास करें, निराश न हों।

PS आप रामबलर फ्रंट और मीट # 4 पर मेरी प्रस्तुति से एक वीडियो भी देख सकते हैं