Smashing Podcast ตอนที่ 31 กับ Eve Porcello: GraphQL คืออะไร?

ในตอนนี้ เรากำลังพูดถึง GraphQL มันคืออะไร และแก้ปัญหา API ทั่วไปได้อย่างไร ฉันได้พูดคุยกับผู้เชี่ยวชาญ Eve Porcello เพื่อหาคำตอบ

แสดงหมายเหตุ

• อีฟบนทวิตเตอร์
• บริษัท Moon Highway ของอีฟ
• การเรียนรู้ GraphQL จาก O'Reilly
• ค้นพบเส้นทางของคุณผ่านพื้นที่รกร้างของ GraphQL - เวิร์กชอป GraphQL ของอีฟที่จะเปิดตัวต้นปี 2021

อัพเดทประจำสัปดาห์

• วิธีใช้ MDX ที่จัดเก็บไว้ในเว็บไซต์ Next.js
  เขียนโดย Jason Lengstorf
• การสร้าง Chatbot ที่เปิดใช้งาน NLP การสนทนาโดยใช้ Dialogflow ของ Google
  เขียนโดย นวนี ชัยชนะ
• ข้อพิจารณาด้านจริยธรรมในการวิจัย UX: ความจำเป็นในการฝึกอบรมและการทบทวน
  เขียนโดย Victor Yocco
• ทำให้เว็บไซต์ง่ายต่อการพูดคุยกับ
  เขียนโดย Frederick O'Brien
• วิธีออกแบบ UI อย่างง่ายเมื่อคุณมีโซลูชันที่ซับซ้อน
  เขียนโดย Suzanne Scacca

การถอดเสียง

Drew McLellan: เธอเป็นวิศวกรซอฟต์แวร์ ผู้สอน นักเขียน และผู้ร่วมก่อตั้งบริษัทฝึกอบรมและพัฒนาหลักสูตร Moon Highway อาชีพของเธอเริ่มเขียนข้อกำหนดทางเทคนิคและสร้างการออกแบบ UX สำหรับโครงการเว็บ ตั้งแต่เริ่มต้น Moon Highway ในปี 2012 เธอได้สร้างเนื้อหาวิดีโอสำหรับ egghead.io และ LinkedIn Learning และได้ร่วมเขียนหนังสือ Learning React และ Learning GraphQL สำหรับ O'Reilly's Media

Drew: เธอยังเป็นวิทยากรในการประชุมเป็นประจำ และได้นำเสนอในการประชุมต่างๆ เช่น React Rally, GraphQL Summit และ OSCON เรารู้ว่าเธอเป็นผู้เชี่ยวชาญใน GraphQL แต่คุณรู้หรือไม่ว่าเธอเคยสอนหมีขั้วโลกให้เล่นหมากรุก เพื่อนที่ยอดเยี่ยมของฉัน ได้โปรดต้อนรับ Eve Porcello

ดรูว์: สวัสดีอีฟ สบายดีไหม

Eve Porcello: ฉันยอดเยี่ยมมาก

Drew: ตามที่ผมได้กล่าวไป คุณเป็นนักการศึกษาในด้านต่างๆ เช่น JavaScript และ React เป็นอย่างมาก แต่วันนี้ผมต้องการจะคุยกับคุณเกี่ยวกับผู้เชี่ยวชาญด้านอื่นๆ ของคุณอย่าง GraphQL พวกเราหลายคนคงเคยได้ยินเกี่ยวกับ GraphQL มาบ้างแล้ว แต่อาจยังไม่แน่ใจนักว่ามันคืออะไร หรือทำอะไร และโดยเฉพาะอย่างยิ่ง ปัญหาประเภทใดที่มันแก้ไขได้ในเว็บสแต็ก

Drew: ดังนั้นจงตั้งเวทีสำหรับเรา ถ้าคุณต้องการ ถ้าฉันเป็นนักพัฒนาส่วนหน้า GraphQL สล็อตในระบบนิเวศอยู่ที่ไหน และมันทำหน้าที่อะไรสำหรับฉัน

อีฟ: ครับ ชนิดของ GraphQL นั้นพอดีระหว่างส่วนหน้าและส่วนหลัง เป็นการอยู่ตรงกลางระหว่างคนทั้งสองและให้ประโยชน์มากมายแก่นักพัฒนาส่วนหน้าและนักพัฒนาส่วนหลัง

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

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

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

อีฟ: ใช่ ถูกต้องแล้ว อย่างแน่นอน.

Drew: ฉันคิดว่าในช่วงทศวรรษที่ผ่านมา มาตรฐานทองคำสำหรับ API ได้หยุดนิ่งแล้ว ดังนั้นหากคุณมีแอปฝั่งไคลเอ็นต์และต้องการเติมข้อมูลจากแบ็กเอนด์ คุณจะต้องสร้างปลายทาง REST API และค้นหาสิ่งนั้น แล้วรุ่นนั้นมันตกตรงไหน? และเมื่อใดที่เราต้องการ GraphQL เพื่อเข้ามาแก้ปัญหานั้นให้เรา

อีฟ: ปัญหาที่ GraphQL ช่วยเราได้จริงๆ เช่น ปัญหาทอง วิธีแก้ปัญหาทอง ฉันเดาว่า GraphQL มีให้คือว่าด้วย REST เราดึงข้อมูลมากเกินไป ดังนั้นหากฉันมีผู้ใช้ slash หรือผลิตภัณฑ์ slash ข้อมูลนั้นจะคืนให้ฉันทุกครั้งที่ฉันเข้าสู่เส้นทาง

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

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

อีฟ: ใช่แน่นอน ดังนั้นคำถามของคุณจึงกลายเป็นวิธีที่คุณถาม วิธีที่คุณกรอง วิธีที่คุณเข้าใจข้อมูลประเภทใดก็ได้จากทุกที่

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

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

Drew: ดังนั้นคุณเพิ่มสิ่งนั้นไปยังจุดสิ้นสุด และเริ่มส่งคืนสิ่งนั้น จากนั้นคุณทำส่วนการจัดการบัญชีของคุณ และคุณต้องการเช่นที่อยู่ทางไปรษณีย์ของพวกเขา เพื่อที่ปลายทางนั้นจะถูกส่งกลับเช่นกัน

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

Drew: และนั่นก็ถูกคัดออกทุกหน้าเพื่อแสดงอวาตาร์ ดังนั้น ฉันเดาว่านั่นคือปัญหาประเภทหนึ่งที่เติบโตขึ้นตามกาลเวลา ซึ่งง่ายมากที่จะตกอยู่ใน โดยเฉพาะอย่างยิ่งในทีมใหญ่ๆ ที่ GraphQL ซึ่งอยู่เหนือปัญหานั้น มันรู้วิธีแก้ปัญหา และได้รับการออกแบบมาเพื่อแก้ปัญหานั้น

อีฟ: ตรงนั้น และใช่ ฉันคิดว่าแนวคิดทั้งหมดของ GraphQL Schema นั้น ฉันคิดว่าเป็นแนวคิดที่มีคนพูดถึงน้อยกว่าส่วนภาษาที่ใช้ค้นหาของ GraphQL แต่ฉันรู้สึกว่า Schema โดยเฉพาะทำให้เรามีระบบประเภทที่ดีสำหรับ API นี้

อีฟ: ดังนั้น ใครก็ตามในทีม ผู้จัดการ นักพัฒนาส่วนหน้า นักพัฒนาส่วนหลัง ใครก็ตามที่จัดการกับข้อมูลจริงๆ สามารถมารวมกันได้ รวบรวมข้อมูลที่เราต้องการแสดงบน API นี้จริง ๆ แล้วทุกคนก็รู้ว่าแหล่งที่มานั้นคืออะไร ความจริงก็คือ พวกเขาสามารถสร้างส่วนต่าง ๆ ของแอพตามนั้นได้

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

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

Drew: ด้วย GraphQL คุณมีเพียงจุดปลายเดียวที่คุณเพิ่งเริ่มการสืบค้นและคุณจะได้รับการตอบสนองที่เหมาะสม

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

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

อีฟ: มันยังคงเป็นสตริงเทคโนโลยี แต่ไม่ได้กำหนดว่าตรรกะนั้นมาจากไหน และตรรกะหลายอย่างก็ถูกย้ายกลับไปที่เซิร์ฟเวอร์ ดังนั้นเซิร์ฟเวอร์ GraphQL ของ GraphQL API จึงมีหน้าที่ในการพูดว่า "ไปรับข้อมูลนี้จากที่ที่มันอยู่ กรองตามพารามิเตอร์เหล่านี้"

อีฟ: แต่ในภาษาของคิวรี เป็นภาษาที่เน้นภาคสนามมาก ดังนั้นเราจึงเพิ่มฟิลด์สำหรับสิ่งที่เราต้องการดึงข้อมูล เราสามารถใส่ตัวกรองลงในคำค้นหาเหล่านั้นได้เช่นกัน แต่ฉันคิดว่ามันตรงไปตรงมาน้อยกว่าเล็กน้อยเกี่ยวกับที่มาของข้อมูลนั้น มีฟังก์ชันการทำงานมากมายในเซิร์ฟเวอร์

Drew: เพื่อให้คุณสามารถผสมและจับคู่ในแบบสอบถามได้ คุณสามารถส่งคำขอที่นำข้อมูลหลายประเภทกลับมาในคำขอเดียว นั่นถูกต้องใช่ไหม?

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

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

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

Drew: และแบบสอบถามนั้นใช้ JSON ใช่ไหม

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

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

อีฟ: แน่นอน ดังนั้นสิ่งที่น่าตื่นเต้นและทรงพลังอย่างแท้จริงเกี่ยวกับ GraphQL คือ คุณสามารถย้ายตรรกะนั้นไปยังเซิร์ฟเวอร์ได้มากมาย หากคุณมีข้อความค้นหาที่ซับซ้อน ผู้ใช้บางประเภทที่คุณต้องการได้จริงๆ สิ่งที่คุณต้องทำใน Schema คือพูดว่า "รับผู้ใช้ที่ซับซ้อน" จากนั้นบนเซิร์ฟเวอร์ จะมีฟังก์ชันที่ คุณสามารถเขียนตรรกะทั้งหมดในภาษาใดก็ได้ที่คุณต้องการ JavaScript เป็นภาษาการใช้งาน GraphQL ที่ได้รับความนิยมมากที่สุด แต่คุณไม่จำเป็นต้องใช้มันเลย ดังนั้น Python, Go, C++ ไม่ว่าคุณจะต้องการใช้อะไร คุณสามารถสร้างเซิร์ฟเวอร์ GraphQL ได้ด้วยสิ่งนั้น แต่ใช่ คุณสามารถกำหนดคำค้นหาที่ซับซ้อนได้ตามที่คุณต้องการ

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

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

Drew: ดูเหมือนว่าเป็นการจัดระเบียบ API และความสัมพันธ์ระหว่างส่วนหน้าและส่วนหลัง ดังนั้นทุกคนจึงได้รับอินเทอร์เฟซที่คาดการณ์ได้ซึ่งเป็นมาตรฐาน

อีฟ: ตรงนั้น

Drew: ซึ่งผมเดาว่าในองค์กรที่ front end และ backend เป็นของคนละทีม ซึ่งก็ไม่ใช่เรื่องแปลกเลย ผมเดาว่าแนวทางนี้ทำให้สามารถเปลี่ยนแปลงได้ เช่น front end มันอาจจะต่างกัน ข้อมูลโดยไม่จำเป็นต้องมีคนที่ทำงานแบ็คเอนด์เพื่อทำการเปลี่ยนแปลงที่สอดคล้องกับข้อมูลนั้น คุณยังคงมี API ที่ปรับแต่งได้แทบไม่มีที่สิ้นสุดนี้โดยไม่ต้องดำเนินการใดๆ เพื่อเปลี่ยนแปลง หากคุณต้องการข้อมูลใหม่

อีฟ: ใช่ถูกต้อง

Drew: เซิร์ฟเวอร์ GraphQL มีหน้าที่จัดรูปแบบการตอบสนองหรือคุณจำเป็นต้องทำในตรรกะฝั่งเซิร์ฟเวอร์ของคุณหรือไม่?

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

Drew: ลูกค้าบอกว่า "ฉันต้องการผู้ใช้ที่ซับซ้อน" เซิร์ฟเวอร์ได้รับข้อความนั้นในแบบสอบถามและสามารถพูดว่า "ถูกต้อง ฉันจะค้นหาตัวแก้ไขผู้ใช้ที่ซับซ้อน" นั่นถูกต้องใช่ไหม?

อีฟ: อืม อืม (ยืนยัน)

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

อีฟ: ใช่แน่นอน

Drew: มันสามารถเรียก API อื่น ๆ มันอาจเป็นการสืบค้นฐานข้อมูล มันสามารถค้นหาข้อมูลในแคชหรืออะไรก็ได้

อีฟ: เกือบทุกอย่าง จากนั้น ตราบใดที่ผลตอบแทนจากฟังก์ชันตรงกับข้อกำหนดของสคีมา ตรงกับฟิลด์ใด ประเภทใด ที่ส่งคืนที่นั่น จากนั้นทุกอย่างจะทำงานได้ดีและกลมกลืนกัน

Drew: ฉันเดาว่ามันให้รูปแบบการตอบสนองที่สอดคล้องกันใน API ทั้งหมดของคุณโดยค่าเริ่มต้น คุณไม่จำเป็นต้องออกแบบสิ่งที่ดูเหมือน คุณเพียงแค่ได้รับผลลัพธ์ที่สม่ำเสมอ

อีฟ: ใช่แน่นอน

Drew: ฉันคิดว่านั่นอาจเป็นชัยชนะอย่างแท้จริง เพราะมันอาจเป็นเรื่องยากจริงๆ ที่จะรักษาความสม่ำเสมอในจุดสิ้นสุด API ที่หลากหลาย โดยเฉพาะอย่างยิ่งในทีมขนาดใหญ่ ต่างคนต่างทำงานในสิ่งที่แตกต่างกัน เว้นแต่คุณจะมีธรรมาภิบาลที่เข้มงวด มันอาจจะซับซ้อนได้เร็วมาก จริงไหม?

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

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

Drew: ในทางปฏิบัติ สิ่งต่าง ๆ ทำงานบนฝั่งเซิร์ฟเวอร์อย่างไร ฉันหมายความว่า ฉันเดาว่าคุณต้องเรียกใช้บริการ GraphQL ซึ่งเป็นส่วนหนึ่งของโครงสร้างพื้นฐานของคุณ แต่รูปแบบนั้นเป็นอย่างไร เป็นเซิร์ฟเวอร์ทั้งหมดที่ทำงานบนพอร์ตของตัวเองหรือไม่? หรือเหมือนกับไลบรารีที่คุณรวมเข้ากับ Express หรือ Apache ที่มีอยู่หรืออะไรก็ตามที่มีเส้นทางที่แก้ไขบริการนั้น คุณดำเนินการอย่างไร?

อีฟ: ใช่ มันเป็นเซิร์ฟเวอร์จริง การใช้งาน GraphQL ที่ได้รับความนิยมมากที่สุดคือเซิร์ฟเวอร์ Node.js เมื่อ GraphQL เป็นข้อมูลจำเพาะเปิดตัว ทีมงานได้เผยแพร่การใช้งานอ้างอิงนี้ใน JavaScript ซึ่งเป็นประเภทของเซิร์ฟเวอร์โหนดที่ทำหน้าที่เป็นแนวทางสำหรับสิ่งอื่นๆ ทั้งหมดที่ปรากฏขึ้น แต่ใช่ คุณสามารถเรียกใช้เซิร์ฟเวอร์เหล่านี้ในอินสแตนซ์ของตนเองได้ คุณสามารถใส่มันลงบนแลมบ์ดา มี Apollo Server Express มี Apollo Server Lambda; การใช้งานประเภทต่างๆ ทุกประเภทที่คุณสามารถใช้เพื่อเรียกใช้สิ่งนี้ได้จริง

Drew: ดังนั้นคุณจึงกล่าวถึงสั้น ๆ ก่อนแนวคิดของ Schema ที่เซิร์ฟเวอร์มี

อีฟ: ครับ

Drew: นั่นทำให้คุณสามารถอธิบายประเภทของคุณได้อย่างเคร่งครัดมากกว่าการทำแผนที่ชื่อกับตัวแก้ไข มีส่วนเกี่ยวข้องมากขึ้นที่นั่น ใช่ไหม?

อีฟ: ครับ มีภาษาเต็ม ดังนั้นฉันจึงอ้างอิงข้อมูลจำเพาะและไม่ได้อธิบายว่ามันคืออะไร GraphQL เองเป็นข้อมูลจำเพาะที่อธิบายภาษาการสืบค้นและภาษาคำจำกัดความของ Schema จึงมีวากยสัมพันธ์เป็นของตัวเอง มีกฎเกณฑ์ในการกำหนดประเภทเหล่านี้

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

อีฟ: ใช่แล้ว สคีมานั้นสำคัญมากจริงๆ และฉันคิดว่ามันให้การบังคับใช้ประเภทที่ดีแก่เราในแอปพลิเคชัน Stack ทั้งหมดของเรา เพราะทันทีที่คุณเริ่มเบี่ยงเบนจากฟิลด์เหล่านั้นและจากประเภทเหล่านั้น คุณเริ่มเห็นข้อผิดพลาด ซึ่งในกรณีนี้ ดี เพราะคุณ กำลังปฏิบัติตามกฎของสคีมา

Drew: มีครอสโอเวอร์ระหว่างสิ่งนั้นกับ TypeScript หรือไม่? มีการทำงานร่วมกันระหว่างคนทั้งสองที่นั่นหรือไม่?

อีฟ: แน่นอน ดังนั้น หากคุณเป็นคนที่พูดถึง GraphQL บ่อยๆ บางครั้งผู้คนจะบอกคุณว่ามันไม่ดี และพวกเขาจะเข้ามาหาคุณในที่สาธารณะ เมื่อคุณทำได้ และพูดถึงว่า GraphQL ไม่ดีอย่างไร แต่หลายครั้งที่พวกเขามองข้ามสิ่งดีๆ ที่คุณได้รับจากประเภท ตราบใดที่การทำงานร่วมกับ TypeScript เป็นไปได้ คุณสามารถสร้างประเภทอัตโนมัติสำหรับแอปพลิเคชันส่วนหน้าของคุณโดยใช้ประเภทจาก Schema นั่นเป็นชัยชนะครั้งใหญ่เพราะคุณไม่เพียงแต่สามารถสร้างมันขึ้นมาในครั้งแรกเท่านั้น ซึ่งทำให้คุณสามารถทำงานร่วมกันได้ดีกับแอปพลิเคชั่นส่วนหน้าของคุณ แต่ในขณะที่สิ่งต่าง ๆ เปลี่ยนไป คุณสามารถสร้างประเภทใหม่และสร้างเพื่อสะท้อนการเปลี่ยนแปลงเหล่านั้นได้ ใช่ ฉันคิดว่าสิ่งเหล่านั้นเข้ากันได้ดีจริง ๆ เนื่องจากประเภทเริ่มเป็นกฎ defacto

อีฟ: … เพื่อเป็นชนิดของกฎ defacto ใน JavaScript พวกเขาเข้ากันได้ดี

Drew: ดูเหมือนว่าจะเป็นธีมต่อเนื่องกับวิธีที่ TypeScript ได้รับการออกแบบ … นั่นไม่ใช่ TypeScript ขอโทษ GraphQL ได้รับการออกแบบให้มีการทำปฏิกิริยาระหว่างส่วนหน้าและส่วนหลังให้เป็นแบบแผน และมันเป็นวิธีแก้ปัญหาระหว่างความสม่ำเสมอและการทำให้เป็นทางการของสิ่งที่เคยเป็นประสบการณ์ที่ค่อนข้างกระท่อนกระแท่นกับการพักผ่อนสำหรับคนจำนวนมาก สิ่งหนึ่งที่เราต้องจำไว้เสมอเมื่อเขียนแอปฝั่งไคลเอ็นต์คือโค้ดนั้นต้องได้รับการตรวจสอบและอาจมีการแก้ไข และการมี API ที่ลูกค้าสามารถขอข้อมูลได้เพียงอย่างเดียวอาจเป็นอันตรายได้ ทีนี้ ถ้าคุณสามารถระบุฟิลด์ที่คุณต้องการได้ นั่นอาจเป็นอันตรายได้ คุณจะจัดการกับการอนุญาตของผู้ใช้และทำให้แน่ใจว่ากฎเกณฑ์ทางธุรกิจเกี่ยวกับข้อมูลของคุณบังคับใช้หรือไม่

อีฟ: คุณต้องจัดการกับสิ่งนั้นทั้งหมดบนเซิร์ฟเวอร์ จึงสามารถเกิดขึ้นได้หลายวิธี คุณไม่จำเป็นต้องใช้กลยุทธ์เดียว แต่ตัวแก้ไขจะจัดการการอนุญาตของคุณ นั่นอาจหมายถึงการปิด REST API ที่มีอยู่ เช่น บริการ เช่น Auth0 หรือสิ่งที่คุณสร้างขึ้นเอง นั่นอาจหมายถึงการโต้ตอบกับ OAuth เช่น GitHub หรือ Facebook หรือ Google เข้าสู่ระบบ ประเภทของสิ่งต่าง ๆ ที่เกี่ยวข้องกับการส่งต่อโทเค็นด้วยตัวแก้ไข แต่บ่อยครั้งที่จะสร้างโดยตรงในสคีมา สคีมาจะบอกว่า ไม่รู้ เราจะสร้างการกลายพันธุ์ของล็อกอิน จากนั้นฉันก็ส่งการกลายพันธุ์นั้นด้วยข้อมูลประจำตัวของฉัน จากนั้นบนเซิร์ฟเวอร์ ข้อมูลรับรองทั้งหมดจะได้รับการยืนยัน ดังนั้นลูกค้าจึงไม่ต้องกังวลมากนัก อาจจะเป็นการส่งโทเค็นและสิ่งต่างๆ เช่นนั้น แต่ส่วนใหญ่นั้นสร้างขึ้นในเซิร์ฟเวอร์เท่านั้น

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

อีฟ: มันอยู่ทุกที่จริงๆ ฉันคิดว่าส่วนใหญ่คุณจะเห็นคนสร้างสคีมา และโดยที่ฉันหมายถึง เป็นตัวแทนของประเภทเหล่านั้นและผู้ใช้ที่ได้รับอนุญาต กับผู้ใช้ทั่วไปที่สร้างประเภทเหล่านั้นในสคีมาเอง แต่คุณจะเห็นผู้คนจำนวนมากใช้โซลูชันของบุคคลที่สาม ฉันพูดถึง Auth0 ผู้คนจำนวนมากจะเลิกใช้การอนุญาตไปยังบริษัทที่ให้ความสำคัญกับเรื่องนี้มากขึ้น โดยเฉพาะบริษัทขนาดเล็ก สตาร์ทอัพ อะไรทำนองนั้น แต่คุณยังจะได้เห็นบริษัทขนาดใหญ่เริ่มสร้างโซลูชันสำหรับเรื่องนี้ ดังนั้น AWS, Amazon จึงมี AppSync ซึ่งเป็นรสชาติของ GraphQL และพวกเขามีม้วนผู้เขียนที่สร้างขึ้นโดยตรงใน AppSync และนั่นก็เจ๋งมากที่ทำได้ ไม่รู้สิ ไม่ต้องกังวลกับเรื่องนั้นทั้งหมด หรืออย่างน้อยก็มีอินเทอร์เฟซสำหรับการทำงานกับสิ่งนั้น เครื่องมือระบบนิเวศเหล่านี้มีอยู่มากมาย ฉันคิดว่าการอนุญาตเป็นหัวข้อใหญ่ใน GraphQL พวกเขาได้เห็นความต้องการ ความต้องการโซลูชันการตรวจสอบสิทธิ์ และวิธีการมาตรฐานในการจัดการการรับรองความถูกต้องบนกราฟ

Drew: ฉันเดาว่ามันแทบไม่มี a การนำไปใช้งานที่ไม่ต้องการการอนุญาตบางอย่าง ใช่แล้ว มันจะเป็นข้อกำหนดที่ค่อนข้างธรรมดา เรากำลังสร้างแอปพลิเคชันที่มีการจัดองค์ประกอบมากขึ้น โดยเฉพาะอย่างยิ่งเมื่อเราใช้งาน React และ View และสิ่งที่คุณมี และหลักการของการมีเพศสัมพันธ์แบบหลวม ๆ ทำให้เรามีส่วนประกอบมากมายที่ไม่จำเป็นต้องรู้ว่ามีอะไรอีกบ้างที่กำลังทำงานอยู่บนหน้าเหล่านั้น ผลที่ได้คืออันตรายหรือไม่ คุณอาจลงเอยด้วยส่วนประกอบจำนวนมากที่สืบค้นข้อมูลเดียวกันและร้องขอหลายรายการ หรือเป็นเพียงปัญหาทางสถาปัตยกรรมในแอปของคุณที่คุณต้องแก้ไข มีวิธีแก้ปัญหาที่ดีสำหรับการจัดการกับสิ่งนั้นหรือไม่?

อีฟ: ฉันคิดว่าเพราะส่วนใหญ่แล้ว GraphQL ไม่ใช่โซลูชัน 100% แต่การสืบค้น GraphQL เกือบทั้งหมดถูกส่งผ่าน HTTP ดังนั้น หากคุณต้องการติดตามว่าคำขอหลายรายการเกิดขึ้นที่ใด อาจเป็นปัญหาที่คุ้นเคยสำหรับผู้ที่ใช้ข้อมูลการพักสำหรับแอปพลิเคชันของตน ดังนั้นจึงมีเครื่องมือบางอย่างเช่น Paulo Client Dev Tools และ Urkel Dev Tools สำหรับนักพัฒนาส่วนหน้าที่ชอบ "เกิดอะไรขึ้น? คำถามใดอยู่ในหน้านี้” ที่ช่วยให้คุณเข้าใจอย่างถ่องแท้ถึงสิ่งที่เกิดขึ้น มีหลายโรงเรียนที่มีความคิดเกี่ยวกับเรื่องนี้ เราสร้างแบบสอบถามขนาดใหญ่หนึ่งรายการสำหรับข้อมูลทั้งหมดสำหรับหน้าหรือไม่ หรือเราสร้างการสืบค้นข้อมูลที่มีขนาดเล็กลงเพื่อโหลดข้อมูลสำหรับส่วนต่างๆ ของแอป ทั้งสองอย่างที่คุณอาจจินตนาการได้ พวกเขามีข้อเสียของตัวเอง เพียงเพราะถ้าคุณมีแบบสอบถามขนาดใหญ่ คุณกำลังรอฟิลด์เพิ่มเติม

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

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

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

Drew: และนั่นก็ง่ายพอ ๆ กับการสืบค้นข้อมูลหรือไม่? การเรียกการกลายพันธุ์นั้นง่ายหรือไม่?

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

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

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

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

อีฟ: ฉันคิดว่าสถานที่ที่ GraphQL อาจต้องดิ้นรนคือการสร้างแผนที่แบบหนึ่งต่อหนึ่งของ-

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

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

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

อีฟ: ครับ และฉันคิดว่ามีคนฟังและไม่เห็นด้วยกับฉันในเรื่องนั้น เพราะมีเครื่องมือที่ดีสำหรับสิ่งนั้นเช่นกัน แต่ฉันคิดว่าจุดที่ GraphQL โดดเด่นจริงๆ คือขั้นตอนของการแยกตรรกะไปยังเซิร์ฟเวอร์ ทำให้นักพัฒนาส่วนหน้ามีอิสระในการกำหนดส่วนประกอบหรือข้อกำหนดด้านข้อมูลส่วนหน้า และจัดการสคีมาในฐานะทีมอย่างแท้จริง

Drew: มีอะไรที่สร้างขึ้นในภาษาคิวรีเพื่อจัดการกับการแบ่งหน้าของผลลัพธ์ หรือเป็นการใช้งานแบบกำหนดเองตามความจำเป็นหรือไม่

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

Drew: มี gotcha ขนาดใหญ่ที่เราควรรู้เกี่ยวกับการใช้ GraphQL หรือไม่ สมมติว่าฉันกำลังจะปรับใช้การติดตั้ง GraphQL ใหม่สำหรับองค์กรของฉัน เราจะสร้างปลายทาง API ใหม่ทั้งหมดโดยใช้ GraphQL นับจากนี้เป็นต้นไป ฉันควรรู้อะไร มีอะไรแอบแฝงอยู่ในพุ่มไม้หรือไม่?

อีฟ: ซุกตัวอยู่ในพุ่มไม้พร้อมกับเทคโนโลยีเสมอใช่ไหม? ฉันคิดว่าสิ่งหนึ่งที่ไม่ได้สร้างไว้ใน GraphQL แต่สามารถใช้งานได้โดยไม่ต้องยุ่งยากมากนักคือความปลอดภัยของ API ตัวอย่างเช่น คุณบอกว่าถ้าฉันมีคำถามจำนวนมาก เราพูดคุยเกี่ยวกับเรื่องนี้ด้วยการอนุญาต แต่การเปิด API นั้นน่ากลัวด้วย ซึ่งใครบางคนสามารถส่งข้อความค้นหาที่ซ้อนกันขนาดใหญ่ เพื่อนของเพื่อน เพื่อนของเพื่อน เพื่อนของเพื่อน ลงและลงโซ่ จากนั้นคุณก็อนุญาตให้คนอื่นทำ DDoS คุณได้ด้วยข้อความค้นหาจำนวนมากเหล่านี้ So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. อย่างแน่นอน.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. คุณมีคำพรากจากกันบ้างไหม?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. ฉันรู้สึกทราบซึ้ง.