บันทึกการอ่านบทความเรื่อง
Under the hood: How we built API versioning for LinkedIn Marketing APIs
ทำการอธิบายแนวทางในการจัดการ version ของ maketing api ว่าเป็นอย่างไร
ซึ่งเป็นอีกแนวทางท่ีน่าสนใจ
มาดูกันว่าเป็นอย่างไรบ้าง ?
เริ่มต้นจากไม่มีการจัดการ version ของ API เลย
ช่วงแรก ๆ ก็ใช้งานได้ปกติดี
แต่เมื่อมี partner หรือ ผู้ใช้งานมากขึ้นแล้ว
ทาง business ต้องการให้ทาง delivery team ส่งมอบงานรวดเร็ว
พร้อมกับการเปลี่ยนต่าง ๆ ที่ตามมา
แต่ยิ่งทำก็ยิ่งช้า ทดสอบก็ยาก ยิ่งเกิดความผิดพลาดสูง
ส่งผลให้ไม่สามารถวางแผน หรือ วาง roadmap ของระบบได้เลย
ปัญหาหลัก ๆ ของ API คือ ไม่มีการจัดการ version ใด ๆ
คนจริงต้องใช้ version ล่าสุดเท่านั้น
ก็ให้เกิด breaking change ต่อ partner ที่ใช้งานอย่างมาก
แสดงโครงสร้างดังรูป
ดังนั้นจากปัญหาดังกล่าว เลยเริ่มมองเรื่องการจัดการ verision กัน !!
โดยได้ทำการสร้างรูปแบบการทำงาน และ platform ในการจัดการขึ้นมา
เป้าหมายหลัก ๆ เพื่อแก้ไขปัญหาจากข้างต้น
รวมทั้งยังต้องปรับปรุงเรื่อง Developer experience อีกด้วย
ซึ่งมี principle ในการจัดการ version ของ API ไว้ดังนี้
- Slow is smooth, and smooth is fast
- Future-first architecture
- API first
- Don’t disrupt customers
- Decoupling
จากแนวคิดเหล่านี้ทำให้เกิดโครงสร้างของระบบมาใหม่
ทำการเพิ่ม API gateway เพื่อเป็นทางเข้าเดียวจากผู้ใช้งาน
ทำให้สามารถจัดการเรื่อง authentication, authorization และ request mapping ต่าง ๆ ได้ง่ายขึ้น
จากนั้นทำการสร้าง Mid tier สำหรับส่วนการจัดการ API ของทางฝั่ง marketing เข้ามา
แสดงดังรูป
ในส่วนของ Mid tier นั้น จะจัดการ version ตาม request ที่ส่งเข้ามา
โดยในแต่ละ version จะถูก route ไปยัง service ที่ mapping ไว้
แต่ไม่ควรทำการดูแล version ที่มากจนเกินไปด้วยเช่นกัน
แสดงดังรูป
ผลจากการจัดการ version แบบนี้ของ API
ส่งผลให้ Developer experience ดีขึ้น
รวมทั้งการเปลี่ยนแปลง version ไม่กระทบต่อของเก่าหรือปัจจุบัน
และลดปัญหาจาก schema จาก API ที่เปลี่ยนไป
