Falcor และ GraphQL แตกต่างกันอย่างไร?

GraphQL ประกอบด้วยระบบประเภทภาษาคิวรีและซีแมนทิกส์การประมวลผลการตรวจสอบแบบคงที่และการใช้วิปัสสนาประเภทซึ่งแต่ละด้านล่างนี้ เพื่อแนะนำคุณเกี่ยวกับองค์ประกอบเหล่านี้เราได้เขียนตัวอย่างที่ออกแบบมาเพื่อแสดงให้เห็นถึงส่วนต่างๆของ GraphQL

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

Falcor ช่วยให้คุณแสดงแหล่งข้อมูลระยะไกลทั้งหมดของคุณเป็นรูปแบบโดเมนเดียวผ่านกราฟ JSON เสมือน คุณใช้รหัสในลักษณะเดียวกันไม่ว่าข้อมูลจะอยู่ในหน่วยความจำบนไคลเอนต์หรือบนเครือข่ายบนเซิร์ฟเวอร์

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

Falcor และ GraphQL แตกต่างกันอย่างไร (ในบริบทของ Relay)

ฉันเคยดูAngular Air Episode 26: FalcorJS และ Angular 2ที่Jafar Husainตอบว่าGraphQLเปรียบเทียบกับFalcorJSอย่างไร นี่คือบทสรุป (การถอดความ):

• FalcorJS และ GraphQL กำลังแก้ปัญหาเดียวกัน (การสอบถามข้อมูลการจัดการข้อมูล)
• ความแตกต่างที่สำคัญคือ GraphQL เป็นภาษาแบบสอบถามและ FalcorJS ไม่ใช่
• เมื่อคุณถาม FalcorJS เกี่ยวกับทรัพยากรคุณจะขอชุดค่าที่แน่นอนอย่างชัดเจน FalcorJS genres[0..10]ไม่สนับสนุนสิ่งที่ต้องการช่วงเช่น genres[0..*]แต่ก็ไม่ได้สนับสนุนแบบสอบถามปลายเปิดเช่น
• GraphQL ตั้งตาม: ให้เร็กคอร์ดทั้งหมดที่เป็นจริงเรียงลำดับตามนี้เป็นต้นในแง่นี้ภาษาคิวรีของ GraphQL นั้นมีประสิทธิภาพมากกว่า FalcorJS
• ด้วย GraphQL คุณมีภาษาคิวรีที่ทรงพลัง แต่คุณต้องตีความภาษาคิวรีนั้นบนเซิร์ฟเวอร์

Jafar ให้เหตุผลว่าในการใช้งานส่วนใหญ่ประเภทของแบบสอบถามที่ไปจากลูกค้าไปยังเซิร์ฟเวอร์แบ่งปันรูปร่างเดียวกัน ดังนั้นการมีการดำเนินงานที่เฉพาะเจาะจงและคาดการณ์ได้เช่นรับและตั้งค่าจะทำให้มีโอกาสมากขึ้นในการใช้ประโยชน์จากแคช นอกจากนี้นักพัฒนาจำนวนมากคุ้นเคยกับการแมปคำขอโดยใช้เราเตอร์แบบง่ายในสถาปัตยกรรม REST

การอภิปรายจบลงจะช่วยแก้ไขว่าพลังที่มาพร้อมกับ GraphQL นั้นมีค่ามากกว่าความซับซ้อนหรือไม่

ตอนนี้ฉันได้เขียนแอพที่มีทั้งห้องสมุดและฉันสามารถเห็นด้วยกับทุกสิ่งในโพสต์ของ Gajus แต่พบสิ่งที่แตกต่างที่สำคัญที่สุดในการใช้งานเฟรมเวิร์กของตัวเอง

• ความแตกต่างในทางปฏิบัติที่ใหญ่ที่สุดน่าจะเป็นตัวอย่างส่วนใหญ่และการทำงานที่น่าจะเป็นไปได้จนถึงจุดนี้บน GraphQL นั้นได้เน้นที่การรวม GraphQL เข้ากับ Relay - ระบบของ Facebook สำหรับการรวมวิดเจ็ต ReactJS เข้ากับความต้องการข้อมูล FalcorJS ในทางกลับกันมีแนวโน้มที่จะแยกจากระบบวิดเจ็ตซึ่งหมายความว่าทั้งสองอย่างนั้นอาจจะง่ายกว่าที่จะรวมเข้ากับไคลเอนต์ที่ไม่ทำปฏิกิริยา / รีเลย์และมันจะทำให้คุณโดยอัตโนมัติน้อยลงในแง่ของการจับคู่
• ด้านพลิกของ FalcorJS มีความยืดหยุ่นในการรวมฝั่งไคลเอ็นต์คือมันสามารถให้ความเห็นอย่างมากเกี่ยวกับวิธีที่เซิร์ฟเวอร์ต้องการดำเนินการ FalcorJS มีความสามารถ "Call this Query over HTTP" โดยตรง - แม้ว่า Jafar Husain จะไม่พูดถึงมันมากนัก - และเมื่อคุณรวมสิ่งเหล่านี้แล้ววิธีการที่ไลบรารีไคลเอ็นต์ตอบสนองต่อข้อมูลเซิร์ฟเวอร์จะค่อนข้างคล้ายคลึงกันยกเว้นว่า GraphQL / Relay เพิ่มเลเยอร์การกำหนดค่า ใน FalcorJS ถ้าคุณส่งคืนค่าสำหรับภาพยนตร์ค่าส่งคืนของคุณจะดีกว่าว่า 'movie' ในขณะที่ GraphQL คุณสามารถอธิบายได้ว่าแม้ว่าเคียวรีจะส่งคืน 'film' คุณควรใส่ข้อมูลนั้นลงในฝั่งไคลเอ็นต์เป็น 'ภาพยนตร์ ' - นี่เป็นส่วนหนึ่งของพลังและความซับซ้อนที่กาก้าพูดถึง
• ในทางปฏิบัติ GraphQL และ Relay ดูเหมือนว่าจะมีการพัฒนามากขึ้น Jafar Husain ได้กล่าวว่าส่วนต่อไปของ Netflix จะทำงานอย่างน้อยใน FalcorJS ในขณะที่ทีม Facebook ได้กล่าวว่าพวกเขาใช้ GraphQL / Relay stack มานานกว่า 3 ปีแล้ว
• ชุมชนนักพัฒนาซอฟต์แวร์โอเพนซอร์ซรอบ ๆ GraphQL และรีเลย์ดูเหมือนว่าจะเจริญรุ่งเรือง มีโครงการสนับสนุนที่มีผู้เข้าร่วมจำนวนมากรอบ ๆ GraphQL และ Relay ในขณะที่ฉันได้พบเพียงเล็กน้อยจาก FalcorJS นอกจากนี้ที่เก็บ github ฐานสำหรับ Relay ( https://github.com/facebook/relay/pulse ) มีความสำคัญมากกว่าที่เก็บ github สำหรับ FalcorJS ( https://github.com/netflix/falcor/pulse ) เมื่อฉันดึง repo Facebook ครั้งแรกตัวอย่างก็พัง ฉันเปิดปัญหา GitHub และได้รับการแก้ไขภายในไม่กี่ชั่วโมง ในทางตรงกันข้ามปัญหา GitHub ที่ฉันเปิดใน FalcorJS นั้นไม่มีการตอบสนองอย่างเป็นทางการในสองสัปดาห์

Lee Byronหนึ่งในวิศวกรที่อยู่เบื้องหลัง GraphQL ทำAMA ใน hashnodeนี่คือคำตอบของเขาเมื่อถูกถามคำถามนี้:

• Falcor ส่งคืน Observables, GraphQL เพียงแค่ค่า สำหรับวิธีที่ Netflix ต้องการใช้ Falcor สิ่งนี้สมเหตุสมผลมากสำหรับพวกเขา พวกเขาร้องขอหลายครั้งและนำเสนอข้อมูลตามที่พร้อม แต่ก็หมายความว่าผู้พัฒนาไคลเอ็นต์จะต้องทำงานกับ Observables โดยตรง GraphQL เป็นรูปแบบคำขอ / ตอบกลับและคืนกลับ JSON ซึ่งง่ายต่อการใช้งานเล็กน้อย การถ่ายทอดเพิ่มกลับในบางส่วนของการเคลื่อนไหวแบบไดนามิกที่ Falcor นำเสนอในขณะที่รักษาเพียงใช้ค่าธรรมดา
• พิมพ์ระบบ GraphQL ถูกกำหนดในรูปแบบของระบบและนั่นทำให้เราสามารถสร้างเครื่องมือที่น่าสนใจมากมายเช่น GraphiQL, ตัวสร้างโค้ด, การตรวจจับข้อผิดพลาดและอื่น ๆ Falcor นั้นมีพลวัตมากขึ้นซึ่งมีคุณค่าในตัวของมันเอง แต่จำกัดความสามารถ สิ่งนี้
• การใช้เครือข่าย เดิมที GraphQL ได้รับการออกแบบมาสำหรับการใช้งานฟีดข่าวของ Facebook บนอุปกรณ์ระดับล่างในเครือข่ายที่ต่ำกว่าดังนั้นจึงมีความยาวที่ยอดเยี่ยมเพื่อให้คุณประกาศทุกสิ่งที่คุณต้องการในการร้องขอเครือข่ายเดียวเพื่อลดเวลาแฝง ในทางกลับกัน Falcor มักจะทำการเดินทางไปกลับหลายครั้งเพื่อรวบรวมข้อมูลเพิ่มเติม นี่เป็นเพียงการแลกเปลี่ยนระหว่างความเรียบง่ายของระบบและการควบคุมเครือข่าย สำหรับ Netflix พวกเขายังจัดการกับอุปกรณ์ระดับต่ำสุด (เช่น Roku Stick) แต่สมมติฐานก็คือเครือข่ายจะดีพอที่จะสตรีมวิดีโอ

แก้ไข: ฟัลคอร์สามารถส่งคำขอเป็นชุดแน่นอนทำให้ความคิดเห็นเกี่ยวกับการใช้งานเครือข่ายไม่ถูกต้อง ขอบคุณ @PrzeoR

อัปเดต: ฉันพบความคิดเห็นที่มีประโยชน์มากภายใต้โพสต์ของฉันที่ฉันต้องการแบ่งปันกับคุณเพื่อเป็นเนื้อหาเสริมในเนื้อหาหลัก:

เกี่ยวกับการไม่มีตัวอย่างคุณสามารถค้นหา repo userful ที่ยอดเยี่ยมมีตัวอย่างที่แตกต่างกันของการใช้งาน CRUD ของ Falcor: https://github.com/przeor/awesome-falcorjs ... สิ่งที่สองมีหนังสือชื่อ " Mastering Full Stack React Development "ซึ่งรวมถึง Falcor ด้วย (วิธีที่ดีในการเรียนรู้วิธีใช้งาน):

โพสต์ดั้งเดิมด้านล่าง:

FalcorJS ( https://www.facebook.com/groups/falcorjs/ ) นั้นง่ายกว่ามากในการเปรียบเทียบกับ Relay / GraphQL

กราฟการเรียนรู้สำหรับ GraphQL + Relay มีขนาดใหญ่มาก:

ในบทสรุปสั้น ๆ ของฉัน: ไปหาฟัลคอร์ ใช้ Falcor ในโครงการต่อไปของคุณจนกว่าคุณจะมีงบประมาณจำนวนมากและมีเวลาเรียนรู้มากมายสำหรับทีมของคุณจากนั้นใช้ RELAY + GRAPHQL

GraphQL + Relay มี API ขนาดใหญ่ที่คุณต้องมีประสิทธิภาพ Falcor มี API ขนาดเล็กและง่ายต่อการเข้าใจกับนักพัฒนาส่วนหน้าที่คุ้นเคยกับ JSON

หากคุณมีโครงการ AGILE ที่มีทรัพยากร จำกัด -> ไปที่ FalcorJS!

ความคิดเห็นของฉัน: FalcorJS คือ 500% + ง่ายต่อการมีประสิทธิภาพในจาวาสคริปต์แบบเต็มสแต็ก

ฉันได้เผยแพร่ FalcorJS starter kit บางตัวในโครงการของฉันด้วย (+ ตัวอย่างโปรเจ็กต์ Falcor แบบเต็มกองเพิ่มเติม): https://www.github.com/przeor

จะมีมากขึ้นในรายละเอียดทางเทคนิค:

1) เมื่อคุณใช้ Falcor คุณสามารถใช้ทั้ง front-end และ backend:

นำเข้า falcor จาก 'falcor';

จากนั้นสร้างโมเดลของคุณตาม

... คุณต้องมีสองไลบรารีซึ่งง่ายต่อการใช้กับแบ็กเอนด์: a) falcor-express - คุณใช้เพียงครั้งเดียว (เช่นapp.use ('/ model.json', FalcorServer.dataSourceRoute (() =>) NamesRouter ใหม่ ())) ) ที่มา: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

b) falcor-router - คุณกำหนดเส้นทาง SIMPLE (เช่นเส้นทาง: '_view.length' ) ที่มา: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

ฟัลคอร์เป็นชิ้นส่วนของเค้กในแง่ของการเรียนรู้โค้ง

คุณสามารถดูเอกสารที่ง่ายกว่าของ FB และอ่านบทความ " ทำไมคุณควรใส่ใจ falcorjs (netflix falcor) "

2) รีเลย์ / GraphQL นั้นมีแนวโน้มที่จะเป็นเครื่องมือระดับองค์กรขนาดใหญ่

ตัวอย่างเช่นคุณมีเอกสารสองแบบที่ต่างกันซึ่งแยกกันพูดถึง:

a) รีเลย์: https://facebook.github.io/relay/docs/tutorial.html - ภาชนะบรรจุ - เส้นทาง - รูทคอนเทนเนอร์ - สถานะพร้อม - การกลายพันธุ์ - เครือข่ายเลเยอร์ - ปลั๊กอินรีเลย์ Babel - GRAPHQL

• สเปครีเลย์ของ GraphQL
• การระบุวัตถุ
• สัมพันธ์
• การกลายพันธุ์
• อ่านเพิ่มเติม

• API อ้างอิง

• ถ่ายทอด

• RelayContainer
• Relay.Route
• Relay.RootContainer
• Relay.QL
• Relay.Mutation
• Relay.PropTypes
• Relay.Store

• INTERFACES

• RelayNetworkLayer

• RelayMutationRequest
• RelayQueryRequest

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

• 2Language
• 2.1 แหล่งข้อความ
• 2.1.1Unicode
• 2.1.2 พื้นที่สีขาว
• 2.1.3Line Terminators
• 2.1.4Comments
• 2.1.5 จุลภาคที่มีนัยสำคัญ
• 2.1.6 สัญญาณทั่วไป
• 2.1.7 สัญญาณโทเค็น
• 2.1.8Punctuators
• 2.1.9Names
• 2.2 แบบสอบถามเอกสาร
• 2.2.1Operations
• 2.2.2 เลือกชุด
• 2.2.3Fields
• 2.2.4Arguments
• 2.2.5 ฟิลด์นามแฝง
• 2.2.6Fragments
• 2.2.6.1 เงื่อนไขประเภท
• 2.2.6.2 อินไลน์แฟรกเมนต์
• 2.2.7 อินพุตค่า
• 2.2.7.1Int Value
• 2.2.7.2 มูลค่าลอย
• 2.2.7.3 ค่าบูลีน
• 2.2.7.4 ค่าสตริง
• 2.2.7.5 ค่าจำนวนเงิน
• 2.2.7.6 ค่ารายการ
• 2.2.7.7Input Object Objects
• 2.2.8Variables
• 2.2.8.1 การใช้งานที่หลากหลายภายในแฟรกเมนต์
• 2.2.9 ประเภทอินพุต
• 2.2.10Directives
• 2.2.10.1 คำสั่งการจัดเรียง
• 3 ระบบประเภท
• 3.1Types
• 3.1.1Scalars
• 3.1.1.1 สเกลาร์ในตัว
• 3.1.1.1.1Int
• 3.1.1.1.2Float
• 3.1.1.1.3String
• 3.1.1.1.4Boolean
• 3.1.1.1.5ID
• 3.1.2Objects
• 3.1.2.1 ข้อโต้แย้งฟิลด์
• 3.1.2.2Object Field deprecation
• 3.1.2.3 การตรวจสอบประเภทวัตถุ
• 3.1.3Interfaces
• 3.1.3.1 การตรวจสอบประเภทอินเทอร์เฟซ
• 3.1.4Unions
• 3.1.4.1 การตรวจสอบประเภทยูเนี่ยน
• 3.1.5Enums
• 3.1.6 อินพุตวัตถุ
• 3.1.7Lists
• 3.1.8Non-Null
• 3.2Directives
• 3.2.1@skip
• 3.2.2@include
• 3.3 ประเภทการเริ่มต้น
• 4Introspection
• 4.1 หลักการทั่วไป
• 4.1.1 การตั้งชื่อการประชุม
• 4.1.2Documentation
• 4.1.3Deprecation
• 4.1.4 ชื่อประเภทวิปัสสนา
• 4.2Schema วิปัสสนา
• 4.2.1 ประเภท "__Type"
• 4.2.2 ประเภทประเภท
• 4.2.2.1Scalar
• 4.2.2.2Object
• 4.2.2.3Union
• 4.2.2.4Interface
• 4.2.2.5Enum
• 4.2.2.6Input Object
• 4.2.2.7List
• 4.2.2.8Non โมฆะ
• 4.2.2.9 รายการรวมและไม่ใช่ค่าว่าง
• 4.2.3 ประเภท __ สนาม
• 4.2.4The __InputValue Type
• 5Validation
• 5.1Operations
• 5.1.1 คำจำกัดความการดำเนินงานที่มีชื่อ
• 5.1.1.1 ชื่อการดำเนินงานที่ไม่ซ้ำ
• 5.1.2 คำจำกัดความการดำเนินงานที่ไม่ระบุชื่อ
• 5.1.2.1 การดำเนินการที่ไม่ระบุชื่อโลน
• 5.2Fields
• 5.2.1 การเลือกฟิลด์บนออบเจ็กต์ส่วนต่อประสานและประเภทของสหภาพ
• 5.2.2 การคัดเลือกสนามผสาน
• 5.2.3 การเลือกเขตข้อมูลใบไม้
• 5.3Arguments
• 5.3.1 ชื่อวัตถุ
• 5.3.2 วัตถุโบราณ
• 5.3.3Argument Values ​​Type ความถูกต้อง
• 5.3.3.1 ค่าที่เข้ากันได้
• 5.3.3.2 อาร์กิวเมนต์ที่จำเป็น
• 5.4Fragments
• 5.4.1 การประกาศการจัดเรียง
• 5.4.1.1 ชื่อแฟรกเมนต์เฉพาะ
• 5.4.1.2 การดำรงอยู่ของชนิดการกระจายแบบคงที่
• 5.4.1.3Fragments ในประเภทคอมโพสิต
• 5.4.1.4 ต้องใช้แฟรกเมนต์
• 5.4.2 การกระจายข้อมูลแบบกระจาย
• 5.4.2.1 กำหนดเป้าหมายการแพร่กระจายของไฟล์
• 5.4.2.2 การกระจายข้อมูลต้องไม่ก่อตัวเป็นวงรอบ
• 5.4.2.3 การแพร่กระจายของแฟรกเมนต์เป็นไปได้
• 5.4.2.3.1 วัตถุกระจายในขอบเขตวัตถุ
• 5.4.2.3.2 กระจายในขอบเขตวัตถุ
• 5.4.2.3.3 วัตถุสเปรดในขอบเขตนามธรรม
• 5.4.2.3.4Abstract Spreads ในขอบเขตนามธรรม
• 5.5Values
• 5.5.1 การป้อนค่าฟิลด์วัตถุที่ไม่ซ้ำกัน
• 5.6Directives
• 5.6.1 ไดเรกทอรีมีการกำหนด
• 5.7Variables
• 5.7.1 เอกลักษณ์ที่แตกต่างกัน
• 5.7.2 ค่าเริ่มต้นที่เปลี่ยนแปลงได้ถูกพิมพ์อย่างถูกต้อง
• 5.7.3 ตัวแปรเป็นประเภทอินพุต
• 5.7.4 การใช้ตัวแปรที่กำหนดทั้งหมด
• 5.7.5 ตัวแปรทั้งหมดที่ใช้
• 5.7.6 อนุญาตให้ใช้ตัวแปรทั้งหมดได้
• 6Execution
• 6.1 การประเมินผลคำขอ
• 6.2Coercing ตัวแปร
• 6.3 การประเมินผลการดำเนินงาน
• 6.4 การประเมินชุดการเลือก
• 6.5 การประเมินชุดเขตข้อมูลที่จัดกลุ่ม
• 6.5.1 รายการฟิลด์
• 6.5.2 การประเมินผลตามปกติ
• 6.5.3 การดำเนินการตามลำดับ
• 6.5.4 การจัดการข้อผิดพลาด
• 6.5.5Nullability
• 7Response
• 7.1 รูปแบบการจัดลำดับ
• 7.1.1JSON การทำให้เป็นอนุกรม
• 7.2 รูปแบบการตอบสนอง
• 7.2.1Data
• 7.2.2Errors
• AAppendix: อนุสัญญาโน้ต
• A.1Context ไวยากรณ์ฟรี
• A.2 กฎหมายไวยากรณ์และไวยากรณ์
• A.3Grammar สัญกรณ์
• A.4Grammar Semantics
• A.5Algorithms
• BAppendix: สรุปไวยากรณ์
• โทเค็น B.1Ignored
• B.2 สัญญาณโทเค็น
• B.3 แบบสอบถามเอกสาร

มันเป็นทางเลือกของคุณ:

Falcor ที่มีเอกสารสั้นหวานและง่าย VERSUS เครื่องมือระดับองค์กรขนาดใหญ่ที่มีเอกสารที่ยาวและทันสมัยเป็น GraphQL & Relay

อย่างที่ฉันพูดไว้ก่อนหน้านี้ถ้าคุณเป็นนักพัฒนาระดับแนวหน้าที่เข้าใจแนวคิดในการใช้ JSON การใช้งานกราฟ JSON จากทีมของ Falcor เป็นวิธีที่ดีที่สุดในการทำโครงการ dev แบบเต็มสแต็กของคุณ

ในระยะสั้น Falcor หรือ GraphQL หรือ Restful แก้ปัญหาเดียวกัน - ให้เครื่องมือในการสืบค้น / จัดการข้อมูลอย่างมีประสิทธิภาพ

ความแตกต่างคือวิธีการนำเสนอข้อมูล:

• Falcor ต้องการให้คุณคิดว่าข้อมูลของพวกเขาเป็นต้นไม้ใหญ่มาก JSON เสมือนจริงและการใช้งานได้ , การตั้งค่าและการโทรเพื่ออ่านเขียนข้อมูล
• GraphQL ต้องการให้คุณคิดว่าข้อมูลของพวกเขาเป็นกลุ่มของวัตถุที่พิมพ์ไว้ล่วงหน้าและใช้การสืบค้นและการกลายพันธุ์ในการอ่านเขียนข้อมูล
• พักผ่อนอยากให้คุณคิดว่าข้อมูลของพวกเขาเป็นกลุ่มของทรัพยากรและใช้คำกริยา HTTP ในการอ่านเขียนข้อมูล

เมื่อใดก็ตามที่เราต้องการให้ข้อมูลแก่ผู้ใช้เราจะพบสิ่งที่ชอบ: client -> query -> {a layer แปลแบบสอบถามเป็น data ops} -> data

หลังจากดิ้นรนกับ GraphQL, Falcor และ JSON API (และแม้กระทั่ง ODdata) ฉันก็เขียนเลเยอร์แบบสอบถามข้อมูลของตัวเองชั้นการค้นหาข้อมูลมันง่ายกว่าง่ายกว่าที่จะเรียนรู้และเทียบเท่ากับ GraphQL

ตรวจสอบได้ที่:
https://github.com/giapnguyen74/nextql

นอกจากนี้ยังทำงานร่วมกับ featherjs สำหรับเรียลไทม์แบบสอบถาม / การกลายพันธุ์ https://github.com/giapnguyen74/nextql-feathers

ตกลงเพียงแค่เริ่มจากความแตกต่างที่เรียบง่าย แต่สำคัญGraphQLเป็นข้อความค้นหาในขณะที่Falcorไม่ใช่!

แต่พวกเขาช่วยคุณได้อย่างไร

โดยพื้นฐานแล้วพวกเขาทั้งสองช่วยให้เราจัดการและสืบค้นข้อมูล แต่GraphQLมีโมเดลreq / resและส่งคืนข้อมูลเป็นJSONโดยทั่วไปความคิดในGraphQLนั้นมีคำขอเดียวเพื่อให้ได้ข้อมูลทั้งหมดของคุณในเป้าหมายเดียว ... นอกจากนี้ มีการตอบสนองที่แน่นอนโดยมีการร้องขอที่แน่นอนดังนั้นสิ่งที่จะทำงานบนอินเทอร์เน็ตความเร็วต่ำและอุปกรณ์มือถือเช่นเครือข่าย 3G ... ดังนั้นถ้าคุณมีผู้ใช้มือถือจำนวนมากหรือด้วยเหตุผลบางอย่างที่คุณต้องการที่จะมีคำขอน้อยลง ใช้GraphQL ... ในขณะที่Faclorอยู่ไม่ไกลจากนี้อ่านต่อ ...

ในทางกลับกันFalcorโดย Netflix มักจะมีคำขอพิเศษ (โดยปกติมากกว่าหนึ่งครั้ง) เพื่อดึงข้อมูลทั้งหมดของคุณแม้ว่าพวกเขาจะพยายามปรับปรุงให้เป็นคำขอเดียว ... Falcorมีข้อ จำกัด มากกว่าสำหรับแบบสอบถาม กำหนดผู้ช่วยแบบสอบถามเช่นช่วงและอื่น ๆ ...

แต่เพื่อความกระจ่างมากขึ้นเรามาดูกันว่าแต่ละคนแนะนำตัวเองอย่างไร:

GraphQL ภาษาคิวรีสำหรับ API ของคุณ

GraphQL เป็นภาษาคิวรีสำหรับ API และรันไทม์สำหรับทำแบบสอบถามเหล่านั้นด้วยข้อมูลที่มีอยู่ของคุณ GraphQL ให้คำอธิบายที่สมบูรณ์และเข้าใจได้ของข้อมูลใน API ของคุณให้ลูกค้ามีอำนาจในการขอสิ่งที่พวกเขาต้องการและไม่มีอะไรเพิ่มเติมทำให้ง่ายต่อการพัฒนา API ในช่วงเวลาหนึ่งและเปิดใช้งานเครื่องมือสำหรับนักพัฒนาที่มีประสิทธิภาพ

ส่งแบบสอบถาม GraphQL ไปยัง API ของคุณและรับสิ่งที่คุณต้องการอย่างแน่นอนไม่มีอะไรมากและไม่น้อยไปกว่านี้ ข้อความค้นหา GraphQL จะส่งคืนผลลัพธ์ที่คาดการณ์ได้เสมอ แอปที่ใช้ GraphQL นั้นรวดเร็วและมีความเสถียรเนื่องจากควบคุมข้อมูลที่ได้รับไม่ใช่เซิร์ฟเวอร์

การเข้าถึงแบบสอบถาม GraphQL ไม่เพียง แต่คุณสมบัติของทรัพยากรเดียว แต่ยังติดตามการอ้างอิงระหว่างพวกเขาได้อย่างราบรื่น ในขณะที่ REST API ทั่วไปต้องการโหลดจากหลาย ๆ URL แต่ GraphQL API จะได้รับข้อมูลทั้งหมดที่แอพของคุณต้องการในการร้องขอเดียว แอปที่ใช้ GraphQL สามารถทำได้อย่างรวดเร็วแม้ในการเชื่อมต่อเครือข่ายมือถือที่ช้า

GraphQL API ถูกจัดระเบียบในแง่ของประเภทและฟิลด์ไม่ใช่ปลายทาง เข้าถึงความสามารถทั้งหมดของข้อมูลของคุณจากจุดปลายเดียว GraphQL ใช้ประเภทเพื่อให้แน่ใจว่าแอพถามเฉพาะสิ่งที่เป็นไปได้และให้ข้อผิดพลาดที่ชัดเจนและเป็นประโยชน์ แอปสามารถใช้ประเภทเพื่อหลีกเลี่ยงการเขียนโค้ดการแยกวิเคราะห์ด้วยตนเอง

Falcor ห้องสมุด JavaScript เพื่อการดึงข้อมูลที่มีประสิทธิภาพ

Falcor ช่วยให้คุณแสดงแหล่งข้อมูลระยะไกลทั้งหมดของคุณเป็นรูปแบบโดเมนเดียวผ่านกราฟ JSON เสมือน คุณใช้รหัสในลักษณะเดียวกันไม่ว่าข้อมูลจะอยู่ในหน่วยความจำบนไคลเอนต์หรือบนเครือข่ายบนเซิร์ฟเวอร์

ไวยากรณ์พา ธ เหมือน JavaScript ทำให้ง่ายต่อการเข้าถึงข้อมูลมากหรือน้อยตามที่คุณต้องการเมื่อคุณต้องการ คุณดึงข้อมูลของคุณโดยใช้การดำเนินการ JavaScript ที่คุ้นเคยเช่นรับตั้งค่าและโทร ถ้าคุณรู้ข้อมูลของคุณคุณก็รู้ว่า API ของคุณ

Falcor สำรวจการอ้างอิงในกราฟของคุณโดยอัตโนมัติและทำการร้องขอตามที่จำเป็น ฟัลคอร์จัดการการสื่อสารผ่านเครือข่ายทั้งหมดอย่างโปร่งใส, การแบตช์และคำขอยกเลิกการทำซ้ำ