GraphQL น่าหงุดหงิดนิดหน่อย

• GraphQL นั้นยอดเยี่ยม แต่ดูเหมือนจะถูกโหมเกินจริงไปหน่อย
• ดูเหมือนว่านักพัฒนามือใหม่ถึงระดับกลางจะดู YouTube แล้วหันมาใช้ GraphQL ซึ่งน่าจะเป็นแนวทางที่ผิด
• ข้อดี
  • อธิบายข้อมูลที่ต้องการได้ง่าย
  • ประหยัดแบนด์วิดท์ ดึงมาได้เท่าที่ต้องการในครั้งเดียว
  • สร้างเอกสารสำหรับผู้ใช้ข้อมูลได้ง่าย
  • ใช้งาน subscriptions ได้ง่ายขึ้น
  • สามารถรวมการเรียก API หลายครั้งเข้าด้วยกันได้
• ข้อเสีย
  • ในการใช้งานจริงมันทรมานมาก ถ้าแบ็กเอนด์ที่ใช้ไม่ได้สร้างโค้ดในภาษาของคุณให้ คุณจะต้องดูแล type system ตั้งแต่ 2 ชุดขึ้นไป
  • ไม่รองรับ map/table/dictionary ซึ่งเป็นเรื่องใหญ่มาก แม้จะไม่อยากทำ แต่สุดท้ายที่ไหนสักแห่งก็ต้องใช้ {[key: string] : T}
  • ไม่มีแนวทางที่ชัดเจนสำหรับการทำ API versioning สุดท้ายคุณอาจลงเอยด้วยอะไรอย่าง MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
• ถ้าคุณไม่ได้กำลังจัดการชุดปัญหา/แนวทางแก้ที่ Facebook ตั้งใจให้ GraphQL ใช้รับมือ ก็อย่าใช้ GraphQL
• นักพัฒนาอาวุโสท่านอื่น ๆ พอจะมีคำแนะนำดี ๆ อะไรที่จะช่วยไม่ให้นักพัฒนารุ่นใหม่ตกหลุมนี้ได้บ้างไหม?

ความคิดเห็นจาก HN

• ปัญหาใหญ่ที่สุดของ GraphQL คือคุณต้องลงแรงเพื่อป้องกันการโจมตีแบบ DOS หรือคนที่พยายามดาวน์โหลดทั้งฐานข้อมูลของคุณ
  • มันง่ายมากที่จะสร้างคิวรีที่ทำให้ระบบของคุณรับภาระหนักเกินไป
  • ถ้าอยากเห็นว่าต้องทำอะไรบ้าง ให้ดู Shopify พวกเขาจำกัดอัตราตามปริมาณข้อมูลที่ส่งกลับ และจัดการทั้ง cursor กับ pagination ด้วย ต่างจากตัวอย่าง GraphQL สวย ๆ บนอินเทอร์เน็ต สคีมาของจริงนั้นใหญ่และไม่น่าดู
• GraphQL เป็นวิธีที่ยอดเยี่ยมในการแก้ปัญหาเชิงองค์กรที่บริษัทเทคขนาดใหญ่มี
  • เช่นกรณีที่ทีมดูแล API กับทีมที่ขอให้มีการเปลี่ยนแปลงเป็นคนละทีมกัน
  • เมื่อองค์กรใหญ่พอ การรอให้มีการเปลี่ยนแปลงอาจกินเวลานานมาก GraphQL จึงช่วยลดปัญหานั้นได้
  • แต่ถ้าเป็นองค์กรเล็ก ทำไมไม่ลงมือเพิ่มส่วนที่ขาดเข้าไปเองล่ะ?
• ไม่ว่าจะตั้งใจหรือไม่ GraphQL ทำให้นักพัฒนาฝั่งฟรอนต์เอนด์แยกตัวออกจากข้อจำกัดด้านการร้องขอแบ็กเอนด์ และเคลื่อนที่ได้เร็วขึ้น
  • เมื่อนักพัฒนาแบ็กเอนด์สร้าง data model แล้วเปิดให้ใช้งานผ่าน GraphQL นักพัฒนาฝั่งฟรอนต์เอนด์ที่ไม่เคยเจอคนทำแบ็กเอนด์คนนั้นเลยก็ใช้ต่อได้ทันที
  • สามารถเปลี่ยนสิ่งที่คิวรีได้สด ๆ แล้วดึงสิ่งที่ต้องการไปใช้ได้
  • ทำให้ทุกคนเดินหน้าได้เร็วขึ้น
  • แต่ในฐานะนักพัฒนาแบ็กเอนด์ ฉันเกลียด GraphQL มากจริง ๆ

[bichi]

GraphQL นี่ค่อนข้างน่าหงุดหงิดนะ ไม่ได้ถึงกับน่าหงุดหงิดมากหรอก ก็แค่ชวนหงุดหงิดอยู่บ้าง แต่เพราะมันช่วยลดต้นทุนการสื่อสารระหว่างคนในทีมได้อย่างชัดเจน การเอาเวลานั้นไปแก้ส่วนที่น่าหงุดหงิดจึงมีประสิทธิภาพกว่ามาก แล้วหน้าตามันก็ไม่สวยจริง ๆ แต่ผมก็ยังแนะนำให้ใช้ GraphQL นะ เพราะคงไม่มีใครเห็นด้วยหรอกถ้าจะบอกว่าไปใช้ tRPC กันเถอะ คนส่วนใหญ่แทบยังไม่เคยลองใช้อย่างจริงจังด้วยซ้ำ แต่กลับเดาเอาเองแล้วปฏิเสธการใช้เทคโนโลยี และถ้าจะจัดการเรื่องนั้นก็ต้องใช้การผลักดันแบบมีอำนาจมาก ๆ ซึ่งถ้าฝืนดันสัก 1-2 เทคโนโลยีก็พอทำได้ แต่ถ้าจะดันทุกอย่างพร้อมกัน สุดท้ายสิ่งที่เสียไปจะมากกว่า ก็เลยทำไม่ได้... เพราะงั้นระดับที่พอจะโน้มน้าวกันได้มากที่สุด สุดท้ายก็คือ GraphQL เฮ้อๆ REST ห่วย ๆ นี่แหละ เทคโนโลยียุคหินแย่ ๆ ที่ทำให้ต้นทุนการสื่อสารสูงมหาศาลจริง ๆ เฮ้อๆ

[alucard]

นี่เป็นครั้งแรกเลยที่อ่าน GeekNews แล้วเจอบทความที่ทำให้อยากสมัครสมาชิก ผมลองไปตอบไว้ในส่วน The bad แล้วครับ

แม้จะมีทั้งข้อดีข้อเสียจากมุมมองของฝั่งไคลเอนต์/เซิร์ฟเวอร์แยกกัน แต่ถ้ามองรวมกันแล้ว GraphQL schema เข้ามาเติม abstraction layer ที่ขาดหายไประหว่างเซิร์ฟเวอร์กับไคลเอนต์ ซึ่งเป็น value proposition ที่ใหญ่ที่สุดอยู่แล้ว ดังนั้นพอรู้ข้อนี้แต่ยังจะบอกว่าสำหรับโปรดักต์ทั่วไปควรพิจารณา REST ผมเลยรู้สึกเป็นการพูดแบบยุคเก่าไปหน่อย
The bad

• It is actually a pain to use, depending on the backend you are using you'll have to manage
  two or more type systems if there are no code first generates in your language
  สุดท้ายถ้าพูดอีกแบบก็คือ ถ้าใช้ให้ถูกมันก็ดี? เรื่อง code generation อะไรพวกนี้เดี๋ยวนี้ไม่ใช่ปัญหาแล้วมั้ง tooling พัฒนาไปไกลแค่ไหนแล้ว
• It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
  some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
  เรื่องนี้มีพูดถึงใน Production Ready เหมือนกัน แต่ถ้าใช้ข้อดีของ Type System ให้เป็น ก็ดูเหมือนไม่ใช่เรื่องที่ต้องกังวลเท่าไรนะ ไม่ใช่ key: string แต่ระบุฟิลด์ให้ชัดเจนไปเลยก็จบ..
• No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
  เดิมที GraphQL ก็เป็นแบบ versionless อยู่แล้ว....
  Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
  ฟังดูเหมือนกับการบอกว่า React ก็ไม่ควรใช้ถ้าไม่ได้กำลังแก้ปัญหาแบบที่ Facebook ตั้งใจให้มันแก้เลยนะ

[bichi]

สวัสดีครับ เห็นด้วยมากครับ พอจะขอรู้จักกันไว้ได้ไหมครับ ผมต้องการคนที่คิดเหมือนกันแบบนี้จริง ๆ การโน้มน้าวคนอื่น ๆ (สมาชิกทีม) ยากมากครับ

[alucard]

ฮ่าๆ ผมเพิ่งมาเห็นคอมเมนต์ช้าไปหน่อย..!! ใน Slack ของ GraphQL Korea ผมใช้ชื่อเล่นว่า Alucard :)

[sixmen]

ผมนำ GraphQL มาใช้ค่อนข้างตั้งแต่ช่วงแรก ๆ แต่ตอนนั้นคำอธิบายส่วนใหญ่มักเน้นฝั่งแบ็กเอนด์

เลยทำให้รู้สึกว่าอาจมีการมองกันว่ามันน่าจะดีสำหรับฝั่งแบ็กเอนด์อยู่บ้าง

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

[bbulbum]

#แต่ในฐานะนักพัฒนาแบ็กเอนด์ ฉันเกลียด GraphQL มากจริง ๆ
เห็นด้วยครับ..

[ifmkl]

คำว่าใช้ให้ถูกที่ถูกเวลาผุดขึ้นมาในหัวเลยครับ

[kbumsik]

ไม่ว่าจะตั้งใจหรือไม่ก็ตาม GraphQL ช่วยให้นักพัฒนาฝั่งฟรอนต์เอนด์แยกตัวออกจากข้อจำกัดด้านความต้องการของนักพัฒนาฝั่งแบ็กเอนด์ และเคลื่อนไหวได้เร็วขึ้น

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

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

[hwasurr]

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

อีกด้านหนึ่ง ผมก็แอบคิดว่าเหตุผลหนึ่งที่ GraphQL โดนโจมตี อาจเป็นเพราะมันพยายามขายภาพลักษณ์ว่า "ใช้ง่าย" ด้วยหรือเปล่า(?) นะครับ

[jjpark78]

ตอนช่วงแรก ๆ ที่ GraphQL ออกมาและทำโปรเจกต์ POC กัน ยังไม่มีเอนจินที่รองรับ multipart ได้อย่างเหมาะสม เลยจำได้ว่าลำบากพอสมควรครับ..

[gjen6s]

ผมเองก็คิดมานานแล้วว่า เวลาเห็นคนบอกว่าใช้ GraphQL ในโปรเจ็กต์เล็ก ๆ มันไม่โอเวอร์สเป็กไปหน่อยเหรอ.. ดูเหมือนว่าทุกคนก็คิดคล้าย ๆ กันนะ

[xguru]

ฉันลองย้ายมาแค่คอมเมนต์ช่วงแรก ๆ ก่อน มีคอมเมนต์มากกว่า 400 อัน เลยอ่านทั้งหมดก็ค่อนข้างยากเหมือนกัน