ข้อมูลเบื้องต้นเกี่ยวกับ Hasura GraphQL Engine สำหรับ Dynamic API ด้วย PostgreSQL

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

GraphQL: กบฏ Facebook

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

สถาปัตยกรรมส่วนที่เหลือ

โดยทั่วไปแล้ว API คือกฎ รูทีน หรือโปรโตคอลที่ระบุวิธีที่คอมโพเนนต์ซอฟต์แวร์ควรโต้ตอบ Representational State Transfer (REST) ​​นั้นเป็นสถาปัตยกรรมการออกแบบ API ที่ปกติแล้วจะใช้ในการใช้บริการเว็บ ซึ่งทุกอย่างถือเป็น 'ทรัพยากร' น่าเสียดายที่ระเบียบวิธี RESTful ถูกจำกัดให้จัดการกับทรัพยากรเพียงแหล่งเดียวอย่างต่อเนื่อง ดังนั้น หากจำเป็นต้องใช้ข้อมูลและมาจากแหล่งข้อมูลตั้งแต่สองแหล่งขึ้นไป เช่น โพสต์และผู้ใช้ การเดินทางหลายรอบไปยังเซิร์ฟเวอร์จะต้องรวบรวมทุกสิ่งที่จำเป็น นอกจากนี้ REST ยังประสบปัญหาเกี่ยวกับการดึงข้อมูล 'over' และ 'under' ทั้งหมดนี้ไม่เหมาะ โดยเฉพาะอย่างยิ่งเมื่อมีแอพที่ขับเคลื่อนด้วยข้อมูลมากขึ้นซึ่งจัดการชุดข้อมูลขนาดใหญ่ที่รวมทรัพยากรที่เกี่ยวข้อง ซึ่งสามารถอธิบายสถานการณ์ที่ Facebook เผชิญได้

ดังนั้น ความต้องการสถาปัตยกรรม API ที่จะต้องใช้วิธีการที่ยืดหยุ่นและก้าวหน้ามากขึ้น

การสร้างทางเลือก

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

ความเรียบง่าย ความเสถียร และประสิทธิภาพ

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

ข้อดีของ GraphQL

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

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

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

กรณีการใช้งาน GraphQL ในการพัฒนา API

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

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

PostgreSQL คืออะไร?

ในฐานะที่เป็นระบบจัดการฐานข้อมูลเชิงสัมพันธ์ที่ขับเคลื่อนโดยชุมชนฟรี PostgreSQL ไม่ได้เป็นเจ้าของโดยบริษัทใดบริษัทหนึ่ง Postgres ถือเป็น RDBMS ที่ทรงพลังและสอดคล้องกันภายในมากที่สุด ซึ่งเขียนด้วยภาษา C และรองรับภาษาการเขียนโปรแกรมจำนวนมาก เช่น C/C++, JavaScript, Java, Python, R, Go, Lisp, .Net เป็นต้น เป็นที่ต้องการมากขึ้นในหมู่คนส่วนใหญ่ นักพัฒนาแบบฟูลสแตก PostgreSQL มีคุณลักษณะที่หลากหลายมากกว่า MySQL น้องสาว ซึ่งได้รับความนิยมเนื่องจากคุณลักษณะ ความสามารถในการปรับขนาดและประสิทธิภาพ PostgreSQL เป็นที่นิยมในโครงการที่มีข้อกำหนดเกี่ยวกับขั้นตอนที่ซับซ้อน การออกแบบที่ซับซ้อน การผสานรวมตามความต้องการ และความสมบูรณ์ของข้อมูล

ข้อดีของ Postgres สำหรับนักพัฒนา Full-Stack

โดยทั่วไป คุณสมบัติต่างๆ เช่น การค้นหาข้อความแบบเต็ม คอลัมน์ JSON การจำลองแบบลอจิคัล ทำให้ Postgres เหนือกว่า MySQL สิ่งนี้เหมาะสมที่สุดสำหรับความต้องการด้านประสิทธิภาพของฐานข้อมูลเชิงพาณิชย์ทั่วไป ในขณะที่อนุญาตให้รวมระบบฐานข้อมูลหลายระบบเข้าเป็นหนึ่งเดียวโดยมีค่าใช้จ่ายและค่าใช้จ่ายที่น้อยลง นอกจากนี้ ฟีเจอร์ล่าสุดสำหรับ Key-Value-Storage (ประเภทคอลัมน์ JSON / JSONB) ทำให้เป็นทางเลือกที่เหมาะสมกับฐานข้อมูล NoSQL นอกจากนี้ยังรองรับการทำคลัสเตอร์หรือมาสเตอร์-ทาส-สถาปัตยกรรม ทำให้เหมาะสำหรับสภาพแวดล้อมที่เหมือนคลาวด์ นอกจากนี้ ส่วนขยาย foreign-data-wrapper ที่เป็นที่นิยมยังช่วยให้สามารถสืบค้นแหล่งข้อมูลภายนอกได้โดยตรงจากภายใน PostgreSQL เมื่อจำเป็น โดยเฉพาะอย่างยิ่ง เหมาะที่สุดสำหรับระบบที่ต้องใช้การสืบค้นที่ซับซ้อน คลังข้อมูล และการวิเคราะห์ข้อมูลแบบไดนามิก

ตามจริงแล้ว PostgreSQL รองรับคุณสมบัติบางอย่างที่ MySQL ไม่รองรับได้ดีกว่า ตัวอย่างเช่น ตรวจสอบข้อจำกัด ประเภทข้อมูลที่หลากหลาย (เช่น อาร์เรย์ แผนที่ JSON) การสนับสนุนเชิงพื้นที่ที่สมบูรณ์ยิ่งขึ้น (PostGIS) และการสนับสนุนข้อความแบบเต็มที่สมบูรณ์ยิ่งขึ้น นอกจากนี้ ยังสนับสนุนการสร้างดัชนีที่ไม่บล็อก ดัชนีบางส่วน นิพจน์ตารางทั่วไป และฟังก์ชันการวิเคราะห์แบบไดนามิกมากขึ้น อย่างไรก็ตาม PostgreSQL ให้การสนับสนุน SLL ดั้งเดิมสำหรับการเชื่อมต่อสำหรับการเข้ารหัสการสื่อสารของไคลเอ็นต์/เซิร์ฟเวอร์ ตลอดจนการเพิ่มประสิทธิภาพในตัวที่ชื่อว่า SE-PostgreSQL ซึ่งให้การควบคุมการเข้าถึงเพิ่มเติมตามนโยบาย SELinux

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

ข้อได้เปรียบหลักอีกประการของสถาปัตยกรรม Postgres คือความสามารถในการขยายได้เฉพาะตัว อนุญาตให้ผู้ใช้เพิ่มคุณสมบัติ เช่น ชนิดข้อมูล วิธีการเข้าถึงดัชนี ภาษาโปรแกรมเซิร์ฟเวอร์ โปรแกรมห่อข้อมูลต่างประเทศ (FDW) และส่วนขยายที่โหลดได้ โดยไม่ต้องเปลี่ยนรหัสระบบหลัก มันใช้ประโยชน์จากสถาปัตยกรรมโปรเซสเซอร์แบบมัลติคอร์ที่ทันสมัย ​​ดังนั้นจึงช่วยให้ประสิทธิภาพเพิ่มขึ้นเกือบเป็นเส้นตรงเมื่อจำนวนคอร์เพิ่มขึ้น นี่เป็นสิ่งสำคัญโดยทั่วไป คุณสมบัติต่างๆ เช่น การค้นหาข้อความแบบเต็ม คอลัมน์ JSON การจำลองแบบลอจิคัล ทำให้ Postgres ได้เปรียบใน MySQL สิ่งนี้เหมาะสมที่สุดสำหรับความต้องการด้านประสิทธิภาพของฐานข้อมูลเชิงพาณิชย์ทั่วไป ในขณะที่อนุญาตให้รวมระบบฐานข้อมูลหลายระบบเข้าเป็นหนึ่งเดียวโดยมีค่าใช้จ่ายและค่าใช้จ่ายที่น้อยลง นอกจากนี้ ฟีเจอร์ล่าสุดสำหรับ Key-Value-Storage (ประเภทคอลัมน์ JSON / JSONB) ทำให้เป็นทางเลือกที่เหมาะสมกับฐานข้อมูล NoSQL นอกจากนี้ยังรองรับการทำคลัสเตอร์หรือมาสเตอร์-ทาส-สถาปัตยกรรม ทำให้เหมาะสำหรับสภาพแวดล้อมที่เหมือนคลาวด์ นอกจากนี้ ส่วนขยาย foreign-data-wrapper ที่เป็นที่นิยมยังช่วยให้สามารถสืบค้นแหล่งข้อมูลภายนอกได้โดยตรงจากภายใน PostgreSQL เมื่อจำเป็น โดยเฉพาะอย่างยิ่ง เหมาะที่สุดสำหรับระบบที่ต้องใช้การสืบค้นที่ซับซ้อน คลังข้อมูล และการวิเคราะห์ข้อมูลแบบไดนามิก

ข้อเสียของ PostgreSQL

โดยทั่วไป หากคุณต้องการมาตรฐาน ANSI SQL ให้พิจารณา PostgreSQL แม้ว่าคุณจะชอบมาตรฐาน ODBC มากกว่า ก็เลือกใช้ MySQL น่าเสียดายที่ Postgres มีประสิทธิภาพในการทำงานต่ำในบางครั้งด้วยสภาพแวดล้อมการผลิตแบบสด "เสมอ" ข้อเสียเพิ่มเติมของ Postgres คือความจริงที่ว่าการจำลองแบบถูกนำไปใช้ในระดับเอ็นจิ้นการจัดเก็บข้อมูล ทำให้มีราคาแพงกว่าการจำลองแบบของ MySQL ซึ่งมีความสมบูรณ์มากกว่าและใช้งานที่ "ระดับเอ็นจิ้นการสืบค้น"

ข้อมูลเบื้องต้นเกี่ยวกับเครื่องยนต์ Hasura GraphQL

เนื่องจากเราได้กล่าวถึงการพัฒนา GraphQL API และ PostgreSQL โดยสังเขป เราควรมีบริบทเพียงพอสำหรับการแนะนำเครื่องมือ Hasura GraphQL โดยพื้นฐานแล้ว Hasura เป็นเพียงเอ็นจิ้น GraphQL สำหรับ PostgreSQL RDBMS ซึ่งให้วิธีการบูตที่ง่ายขึ้นและจัดการการพัฒนา GraphQL API ในการหวนกลับ Hasura เป็นโซลูชันเดียวที่พร้อมใช้งานซึ่งจะเพิ่ม GraphQL-as-a-Service ลงในแอปพลิเคชันที่ใช้ PostgreSQL ที่มีอยู่ทันที โดยพื้นฐานแล้ว เลี่ยงงานที่ใช้เวลานานในการเขียนโค้ดส่วนหลังที่ประมวลผล GraphQL

Hasura Simplified

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

Hasura แก้ปัญหาอะไรในการพัฒนา API

โดยทั่วไป Hasura จะทำให้การจัดการวงจรชีวิตของ API ง่ายขึ้นในระหว่างการใช้งานการผลิตขนาดใหญ่โดยเฉพาะอย่างยิ่งสำหรับ API ที่ซับซ้อน เหนือสิ่งอื่นใด GraphQL Engine ดึงดูดนักพัฒนาแบบ full-stack ที่ backlog กับโครงการพัฒนา API ระดับองค์กรที่ใช้ฐานข้อมูล PostgreSQL ที่มีอยู่ ตามหลักการแล้ว เนื่องจาก GraphQL อนุญาตให้มีวงจรการพัฒนา API ที่รวดเร็วปานสายฟ้า Hasura จึงมอบวิธีการที่ง่ายขึ้นสำหรับองค์กรในการย้ายไปยัง GraphQL ทีละส่วน โดยไม่ส่งผลกระทบต่อแอปพลิเคชัน ฐานข้อมูล หรือผู้ใช้ที่มีอยู่ นอกจากประสิทธิภาพที่เบาและประสิทธิภาพสูงแล้ว เครื่องยนต์ยังมาพร้อม UI ของผู้ดูแลระบบ ช่วยให้คุณสำรวจ GraphQL API และจัดการสคีมาฐานข้อมูลและข้อมูลของคุณแบบเห็นภาพได้

ข้อดีของ Hasura

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

ประการที่สอง เอ็นจิ้น Hasura GraphQL ทำให้ง่ายต่อการดึงข้อมูลที่ต้องการด้วยการสืบค้นเพียงครั้งเดียว ซึ่งทำได้โดยอนุญาตให้คุณเพิ่มมุมมองเป็นความสัมพันธ์กับตารางหรือมุมมองอื่นๆ นอกจากนี้ยังอนุญาตให้เขียนตัวแก้ไขแบบกำหนดเองด้วย schema-stitching และการรวมฟังก์ชันแบบไร้เซิร์ฟเวอร์หรือ microservice API ที่ได้รับการทริกเกอร์ในเหตุการณ์ฐานข้อมูล สิ่งนี้มีประโยชน์และอำนวยความสะดวกในการสร้างแอพ 3factor ตามความเป็นจริงแล้ว Hasura เป็นเครื่องยนต์ที่มีน้ำหนักเบามาก ในการหวนกลับ มันใช้ RAM สูงสุด 50MB เท่านั้น แม้ว่าจะให้บริการมากกว่า 1,000 คำขอ/ต่อวินาที ผลตอบแทนการลงทุนที่ยอดเยี่ยม!

โดยเฉพาะอย่างยิ่ง Hasura ยังอำนวยความสะดวกในการอนุญาตและรับรองความถูกต้องระดับข้อมูล API อย่างละเอียดอีกด้วย อนุญาตให้เชื่อมต่อกับผู้ให้บริการตรวจสอบสิทธิ์ที่ต้องการผ่าน webhook, JWT, Auth0 หรือการใช้งานที่กำหนดเอง ดังนั้น การกำหนดบทบาทสำหรับผู้ใช้ การกำหนดว่าใครสามารถเข้าถึงข้อมูลต่างๆ เช่น ผู้ดูแลระบบ ผู้ใช้ที่ไม่ระบุชื่อ เป็นต้น โดยทั่วไป ระบบควบคุมการเข้าออกแบบละเอียดจะขึ้นอยู่กับโครงสร้างตารางฐานข้อมูลที่คล้ายกับสคีมา GraphQL นอกจากนี้ กฎการอนุญาตแบบกำหนดเองได้รับการกำหนดอย่างเคร่งครัดตามการดำเนินการและค่าของฐานข้อมูล

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

Hasura ใช้กรณี

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

ข้อจำกัดของ Hasura เล็กน้อย

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

บทสรุป

โดยสรุป เมื่อ GraphQL เติบโตขึ้น จะทำให้การพัฒนา API ภายในองค์กรง่ายขึ้นอย่างมาก เพื่อสร้างในระดับเว็บ ด้วยการนำ GraphQL ไปใช้ในวงกว้างอย่างรวดเร็วในกลุ่มอุตสาหกรรมที่หลากหลาย Hasura มีศักยภาพในการสร้างและจัดการ API แบบอัตโนมัติเพิ่มเติมด้วยเทคโนโลยีมาตรฐานอุตสาหกรรมที่เลือก GraphQL และ Postgres Hasura ช่วยลดความยุ่งยากในการสร้าง CRUD (สร้าง อ่าน อัปเดต และลบ) แบ็กเอนด์ GraphQL ที่สำคัญกว่านั้น Hasura เป็นตัวเลือกที่ดีที่สุดและเป็นทางเลือกเดียวหากคุณเริ่มต้นจากศูนย์ด้วย GraphQL-centric API และ Postgres โดยไม่ต้องเขียนโค้ดแบ็กเอนด์ สำหรับข้อสงสัยหรือคำปรึกษาเกี่ยวกับความเป็นไปได้ในองค์กรของ GraphQL และ Hasura โปรดติดต่อเรา นั่นคือข้อมูลเบื้องต้นที่เราแนะนำ Hasura GraphQL Engine