Graphql – การเปลี่ยนแปลงและปรับปรุงวิธีการสื่อสารของแอปพลิเคชัน

ไม่นานนักคนรุ่นต่อไปจะซื้อคริปโตและตรวจสอบความสมดุลของหน่วยทรัสต์ใน ล็อบบี้ Fortnite ระหว่างเกม นี่จะเป็นไปได้โดยอาศัยความก้าวหน้าทางเทคโนโลยีหลายอย่าง

สิ่งที่เรากำลังพูดถึงในวันนี้คือวิธีการถ่ายโอนข้อมูล (อ่าน อัปเดต เพิ่ม/ลบ) ระหว่างแอปพลิเคชันและบริษัทที่เป็นเจ้าของ แอปพลิเคชันโปรแกรมมิ่งอินเทอร์เฟซ (API) คือสถาปัตยกรรมที่กำหนดการรับส่งข้อมูลนี้ และเมื่อมาตรฐานเหล่านี้พัฒนาแล้ว ความต้องการในการประมวลผลและจัดเก็บข้อมูลก็ลดลง

ผู้นำในกลุ่มในแง่ของ “การใช้ทรัพยากรเบา” คือ GraphQL ภาษาควอรี่และจัดการข้อมูลแบบเปิด รากฐานของระบบนิเวศคือสเปคและชุดเครื่องมือที่สร้างขึ้นรอบๆ มัน

ไม่ใช่สิ่งใหม่ – เวลาผ่านไปเร็ว Facebook พัฒนามันในปี 2012 และใช้เฉพาะภายในสำหรับการพัฒนาแอปพลิเคชันมือถือ ในปี 2015 มันถูก “เปิดแหล่งที่มา” และปัจจุบันถูกดูแลโดย GraphQL Foundation (https://graphql.org/foundation/) ซึ่งดูแลการพัฒนาต่อ

ทำไมฉันถึงเขียนเกี่ยวกับมันในวันนี้? แผนเส้นทางสู่การรับเทคโนโลยีจะตามรูปแบบการรับใช้ดังนี้ 1) นักพัฒนาส่วนบุคคล/โปรเจ็กต์ส่วนบุคคล 2) การใช้งานข้ามภาษาหลายภาษา 3) การใช้งานข้ามสตาร์ทอัพและบริษัทขนาดเล็ก 4) บริษัทขนาดกลางและใช้ในพัฒนาผลิตภัณฑ์ 5) บริษัทขนาดใหญ่และยักษ์เทคโนโลยี

GraphQL ได้ถึงระดับ 5 ปัจจุบันใช้โดย GitHub Pinterest Shopify Microsoft เพื่อชื่อไม่กี่ตัว และล่าสุด ในเดือนมีนาคม 2022 Salesforce

เมื่อฉันกำลังมองหาวิธีการดึงข้อมูลจาก Salesforce ฉันพบเอกสาร GraphQL ของพวกเขาและเริ่มอ่านและดูวิธีการใช้งาน

GraphQL แตกต่างจาก API แบบดั้งเดิมอย่างไร?

• หนึ่งในข้อได้เปรียบที่สำคัญคือ GraphQL ช่วยให้คุณสามารถคิวรี่และได้รับเฉพาะข้อมูลที่คุณต้องการเท่านั้น หากคุณต้องการเฉพาะสองฟิลด์ที่เกี่ยวข้องกับเหตุการณ์ของลูกค้า คุณจะได้รับเฉพาะสิ่งนั้น API แบบดั้งเดิมจะส่งคืนฟิลด์ทั้งหมดที่เกี่ยวข้องกับเหตุการณ์ ซึ่งอาจมี 100+ ฟิลด์ ตอนนี้คุณต้องทำอะไรบางอย่างกับข้อมูลทั้งหมดที่คุณไม่ต้องการในตอนแรก ซึ่งเรียกว่า การดึงข้อมูลมากเกินไป (การดึงข้อมูลน้อยเกินไปก็เป็นปัญหา)
• สิ่งที่กล่าวมาข้างต้นทำให้ GraphQL เร็วกว่าวิธีการ API อื่นๆ เมื่อกลับข้อมูล
• GraphQL เป็นภาษาที่มีการกำหนดประเภทอย่างเข้มงวด ซึ่งหมายความว่าข้อผิดพลาดของโค้ดจะถูกจับได้ก่อนที่โปรแกรมจะทำงาน ไม่ใช่ระหว่างที่มันทำงาน
• ชุดเครื่องมือที่ดีได้ถูกสร้างขึ้นรอบๆ GraphQL ซึ่งทำให้มันเป็นมิตรกับนักพัฒนา
• GraphQL มีจุดสิ้นสุดเดียว ในขณะที่ API แบบดั้งเดิมมีจุดสิ้นสุดหลายจุด ซึ่งหมายความว่าข้อมูลทั้งหมดของคุณสามารถดึงมาได้ในคำขอเดียว

สองด้านของเหรียญ: ผู้ร้องขอ (クライアント) และผู้ให้บริการ (โฮสต์ GraphQL)

ฉันพิจารณา GraphQL จนถึงตอนนี้จากมุมมองของ “การร้องขอข้อมูล” โดยที่บริษัท เช่น Salesforce หรือ Microsoft ตั้งค่า API ของ GraphQL ที่คุณสามารถใช้เพื่อคิวรี่และจัดการข้อมูล (อ่าน อัปเดต เพิ่ม)

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

อีกด้านหนึ่งของเหรียญคือองค์กรที่ตั้งค่าโครงสร้าง GraphQL เพื่อให้ลูกค้ามีวิธีการเข้าถึงข้อมูลที่พวกเขาต้องการได้อย่างมีประสิทธิภาพ

เมื่อสร้าง API ของ GraphQL องค์กรกำลังสร้างแบบจำลองที่รวมระบบทั้งหมดเข้าด้วยกัน มันรวมระบบเหล่านี้เข้าด้วยกัน และเมื่องานเสร็จสิ้น การคิวรี่ข้อมูลจะกลายเป็นเรื่องง่ายผ่าน API

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