จดจาก Build GraphQL APIs (Go)

สัปดาห์ที่แล้วมาเป็นคนสอน docker สัปดาห์นี้วนมาเป็นนักเรียนบ้างครับ โดยรอบนี้ลองมาฟังตัว GraphQL วางมันจะต่างกับ REST แบบเดิมๆที่ใช้กันยังไง โดย Course นี้สอนโดยพี่ปั๊บ (Dev Mountain) ครับ ได้ความรู้เยอะครับ มีประสบการณ์ที่เจอมาเล่าด้วยนะ

สำหรับผมก่อนมาเรียน อยากลองมาไล่ GraphQL ของ GitLab บางทีข้อมูลที่อยากได้มันยิงหลายรอบมาก และมาแก้พวก Get ที่ยิบย่อยที่เจอๆกัน

แปะไว้ด้วยดีกว่า มีอีกบทความ / Post ที่บอกอีกมุมมองนึงนะ เอาไว้มาหาคำตอบตอนเรียน

ที่เรียนมา ผมมีจดๆบางส่วนมานะ ตามนี้เลย

ทำไมต้อง GraphQL ?

ปัญหาแบบเดิมๆ

  • หน้าเว็บ 1 หน้า กว่าจะได้ข้อมูลมาครบ ต้องยิงขอข้อมูลหลาย Request มันใช้ network และมี latency เพิ่มด้วย บางหน้าใช้ 1-2 API แต่ถ้าเยอะๆ หลัก 10 - 20 ++ เลยก็มี
  • ข้อมูลชุดเดียวกัน แต่มีการ Request ที่แตกต่างกัน
    - หน้านี้แสดงข้อมูลสรุป เอามา 5 Field > API 1
    - หน้านี้แสดงข้อมูลเต็ม ดึงมาหมด 108 Field ตอนนี้มี 2 API และ
    - สำหรับ Mobile อีก จอมันเล็ก เอาสัก 10 Field ที่สำคัญพอ ถ้าแยก Platform IOS / Android / WP10 อาจจะได้อีก 3 API รวม 5 //WP10 ตายไปแล้วแต่ซากอารยธรรมมันยังอยู่ 555
    เอาจริงๆใน Code มี DTO xxxMini / xxxxM บราๆ

แล้วที่นี้ Facebook เห็นปัญหา งานมาเยอะ และทำงานซ้ำซ้อน เลยทำ GraphQL ขึ้นมา โดยที่

  • แต่ละ Client มาเลือก Field ได้
  • ฝั่ง Backend ที่ API กลางๆ ปรับให้ยึดหยุ่นกับทาง Client (Front-End) ระดับนึง
    - มี property ที่เป็นไปได้ทั้งหมด
    - มี field + argument > มองเป็น method ให้ใช้งาน
    - อาจจะทำ directive ผมมองพวก Utility Function ของ SQL แบบพวก Concat / Sum / Min / Max อะไรงี้

GraphQL มีรูปร่างอย่างไร ?

สิ่งที่สำคัญของ GraphQL เราต้องมากำหนด Schema มันอารมณ์แบบ Swagger ที่ Gen ออกมา เพื่อบอกว่ากับ Client เรามีรูปแบบอย่างไร โดยมี Keyword ที่สำคัญ

  • Query - ส่วนของการดึงข้อมูล ถ้าใช้ REST HTTP GET แหละ แต่เรามีลูกเล่น เรียก func ที่กำหนด ส่ง argument และอยากได้ผลลัพธ์มี Field อะไรบ้าง
  • Mutation ส่วนเปลี่ยนแปลงข้อมูล Create Update Delete ข้อมูล
  • Subscription - จะเป็นงานที่ต้องการข้อมูล Realtime

ก่อนนำมาจัดในส่วน Query / Mutation / Subscription สิ่งที่เราต้องทำก่อน มี Resource อะไรบ้าง มี Keyword เพิ่ม

  • Type - ข้อมูลที่เราจะให้ Client เห็น หรือปรับได้ อาจจะ map กับ Struct ตัวอย่างใน Course เป็น Go ถ้าภาษาอื่นๆ พวก DTO / Class
  • Field - บอกว่า method อะไร ให้ใช้บ้าง
  • Argument - method นั้นส่งอะไรได้บ้าง
  • Resolver (Field Resolver) - หลังจากไปกำหนดนิยาม ใน Schema แล้ว ใครเป็นคนทำหน้าที่จริงๆ ส่วน Business Logic นั้นแหละ

เมื่อ Build ได้ Schema ดูที่หน้า Explorer ได้เลย

GraphQL ถ้าเอามาใช้กับระบบ มันอยู่จุดไหน

ผมเองตอนนี้เข้าใจว่า มันส่วน Presentation Layer นะ เดิมมี REST ตอนนี้มี GraphQL เข้ามาเพิ่ม เพื่อเป็นทางเลือก แต่ชั้น Service / Data Access (Repository) ยังทำเหมือนเดิม Select เท่าไหร่ ทำแบบเดิม แต่ตัว GraphQL มาช่วยให้ Client Customize ได้นิดหน่อย แบบ เพิ่ม-ลด property ของ result

แต่ข้างหลังยัง Query อะไรเหมือนเดิมนะ

ฝั่ง Client เราอาจจะยิง json ที่มีความหมายบางอย่างในเรื่องของเราเอง หรือ อาจจะใช้ Query Param / Path Param แต่ตัว GraphQL มี Syntax ของตัวเองนะ ว่าจะดึงอะไร Query ของ อะไร เรียกผ่าน Function + Argument ไหน แล้วได้ผลลัพธ์อะไร หรือ Mutation มี เช่นกัน

pattern ตามนี้ สำหรับ Query ฝั่ง client ต้องปรับตัวด้วย เช่นกัน ตอนนี้มี Lib มาช่วยแล้ว apollo client

{
  contacts {
    gets(searchText:""){
      name
      contact_id
    }
  }
}

ผสมก็ได้นะ

ถ้ามีหลาย Microservice อาจจะเพิ่ม Layer BFF เข้ามาประสานก็ได้

มี GraphQL ถ้าจะให้ดี ต้องทำตัว API Management

มีหลายตัวเลยที่ได้ฟังมาวันนี้ เช่น

  • Authentication - JWT
  • Authorization คุมการใช้ Resource พวก Field นั่นแหละ
    - เขียนไปเพิ่งนึกได้ ถ้ามีเคสแบบ PDPA เราไปตัดจาก Response ได้นี่ สุดท้าย GraphQL ได้ json ออกมา
  • Pagination - แบ่งหน้าแหละ จะได้ไม่ต้องดึงมาหมด
  • ทำ Data Validation ทั้งตอนส่งไป Query และทำ Mutation อันนี้เป็น Lib ของแต่ละภาษาทำเลย
  • Audit Log - เก็บอะไร เพื่อติดตาม Action ได้ การจัดการพวกใครทำอะไรที่ไหนนะ
    ควรทำอะไรบ้าง
    - Async Process / UDP
    - Chunk File กัน Process เจอไฟล์ Lock
    - จัดการกับพวก Log ยังไง เอาไปเก็บส่วนกลาง Realtime / Batch มีผลกับ Cost
    - ใช้ของที่มีคนทำแล้ว
  • Rate Limit มี 2 Level
    - App
    - API Gateway
  • Circuit Breaker - ที่ผมเข้าใจต้องคุย Business ก่อน ว่าอะไรปล่อยพังได้ แล้วให้คนมาทำงานมือ Reconcile ที่หลัง เคสที่เจอเป็น 3rd party Api ตุย เราจดไว้ก่อน เดี๋ยวไปจัดการหลังบ้าน
  • อะไรที่มัน Common ทำเป็น Middleware จะได้ Inject ใส่เข้าไปได้
  • Documentation - GraphQL มี Doc อยู่แล้ว ตัว Schema + Query Tools แต่ต้องคุมสิทธิ คนร้ายเห็นเหมือนกัน
  • Caching
    - ปกติทำทุก Layer Client (แต่ละคุม TTL ยาก) <--> App (CDN / memory / Redis) <--> Data Store (DB Sclae ท้ายสุด
    - Caching Strategies
Ref: Top caching strategies - by Alex Xu - ByteByteGo Newsletter

ระวังการ Design Key ในการ Access Cache แต่ละ Tools มีข้อจำกัดกันไปคนละแบบ

  • Observability / Monitoring
    - Open Telemetry เพิ่มใน App / Infra
    - ตัวใหม่ Grafana Beyla OSS | eBPF-based auto-instrumentation อ่านจะ Kernel เลย ลดการ Instrument จาก Code
  • Batch Process
  • Federation - ถ้ามีหลายๆ GraphQL จะเชื่อมยังไง
    - Introduction to Apollo Federation | Apollo GraphQL Docs
    - เขียน Code Handle พี่ปั๊บแนะนำว่าใช้ JS/TS ง่ายสุด เพราะ GraphGL มันมาจาก JS ตอนแรก

จริงๆตัวเรื่อง API Management มาตอบบทความ หรือ Post ที่เห็นต่างข้างต้นได้นะ ปล. ผมมาอ่านที่หลังตอนเรียนจบและ

อ่าจบและ บางอันอาจจะเขียนผิดตอนนี้นะ 555 เดวไปลองเล่นตัวของ dotnet ก่อน กับแงะตัวอย่าง Go ที่ได้มา dotnet เห็น 2 ค่าย

Reference


Discover more from naiwaen@DebuggingSoft

Subscribe to get the latest posts sent to your email.