พอดีต้องไปแบ่งปันความรู้เรื่องการใช้งาน Apache Airflow ขั้นพื้นฐาน
เลยไปเห็น roadmap ของความสามารถต่าง ๆ ใน Apache Airflow 3.0
จึงทำการสรุปความสามารถที่น่าสนใจไว้นิดหน่อย
มาดูกัน

อย่างแรกคือ Modern Web Application

ซึ่งในส่วนของ UI นั้นพัฒนาด้วย React, TypeScript และ Chakra UI
ทำการปรับปรุงเรื่องของ navigation, realtime refresh และ dark mode
และทำการลบ Flask AppBuilder, or FAB ออกไปจาก Airflow

เรื่องที่สองคือ DAG versioning

โดยปกตินั้น Airflow จะทำการ run DAG ใน code ล่าสุดเสมอ
ทำให้เกิดปัญหาบางอย่างขึ้นมา คือ
ในขณะที่ DAG กำลัง run อยู่นั้น มีการเปลี่ยนแปลงขึ้นมา
มักจะทำให้เกิดปัญหา หรือ ผลทำงานไม่เป็นไปตามที่คาดหวัง
หรือไม่รู้เลยว่า การ run แต่ละครั้งใช้ code version ไหนบ้าง
ดังนั้นเรื่องของ DAG versioning เป็นการเปลี่ยนแปลงที่น่าสนใจมาก ๆ

เรื่องที่สาม ในการเขียน Task สนับสนุนภาษาโปรแกรมมากขึ้น

จากเดิมที่เขียนได้เฉพาะภาษา Python เท่านั้น
แต่ใน version นี้มีการสร้าง Task SDK หรือ interface ขึ้นมา
พร้อมกับ Remote executor ขึ้นมาใหม่
ส่งผลให้สามารถเขียน Task ด้วยภาษาโปรแกรมอื่น ๆ ได้ เช่น

• JavaScript และ TypeScript
• Go
• Java

เรื่องที่สี่ Data Assets, Event driven scheduling

ทำให้ Airflow scheduler ทำงานแบบ event-driven
ซึ่งจากเดิมทำงาน time-based และ ตาม dependency ใน workflow เท่านั้น
หรือถ้าต้องการทำงานแบบ event-driven ได้
ก็ต้องใช้พวก external task sensors, sensors/deferrable operators, REST API หรือ datasets เท่านั้น

แต่ในตัวใหม่นี้สามารถ integrate การทำงานแบบ event-driven
เข้ามายัง workflow ได้เลย ไม่ต้องแยก process การทำงานอีกต่อไป
ทำให้สามารถทำงานกับข้อมูลของระบบต่าง ๆ ได้แบบ near realtime มากยิ่งขึ้น
เช่น ระบบ cloud ต่าง ๆ ถ้ามีการเปลี่ยนแปลงใด ๆ
สามารถส่ง event trigger มายัง Airflow ได้เลย
เพื่อทำการ start task การทำงานแบบง่าย ๆ

ลองศึกษาเพิ่มเติมกันดู
โดยจาก roadmap ตัว final น่าจะออกต้นเดือนเมษายนนี้

บันทึกการอ่านบทความเรื่อง How Discord Reduced Websocket Traffic by 40%
โดยทำการอธิบายแนวทางการลด traffic ของ websocket ลง
ซึ่ง websocket นั้นเป็นการติดต่อสื่อสารแบบ realtime ของระบบงานนั่นเอง
มาดูกันว่ามีอะไรที่้น่าสนใจบ้าง ?

เริ่มด้วยปัญหาที่เกิดขึ้นก่อน

หลัก ๆ คือ bandwidth ในระบบ websocket ใช้งานนั้น เยอะมาก ๆ
ส่งผลให้การเชื่อมต่อระบบกับ mobile app นั้นช้ามาก ๆ
สรุปต้นเหตุของปัญหานี้มาได้ดังนี้

• ข้อมูลที่ส่งไปมา เป็น plain text ในรูปแบบ JSON และมีข้อมูลที่ไม่ได้ใช้จำนวนมาก
• ในการส่งข้อมูลพบว่ามีการส่งข้อมูลซ้ำซ้อนกันเยอะมาก ๆ
• เรื่อง network ของ mobile device ที่มีข้อจำกัด

จากปัญหาเหล่านี้ จึงเริ่มการแก้ไข เพื่อปรับปรุงระบบให้ดีขึ้น

วิธีการแก้ไขมีดังนี้

เปลี่ยนจาก plain text มาเป็น binary format ซึ่งใช้ MessagePack

จะเห็นได้ว่าลดขนาดของข้อมูลที่ส่งไปมาได้ประมาณ 35%
ในการแก้ไขจะเขียนตัว encode ข้อมูลก่อนส่งและรับจาก websocket
แถมส่งผลต่อ latency เพียงเล็กน้อยเท่านั้น

แต่ยังไม่พอเพียงเท่านี้ ยังทำการบีบอัดข้อมูลให้เล็กลงไปอีก
แต่ผลที่ตามมาคือ การใช้งาน CPU สูงขึ้น
แต่เมื่อเทียบกับขนาดของข้อมูล และ performance ที่ดีขึ้น
ก็ถือว่ายอมรับได้

ต่อมาก็มาดูที่ข้อมูลที่ส่งไปมา ว่ามีข้อมูลอะไรที่ไม่จำเป็นต่อการใช้งาน
ก็ทำการลบทิ้งไป
รวมทั้งการส่งข้อมูลเดิมซ้ำ ๆ แล้วมีการจัดเก็บในฝั่ง client อยู่แล้ว
ก็จะไม่ส่งซ้ำอีก
เช่นในครั้งแรกของการดังข้อมูลและสถานะของผู้ใช้งานว่าเป็นอย่างไร
เช่น offline เป็นต้น
แต่เมื่อเปลี่ยนสถานะเป็น online ก็ไม่ต้องส่งข้อมูลผู้ใช้งานมาก็ได้
ส่งมาเพียง id ก็เพียงพอแล้ว
นั่นคือ การส่งข้อมูลของ state ที่เปลี่ยนไปเท่านั้น
ช่วยให้ลดขนาดของข้อมูลลงไปได้อีกเยอะแล้ว

แต่การแก้ไขด้วยวิธีการต่าง ๆ เหล่านี้ ก็ทำให้เกิดปัญหาตามมาเช่นกัน

เช่น

• ความซับซ้อนที่สูงขึ้น
• ความเข้ากันได้กับ client ใน version เดิม ซึ่งตรงนี้ก็ต้องค่อย ๆ migrate และ update กันไปด้วย
• การ debug binary data จะยากและซับซ้อนมากยิ่งขึ้น ซึ่งต้องสร้างเครื่องมือมา debug กัน แต่ในการพัฒนาจะให้งานข้อมูล JSON format เพื่อให้เข้าใจได้ง่ายขึ้น ดังนั้นระบบงานจึงต้องมีเรื่องของการ config ให้เปลี่ยนไปมาได้ เป็นอีกเรื่องที่น่าสนใจ

เป็นอีกเรื่องการแก้ไขปัญหาที่น่าสนใจ
ลองศึกษาเพิ่มเติมกันดู

สรุปแล้วเรื่องของ real time application นั้น จะต้องสนใจในเรื่อง

• รูปแบบของข้อมูลที่ส่งไปมา
• ข้อมูลที่ส่งไปมาเหมาะสมหรือไม่
• เรื่องของการบีบอัดข้อมูลก็ต้องพิจารณา เพราะว่ามีทั้งข้อดีและข้อเสีย
• เรื่องของ compatability สำคัญมาก ๆ ต้องวางแผนให้ดี
• ระบบที่ดีต้องมีระบบ monitoring ที่ดี หรือ การทดสอบที่ดี เพื่อให้เรา detect ปัญหา หรือ จุดคอขวดได้อย่างรวดเร็ว เพื่อแก้ไขปัญหาต่อไป

ทีมพัฒนา MongoDB Go Driver ได้ปล่อย version 2.0.0 ออกมา
โดยมีทั้ง feature ใหม่ และ breaking change ต่าง ๆ
มาดูกันว่ามีอะไรที่น่าสนใจบ้าง ?

มาดูความสามารถใหม่ ๆ และการปรับปรุง

• สนับสนุน OpenID Connect
• ปรับปรุงเรื่อง Client-Side Operation Timeout (CSOT)
• ปรับปรุงเรื่อง code ให้ถูกต้องตาม Go idiom มากยิ่งขึ้น
• ปรับปรุง error message ต่าง ๆ ห้เข้าใจง่ายขึ้น
• การจัดการ timeoutทำได้ทั้ง client-side, option, connection string และ operation ใน context

ส่วนที่เป็น breaking change ก็น่าสนใจ เพราะว่าต้องแก้ไข code เดิม

• เพิ่ม mongo package เข้ามา จากเดิมในการ connect ใช้งาน Client.Conect() ใน version นี้ต้องเปลี่ยนเป็น mongo.Connect()
• เพิ่ม options package เพื่อจัดการ config ต่าง ๆ ของการเชื่อมต่อไปยัง MongoDB โดยพัฒนาตามแนวคิด builder pattern
• เพิ่ม event package สำหรับ monitor MongoDB cluster ที่ทำงานเชื่อมต่อ
• เพิ่ม bson package เข้ามา เพื่อรวบรวม package ต่าง ๆ ที่ใช้งาน BSON ให้มาอยู่ที่เดียวกัน เช่น bsoncodec, bsonoptions เป็นต้น

ลองศึกษาเพิ่มเติมกันดูครับ
มีหลายสิ่งอย่างที่ต้องเปลี่ยนแปลงกัน
อ่าน Migration guide ได้เลย

เห็น link ของ whitepaper เรื่อง Agents จาก twiiter
ทำการอธิบายเรื่องของ AI Agents ไว้ ประกอบไปด้วย

• ความรู้ฐานของ AI Agents
• แตกต่างจาก AI models อย่างไร
• บทบาทของเครื่องมือต่าง ๆ ใน Agents
• การปรับปรุง performance ของการเรียนรู้ในเรื่องต่าง ๆ
• ตัวอย่างการพัฒนา Agents ด้วย Langchain

ซึ่งเป็นพื้นฐานของการเรียนรู้เรื่องนี้มาก ๆ
จึงทำการจดบันทึกไว้นิดหน่อย

รูปแสดง Architecture ของ Agent และ component พื้นฐาน

ประกอบไปด้วย

• Orchestration เป็นตัวกลางในการจัดการระบบงาน ทั้ง profiling, ขั้นตอนการทำงาน, instruction หรือ prompt engineer technique, memory ในการจดจำ และการเลือกใช้ model ตาม use case
• Model (Language Model) ​ซึ่งสามารถมีได้มากกว่า 1 model
• Tools เป็นส่วนที่ทำการติดต่อไปยัง external system เพื่อทำงานหนึ่ง ๆ ตามที่ต้องการ ช่วยให้ agent ทำงานได้หลากหลาย มีข้อมูลหรือความรู้ที่มาก และ ถูกต้อง หรือ up-to-date มากยิ่งขึ้น

มีการพูดถึง Prompt engineer technique ต่าง ๆ ดังนี้

• ReAct
• Chain of Thought (CoT)
• Tree of Thought (ToT)

ในเอกสารทำการอธิบายและบอกถึงการปรับปรุง performance ของการทำงานที่น่าสนใจ
ซึ่งขึ้นอยู่กับ reason, act และ การเลือก tool ที่เหมาะสม
รวมทั้งเรื่องของข้อมูลที่ถูกต้องจะช่วยได้เยอะมาก ๆ

อีกส่วนที่สำคัญคือ Tools นั้นเอง

ทำการเชื่อมต่อไปยังระบบอื่น ๆ ที่จำเป็นต่อการทำงานของ Agents นั้น ๆ
โดยแยกออกเป็น 3 ชนิด คือ

• Extension หรือ ส่วนขยายของระบบ เช่น การดึงข้อมูลผ่าน API
• Function คือส่วนการทำงานเฉพาะเจาะจงไปเลย เป็น module ที่ใช้ในการ reuse ต่อไป เป็นส่วนการทำงานก่อนหรือหลัง ต่อจาก Extension เพื่อจัดการข้อมูลต่าง ๆ ที่ได้รับ หรือ จัดการเรื่องของ security ต่าง ๆ

• Data store เป็นที่จัดเก็บข้อมูล หรือ knowledge ของระบบงาน ช่วยให้ Agent จัดการกับข้อมูลที่ up-to-date อยู่อย่างเสมอ ซึ่งสามารถทำได้ทั้ง CRUD (Create-Read-Update-Delete) ซึ่งเป็นส่วนหนึ่งที่อยู่ใน RAG (Retrieval Augmented Generation) นั่นเอง ในส่วนนี้จะรองรับโครงสร้างข้อมูลทั้ง structure, unstructure และ semi-structure จากนั้นทำการจัดเก็บใน Vector database ต่อไป

ลองอ่านเพิ่มเติมดูครับ
มี code ตัวอย่างให้ลองนำไปทดลองกันดูได้ครับ
เป็นอีกหนึ่งเอกสารที่น่าสนใจ

ตัวอย่างของระบบที่ให้มาก็เข้าใจง่ายดี

ปล. แต่ตัวอย่าง code ใช้ Langchain 0.2 นะครับ
ดังนั้นถ้าใช้ version ล่าสุดก็ต้องปรับพอสมควร !!

จากการไปแบ่งปันเรื่องของ Software Architecture ในมุมมองด้านโครงสร้าง
พบว่าจะมีโครงสร้างของระบบหลายรูปแบบ
แต่ส่วนใหญ่ที่พบคือ จะแยกเป็น tier ต่าง ๆ ออกมา
แล้วแต่ละ tier จะมีขนาดที่ใหญ่มาก ๆ ตามเวลาหรือจำนวน feature
ไม่ว่าจะเป็น web tier, business tier, service tier และ database tier
โดยการโตแบบนี้จะเรียกว่า Monolith
หรือบ่อยครั้งจะเรียกว่า Legacy system นั่นเอง
ส่งผลให้ดูแลรักษายาก
พัฒนายาก
build นาน
scale ยาก !!

และต่อมาก็คิดว่าแยกออกไปเป็น service เล็ก ๆ จะช่วยได้
ทั้ง micro-service, nano-service หรือ macro-service
แต่ก็ไม่ได้ช่วย อาจจะสร้างปัญหาใหม่ ๆ ขึ้นมาอีก !!

ดังนั้นแนวทางที่มักจะแนะนำก่อนที่จะแยกคือ ทำของเดิมให้มันดีขึ้นก่อนไหม ?

Q: ถ้าระบบมีปัญหาแก้ไขอย่างไร ?
A: restart ไงละ
Q: ถ้ามีปัญหาทุก ๆ วัน แก้ไขอย่างไร ?
A: ตั้ง schedule restart มันทุกวันไงละ ง่ายจะตาย !!

เราคงไม่ทำในระยะยาวกันนะ แต่ระยะสั้น ๆ อาจจะทำก็ได้

ถ้าความต้องการของระบบต้องการ scale ให้รองรับผู้ใช้งานที่มากขึ้น

คำว่ามากขึ้นมีทั้ง

• ผู้ใช้งานมากขึ้น
• ข้อมูลมากขึ้น

แต่ก่อนอื่นระบบงานต้องมีระบบ monitoring หรือ observability ที่ดีก่อน
ทั้ง log, metric และ tracing
เพื่อช่วยให้การวิเคราะห์ การปรับปรุงได้ดียิ่งขึ้น

มาเริ่มกันเลย

ก่อนอื่นต้องเข้าใจก่อนว่า เมื่อระบบโตขึ้น
feature มากขึ้น
ผู้ใช้งานมากขึ้น
ข้อมูลมากยิ่งขึ้น
มันส่งผลต่อการพัฒนา ทดสอบ และ deploy รวมทั้งการ scale ด้วยหรือไม่ ?
ถ้าใช่ แสดงว่า เราเจอปัญหาเข้าให้แล้ว
จำเป็นจะต้องแก้ไขปัญหานั้น ๆ ให้เร็วที่สุด
อย่าผลัดวันประกันพรุ่ง !!

ตัวอย่างของ scale ระบบที่มักจะทำกันอย่างแรกคือ Vertical scale หรือ Scale up

คือการขยายเครื่องให้ใหญ่ขึ้นทั้ง CPU, Memory, Disk และ Network
มีกี่เครื่อง หรือ กี่ส่วนของขยายกันไป
ยิ่งระบบไหนอยู่บน cloud ได้ลากไปทางขวากันง่าย ๆ และ สนุกเลย !!
เป็นแนวทางที่เรียบง่าย
ไม่ต้องเปลี่ยนแปลง architecture
ไม่ต้องเปลี่ยนแปลงรูปแบบการ deploy
ไม่ต้องเปลี่ยนแปลงรูปแบบการ monitor

แต่การ scale แบบนี้ก็มี limit ที่กำหนดไว้
ยิ่งกว่านั้นเมื่อค่าใช้จ่ายที่ใช้ไป
มันไม่สมเหตุสมผลต่อทาง business
ค่าใช้จ่ายมากกว่ารายรับที่ได้
รวมทั้ง performance ที่ได้รับกลับมา

ยิ่งถ้าล่มไปกระทบต่อผู้ใช้งาน และ business อีก
โดนด่าอีก
มี single-point-of-failure อีก

ดังนั้นอาจจะต้อง scale ในรูปแบบของ Horizontal scale หรือ Scale out

คือการเพิ่มเครื่องเข้าไป
ทั้งฝั่งของ frontend
ทั้งฝั่งของ backend/service
ทั้งฝั่งของ database
และยังต้องเพิ่มพวก Load balance เข้ามา
เพื่อช่วยกระจาย load ไปยังเครื่องต่าง ๆ ที่เพิ่มเข้ามา
หรืออาจจะมี API gateway เข้ามาอีก
ซึ่งแน่นอนว่า ช่วยทำให้ระบบงานดีขึ้น รองรับผู้ใช้งานได้มากขึ้น
แต่ตามมาด้วยความซับซ้อนที่สูงขึ้น
อีกอย่าง Architecture ของระบบงานที่ออกแบบและพัฒนากันมา
สนับสนุนโครงสร้างแบบนี้หรือไม่ ? (Stateless vs Stateful)
รูปแบบของการ monitor และ deploy ก็เปลี่ยนไป

ต้องทำการเพิ่ม Caching ใน layer/tier ต่าง ๆ ด้วยหรือไม่ ?

เพื่อปรับ response time ให้รวดเร็วมากขึ้น
ลด load ต่าง ๆ ที่เข้ามาในระบบ เช่น

• Web browser caching
• CDN caching
• Application-level caching
• Database query caching

จะจัดการเรื่อง caching ได้ดี
จำเป็นต้องเข้าใจการใช้งานข้อมูล (Read vs Write)
การออกแบบ data model ที่เหมาะสมต่อการใช้งาน
อย่าลืมว่า caching มันคือ การสร้าง duplication data ขึ้นมานะ !!

ต่อมาในส่วนของ Database ก็ต้อง scale ด้วย

เช่นการทำ replica เพื่อรองรับการ read ที่มากขึ้น
แต่ระวังเรื่อง lag time ระหว่างการ write ที่ primary กับการ read ที่ replica ด้วย

ยังไม่พอเรื่องของ data model ที่ใช้งาน
ต้องมองทั้งการ read และ write
บ่อยครั้งพบว่า เรามักจะออกแบบ model เดียวแล้วใช้ทั้ง read และ write
ซึ่งอาจจะไม่เหมาะสมนัก
จึงต้องปรับปรุงเรื่องนี้ เพื่อลดการ read หรือ query ที่หนักเกินไป
เพราะว่าจะใช้งาน CPU และ memory ของ database มากเกินไป
จากนัั้นก็จะกระทบต่อ operation อื่น ๆ
ในเรื่องนี้อาจจะเรียกว่าการทำ

• Materialized view
• Denormalization vs Nomalizarion
• Pre-aggregate/summarize data

ในเรื่องของข้อมูลใน database ก็เช่นเดียวกัน
ข้อมูลอะไรไม่ใช้งานแล้ว หรือ นาน ๆ ใช้ครั้ง
อาจจะต้องแยกออกจากกัน
มิเช่นนั้น ระบบอาจจะมีปัญหาเมื่อ data สูงขึ้นเรื่อย ๆ

ในส่วนนี้อาจจะทำพวก house keeping ก็ได้
ทำ data partitioning ก็ได้
ทำ data sharding ก็ได้
อยู่ที่ use case ของระบบงานนั่นเอง

ใน database นั้นอย่าลืมดูพวก slow query ด้วย
เพื่อทำการปรับปรุงให้ดีขึ้น
หรือแม้แต่ query ไหนที่ใช้งานเยอะ ๆ
ก็ต้องปรับในส่วนของ application ให้ใช้งานลดลง
เช่น caching และ data model ก่อนหน้านั่นเอง

ยังไม่พออาจจะทำการแยกงานบางอย่างออกมาจากระบบ

เช่นงานที่ใช้ resource เยอะ หรือ งานที่ทำงานนาน ๆ
สามารถแยกออกไปทำด้วยการใช้งาน messaging queue เข้ามาช่วย
เช่น

• Upload file
• ส่ง email หรือพวก notification ต่าง ๆ
• การ generate report
• พวก batch operation

จะช่วยลดการใช้งาน resource ในส่วนหลักไปได้เยอะ
หรือสร้าง buffer ขึ้นมาให้ระบบงานค่อย ๆ ทำงานไปนั่นเอง

ดังนั้นจะเห็นได้ว่าระบบ Monilith นั้นมีรูปแบบของการปรับปรุงหลายรูปแบบ

เราจำเป็นที่จะต้องเรียนรู้ด้วยเช่นกัน
ว่าระบบงานของเราอยู่ใน stage ไหน
จะได้เลือกวิธีการที่เหมาะสม
ก่อนที่สุดท้ายจึงจะแยกออกมาเป็น service เล็ก ๆ

เพราะว่าทุกครั้งที่เราแยกอะไรออกมา
จะทำให้ระบบเราซับซ้อนขึ้นอย่างมาก (มีได้ก็มีเสีย)

ขั้นตอนทั่วไป ที่ผมชอบทำ มีดังนี้

• ปรับปรุง code และ การ query database ก่อน
• เพิ่ม caching เข้าไปในจุดที่เจอปัญหา
• ขยายเครื่องก่อน จนค่าใช้จ่ายไม่สมเหตุสมผล
• ทำการเพิ่มเครื่องทั้ง web, business และ database ตามปัญหาที่พบเจอ
• จัดการข้อมูลให้ดี
• ใช้ messaging queue เข้ามาช่วย

ลองดูว่าระบบของเราเป็นอย่างไร ?

เพิ่งเห็นว่า model DeepSeek-R1 มีใน Ollama แล้ว
เลยลองติดตั้งและใช้งานกันหน่อย
ซึ่ง Ollama ช่วยให้เราใช้งาน AI บนเครื่องของเราได้
model นี้มีให้เลือกหลาย version ตามการใช้งาน
เป็น reasoning model ที่มีความสามารถด้าน

• logical analysis
• mathematical
• programming assistance

ดังนั้นจึงสามารถนำมาประยุกต์ใช้งานได้หลากหลาย use case
มาทำการติดตั้งและใช้งานกันนิดหน่อย

มาติดตั้งใช้งานกัน เริ่มจากติดตั้ง Ollama ก่อนนะ
ทำการ Download ได้

จากนั้นทำการ download model มาได้เลย
ซึ่งเลือก version ตามการใช้งานได้เลย เช่น

• 1.5B เป็นตัวเล็กที่สุด
• 7B คือตัวที่แนะนำสำหรับการใช้งาน use case ทั่วไป รู้จักภาษาอังกฤษและจีนเท่านั้น
• ที่เหลือจะเก่งและฉลาดมากกว่า ลองทดสอบใช้งานกันดู

ส่วนผมเลือก 7B มาใช้งานดังนี้

เมื่อทำการติดตั้งแล้ว ก็ลองเขียน code ใช้งานนิดหน่อย

ใช้งานผ่าน ollama library ด้วยภาษา Python แบบง่าย ๆ

ผลการทำงานเป็นดังนี้

ตอนนี้มีหลาย model ให้ลองใช้งานกัน สนุกมาก ๆ

Reference websites

• DeepSeek R1's recipe to replicate o1 and the future of reasoning LMs

ใน Robot framework 7.2 นั้นทำการเพิ่ม Group syntax เข้ามาใน test script
มีเป้าหมายเพื่อจัดกลุ่มของขั้นตอนการทำงานใน test case
ให้อ่านง่ายขึ้น ดูแลรักษาได้ง่ายขึ้น
รวมทั้งเรื่อง log ที่ออกมาใน report ให้เข้าใจใน high level มากยิ่งขึ้น
แต่ในเอกสารยังแนะนำให้ใช้งาน User Keyword มากกว่า
เพราะว่าสามารถ reuse ได้ รวมทั้งเป็นการซ่อนความซับซ้อนของการทำงานไว้ด้วย
มาลองใช้งานกันดู

อีกอย่างหนึ่ง ถ้ามีหลาย group ใน test case หรือ keyword เดียวกันแล้ว
พวก variable ต่าง ๆ ยังมี scope การทำงานเช่นเดิม ไม่เปลี่ยนแปลง

ก่อนอื่นต้อง update Robot framework 7.2 !!

ต่อมาเขียนแบบปกติของคนเริ่มต้นใหม่

จากนั้นเพิ่มให้อ่านรู้เรื่องขึ้นมา เพื่อให้กลับมาอ่านได้ง่ายและเข้าใจ
น่าจะใส่ comment กันประมาณนี้

แต่ถ้าเริ่มมีประสบการณ์กับความเจ็บปวดขึ้นมาหน่อย
อาจจะแยกออกไปสร้าง Keyword หรือ User Keyword
หรืออาจจะแยกออกไปตามแนวทางของ Page Object ก็ว่ากันไป
ประมาณนี้

ส่วนใน Robot framework 7.2 นั้น ได้เพิ่ม Group syntax เข้ามา

สามารถเพิ่มเข้ามาแทนในส่วนของการ comment ได้เลย
ให้อยู่ใน GROUP-END block เป็น case-sensitive นะ
ซึ่งมันคล้าย ๆ test step ใน Playwright เลย
แต่ดูแล้วมันแปลก ๆ นิดหน่อย ดังนี้

เมื่อไปดูใน report ของการทดสอบ ได้ดังนี้

เป็นอีกความสามารถใหม่ ๆ ของ Robot framework 7.2
ลองศึกษาและใช้งานกันดูครับ
อ่านเพิ่มเติมใน User guide ได้เลย

เห็นใน feed มีการ share เรื่องการควบคุม web browser ด้วย Browser Use
โดย library ตัวนี้บอกว่าเป็น AI Agent
ซึ่งการทำงานมีขั้นตอนดังนี้

• ทำการเปิด web browser เพื่อเข้าไปยัง URL ที่เรากำหนด
• ทำการ extract DOM ต่าง ๆ ในหน้า web ออกมา
• จากนั้นทำงานตามที่เรากำหนดไว้ต่อไป

ดังนั้นเรามาลองใช้งานกันดูแบบง่าย ๆ

เริ่มการใช้งาน

ในการใช้งานนั้นจะต้องติดตั้ง Python ก่อน
ส่วนการควบคุม web browser จะใช้งาน Playwright ดังนี้

โดยการอ่านและ extract DOM ของแต่ละ page ออกมาจะใช้งาน Playwright นั่นเอง
ดูได้จาก source code ตรงนี้
อีกอย่างในการทำงานว่าจะ execute คำสั่งอะไรของ Playwright
เพื่อควบคุมการทำงานตามคำสั่งที่เรากำหนด
จะมีการเขียน prompt ขึ้นมา สามารถดูได้ใน System prompt ซึ่งละเอียดมาก ๆ
ยกตัวอย่างของ Prompt

ขั้นตอนที่สอง ทำการเขียน code เพื่อทดลองใช้งาน

ซึ่งใช้งาน AI model=gemini-2.0-flash-exp ของ Google Genimi
จากนั้นสั่งให้ทำการเข้าไปใช้งาน https://seleniumbase.io/coffee/
มาดู code กันดู

รูปแบบของ task หรือคำสั่ง ให้ทำการซื้อ Americano 1 แก้ว และทำการสั่งซื้อด้วยชื่อและ email

ทำการ run ได้ผลดังนี้

จะเห็นได้ว่าตัว Agent หรือ browser use
จะทำการสร้าง task/action ออกมา
จากนั้นก็ทำการ eval หรือ เรียกใช้งาน function ของ Playwright
เพื่อทำงานต่อไป จนจะ success นั่นเอง

และผลการทำงานจะสร้างเป็น gif animation มาให้อีกด้วย
ลอง click ดู

จะมีการตีกรอบใน element/locator จะเจอบนหน้า web ด้วย

ลองใช้งานกันดูครับ
จะเป็นอีกเครื่องมือที่ช่วยดูว่า web ที่เราต้องการควบคุมนั้น
มันเหมาะหรือไม่ หรือ เราพัฒนาระบบงานให้มีความ accessibility ที่ดีหรือไม่ ?
สามารถดู code ได้ที่ GitHub

ปล. ลองใช้งาน model DeekSeek:7b พบว่าไม่สนับสนุน function call

จากที่แบ่งปันเรื่อง Full Stack Testing ที่ Skooldio ไปนั้น
ได้อธิบายถึงการสร้างหรือจำลอง dependencies ต่าง ๆ ที่ระบบงานต้องใช้งาน
เพื่อควบคุมผลการทำงานให้เป็นไปตามที่ต้องการ
ไม่ว่าจะ success หรือ failure
เพื่อช่วยให้เราทดสอบระบบงานของเราได้อย่างมั่นใจ และ ทำซ้ำ ๆ ได้บ่อยเท่าที่ต้องการ
หนึ่งในวิธีการที่แนะนำไป แต่ยังไม่ทำการ demo ให้ดู
นั่นก็คือ การใช้งาน TestContainer
จึงมาเขียนอธิบายให้เพิ่มเติมดังนี้

ต้องติดตั้ง Docker ลงเครื่องก่อนนะครับ

ความต้องการของระบบประกอบไปด้วย

• ทำการดึงข้อมูลจาก MySQL database
• ทำการดึงข้อมูลด้วย id จะมีทั้ง success และ failure case
• ใน failure case จะมี 2 cases คือ ไม่พบข้อมูล และ database error

สามารถเขียน code การเชื่อมต่อและดึงข้อมูลจาก database แบบง่าย ๆ ได้ดังนี้

คำถามต่อมาคือ จะทำการทดสอบอย่างไรดี ?

ซึ่งมีทั้ง unit test และ integration test
สามารถทดสอบได้ตามที่ต้องการ หรือ ตามความสามารถ
แต่หัวใจของการทดสอบต้อง

• สร้างความเชื่อมั่นให้เรา ทีม และ product
• สามารถทดสอบซ้ำได้ ทั้งบนเครื่อง และ CI/CD server

ดังนั้นจึงเลือกวิธีการสร้าง database server ขึ้นมาด้วย container (Docker)
แต่ให้ทำการสร้าง container ในการ test ด้วย TestContainer for Go ไปเลย
ยังไม่พอ ให้ทำการสร้าง table และ data for test ตาม test case ที่กำหนดไว้

ยกตัวอย่างเช่นการทดสอบ Success case

ตัวอย่าง data for test ใน success case

ทำการ run test กันหน่อย

ลองเพิ่มอีกสัก case เช่น หาข้อมูลที่ต้องการไม่เจอใน database

เพียงเท่านี้ก็สามารถทดสอบระบบงาน กับ database ได้แบบง่าย ๆ
น่าจะเป็นอีกหนึ่งวิธีการในการทดสอบระบบงาน
ลองศึกษาและนำไปใช้งานกันดูครับ
ขอให้สนุกกับการ coding และ testing ...

ตัวอย่างของ source code ที่ GitHub:Up1

ใน Selenium WebDriver นั้นมีความสามารถใหม่ออกมาคือ Selenium WebDriver BiDi
เป็นการนำเอาความสามารถของ
Selenium WebDriver มาผสมเข้ากัน CDP (Chrome DevTools Protocol)
นั่นคือ ทำการผ่าน websocket (JSON-over-WebSocket) ไม่ทำการแบบ synchronous เหมือนเดิมแล้ว
ทำให้การทำงานเร็วขึ้น ปัญหา flaky test น้อยลงไป
ควบคุม Web browser ได้ดีและมากขึ้น
โดยในความสามารถที่รอมานาน ซึ่ง Cypress และ Playwright ทำได้นานแล้ว
คือ Network Intercepter

โครงสร้างการทำงานแบบคร่าว ๆ ของ WebDriver แบบเดิม กับ WebSocket

มาดูตัวอย่างการใช้งาน BiDi ใน Selenium กัน

มีขั้นตอนการทำงานดังนี้

• Enable BiDi ด้วยการเพิ่ม webSockerUrl=true เข้าไปใน option ของ web browser
• ต้องการ intercept หรือ ดักจับ request ที่ออกจาก web browser เพื่อทำการควบคุม response ให้เป็นไปตามที่ต้องการ ทั้ง success และ failure case ต่าง ๆ

ตัวอย่างเขียนด้วยภาษา Java + Chrome for Testing

• ทำการ enable BiDi
• ทำการดักจับ request และส่ง response ที่ต้องการคือ Mock Hello World! กลับไปแทนของจริง
• ทำการตรวจสอบผลการแสดงผลในหน้า web ว่าเป็นไปตามที่คาดหวังหรือไม่

เพียงเท่านี้ก็สามารถใช้งาน Selenium WebDriver BiDi แบบง่าย ๆ ได้แล้ว
ลองใช้งานกันดู

สามารถดู code ตัวอย่างได้ที่ GitHub:Up1

รูปแสดงการทำงานของ BiDi

หลังจากที่ไปแบ่งปันความรู้เรื่องการพัฒนา RAG app (Retrieval-Augmented Generation) มานิดหน่อย
ซึ่งมีกระบวนการพื้นฐานประกอบไปด้วย

• Chunking
• Embedding
• บันทึกลง Vector Database
• ทำการค้นหาข้อมูลที่ใกล้เคียง
• ทำการ re-rank ผล

หนึ่งในขั้นตอนที่น่าสนใจคือ Vector Database
เราจะใช้อะไรดี ซึ่งมีให้เลือกมากมาย ตามความเหมาะสม หรือ ความชอบก็ว่าไป
หนึ่งในตัวที่ถามในการแบ่งปันคือ MongoDB
ดังนั้นมาลองใช้งานกันหน่อย

โดยการเก็บข้อมูลชนิด Vector ใน MongoDB นั้น
จะเป็นความสามารถของ MongoDB Atlas
และเราสามารถทำการติดตั้งบน local เพื่อทดลองใช้งานได้เช่นเดียวกัน
ซึ่งทาง MongoDB ได้เตรียมการติดตั้งไว้ให้ทั้ง

• CLI
• Docker

ใน Workshop นี้ผมเลือกติดตั้งด้วย Docker

ด้วยการเขียนไฟล์ docker compose ขึ้นมาดังนี้

ทำการติดตั้งแบบง่าย ๆ

จากนั้นทำการเขียน code เพื่อทำการบันทึกข้อมูลลง MonogDB Atlas
ซึ่งก่อนจะบันทึกและค้นหาได้นั้น ต้องทำดังนี้

• สร้าง database และ collection สำหรับจัดเก็บข้อมูล
• ทำการ embedding ข้อมูลที่ต้องการบันทึกลอง property ที่เป็น Vector type
• ทำการสร้าง index ให้เป็น type=vectorSearch ใช้สำหรับค้นหา สามารถกำหนก similarity algorithm ได้ โดยจากตัวอย่างใช้ cosine

ตัวอย่าง code เป็นดังนี้

จากนั้นก็สามารถทำการค้นหาข้อมูลด้วย Vector search ได้แล้ว
เป็นอีกหนึ่งทางเลือกที่น่าสนใจ
จะพบว่า Database model ต่าง ๆ จะสนับสนุน Vector type เข้ามา
ทั้ง MySQL, PostgreSQL, SQLite และ Elasticserch/OpenSearch เป็นต้น

Reference Websites

• Getting Started with MongoDB Atlas Local Search Experience Using Docker

มาลองใช้งาน Posting สำหรับ API testing ใน terminal แบบง่าย ๆ
โดยสามารถใช้งานได้ทั้ง local หรือ บนเครื่องของเราเอง
หรือจะใช้งานผ่าน SSH protocol บน remote server ได้
รวมทั้งยังสนับสนุน container อีกด้วย
ส่วน request ต่าง ๆ จะทำการจัดเก็บลงไฟล์ YAML
ทำให้จัดการ version control เช่น Git ได้ง่ายขึ้น
มาเริ่มใช้งานกัน

ความสามารถหลัก ๆ ของ Posting ประกอบไปด้วย

• run ใน terminal ดังนั้นต้องเรียนรู้การควบคุมและใช้งานผ่าน keyboard ใครไม่ชินอาจจะบอกว่ายาก แต่ก็ใช้ mouse ได้ปกติ
• ทำการจัดกลุ่ม request ด้วย collection และสร้าง folder ได้ เหมือนกับ Postman
• จัดการ environment variable และ load ได้จาก .env ได้
• ทำการปรับแต่ง theme แบะ keymap ต่าง ๆ ได้
• ทำการบันทึกเป็นไฟล์ YAML ได้
• ทำการเขียน script เพื่อตรวจสอบการทำงานด้วยภาษา Python

เริ่มด้วยการติดตั้ง

ผลการทำงานเป็นดังนี้

จากนั้นลองเล่นกันดูครับ
อาจจะลำบากกว่า Desktop app นิดหน่อย

ส่วนความสามารถที่น่าสนใจคือ การเขียน test script สำหรับ response ของ request

ดังนั้นจึงลองใช้งานและ save มาเป็นไฟล์ YAML ดังนี้

ทำการเขียน script ด้วยภาษา Python
เพื่อตรวจสอบ status code ของ response ว่ามีค่าเป็น 200 หรือไม่
และทำการเขียน code เพื่อแจ้งให้ผู้ใช้งานรู้ด้วยว่า success หรือ fail
โดยที่ script มี 3 แบบ คือ

• Setup
• Pre-request
• Post-response

มาดูตัวอย่างของ Post-response script

จากนั้นทำการ run ผ่าน Posting UI ได้ผลดังนี้

ลองใช้งานกันดูครับ
เป็นอีกเครื่องมือที่น่าสนใจ

ในการตรวจสอบโครงสร้างของข้อมูลในรูปแบบต่าง ๆ เช่น XML และ JSON เป็นต้น
สำหรับภาษา JavaScript จะใช้ library ต่าง ๆ เช่น JSON Schema, Zod, ValiBot และ ArkType เป็นต้น
ซึ่งมีวิธีการที่หลายหลายมาก ๆ
ดังนั้นจึงเกิดแนวทางของ Standard Schema เพื่อตรวจสอบ
ลดการผูกมัดกับ library ต่าง ๆ งไป
แต่ยังทำงานร่วมกับ library ต่าง ๆ ได้

มาดูกันว่า Standard Schema จะใช้กันอย่างไร ?

ขั้นตอนที่ 1 สร้าง generic function สำหรับ validate ข้อมูลจาก library ต่าง ๆ

ขั้นตอนที่ 2 ทำการตรวจสอบโครงสร้างข้อมูลจาก library ต่าง ๆ

ทำการ run test นิดหน่อย

เป็นแนวทางที่น่าสนใจ
ขอให้สนุกกับการ coding

ทาง Postman ปล่อย Postman AI Agent Builder ออกมาให้ใช้งาน
เพื่อช่วยให้ทำการค้นหา ทดสอบ และจัดการ API ได้ง่ายขึ้น
รวมทั้งยังเตรียม API จำนวนมากไว้ให้ integrate หรือใช้งาน
มาดูกันว่ามีความสามารถอะไรที่น่าสนใจกันบ้าง ?

เรื่องแรกใน Postman เพิ่มการทดสอบผ่าน LLM provider ต่าง ๆ มาแล้ว

ส่วนที่สองใน Flow เพิ่ม AI Agent เข้ามา ให้สร้าง request และ flow ได้ง่ายขึ้น

เรื่องที่สาม Generate code tool

สามารถ generate code ในภาษา JavaScript และ TypeScript
จาก Postman request ได้เลย ผ่าน GenTool

ดดยที่เราสามารถสร้างเครื่องมือเหล่านี้ได้เอง
เพราะว่าทาง Postman เตรียม API ไว้ให้
ลองเข้าไปดูเพิ่มเติมได้ เช่น Tool Generation API

ลองใช้งานกันดูครับ สำหรับสาย Postman
สามารถดูตัวอย่างการใช้งานที่ Workspace นี้ได้

ในเดือนกุมภาพันธุ์นี้ Go 1.24 ตัวเต็มน่าจะถูกปล่อยออกมาให้ใช้งาน
ส่วนตอนนี้เป็น version RC2 อยู่
ดังนั้นมาดูความสามารถที่น่าสนใจกันหน่อยว่ามีอะไรบ้าง ?
ใครสนใจในรายละเอียดอ่าน Release notes ได้

เรื่องของ Benchmark ไม่ต้องเขียน for loop แล้ว

ด้วยการเพิ่ม testing.B.Loop เข้ามา
ลองใช้งานแต่ช้ากว่าแบบเดิม !!

ต่อมาทำการคือ resource ต่าง ๆ ด้วย runtime.AddCleanup ตามต้องการ
ซึ่งจะถูกเรียกเมื่อเราทำการ force GC ด้วย runtime.GC() ดังนี้

เพิ่ม package testing/synctest สำหรับการทดสอบ concurrent code

ประกอบไปด้วน function Run() และ Wait()
ซึ่งเป็น experiment feature
ดังนั้นถ้าต้องการใช้งาน ให้ทำการกำหนดค่า GOEXPERIMENT=synctest

สำหรับ slog ถ้าไม่ต้องการแสดง log

ลองศึกษากันเพิ่มเติมดูครับ

Reference websites

• Go 1.24 interactive tour
• Go 1.24: The Ultimate Update That Makes Development Faster and Safer

จากคำถามในการแบ่งปันเรื่อง Full Stack Testing ที่ Skooldio มานั้น
มีคำถามที่น่าสนใจคือ
ในการทดสอบระบบงานด้วย Playwright นั้น
ถ้าเราต้องการสร้าง dashboard กลางด้วย Grafana
เพื่อแสดงผลการทดสอบ จะทำได้หรือไม่ อย่างไรบ้าง ?
มาดูหนึ่งในแนวทางกัน

โครงสร้างของแนวทางเป็นดังรูป

• ทำการส่งข้อมูลผลการทดสอบไปยัง Prometheus Pushgateway ด้วย Playwright Prometheus Reporter
• จากนั้นทำการเก็บข้อมูลทั้งหมดไว้ที่ Promethus ซึ่งเป็น metric time-serie database
• สุดท้ายสร้าง dashboard ใน Grafana และกำหนด datasource ไปที่ Prometheus นั่นเอง

โดยใน Playwright ให้ทำการ config ดังนี้

ในไฟล์ playwright.config.ts ให้เปลี่ยน report ไปยัง Promethus reporter
ตัวอย่าง

จากนั้นใน folder ที่เก็บชุดการทดสอบต่าง ๆ ให้ทำการสร้างไฟล์ config.conf ขึ้นมา
เพื่อทำการ config การจัดเก็บข้อมูลของ report จากขั้นแรก เช่น

เมื่อทุกอย่างเรียนร้อยก็ทำการ setup ระบบจัดเก็บข้อมูลทั้ง 3 ส่วน คือ

• Prometheus Pushgateway
• Prometheus server
• Grafana

ทำการ run test ปกติ จะได้ผลดังนี้

ให้ทำการตรวจสอบผลการทดสอบและ report ต่าง ๆ ใน Prometheus ได้
ตาม key เหล่านี้

• suite_execution_total
• suite_execution_failed
• test_execution_total

แสดงตัวอย่างดังรูป

และทำการสร้าง dashboard ใน Grafana ต่อไป แสดงตัวอย่าง ดังรูป

ลองใช้งานกันดูครับ
ตัวอย่าง source code และการติดตั้งอยู่ที่ GitHub::Up1

ทาง GitHub Copilot เพิ่งปล่อย Agent mode ออกมาให้ใช้งาน (preview mode)
โดยจะมีการทำงานมีขั้นตอนที่ดีขึ้น ประกอบไปด้วย

• อ่าน code จากไฟล์ที่จะทำการแก้ไข รวมทั้ง context ที่เกี่ยวข้องใน workspace ให้แบบอัตโนมัติ
• ในการทำงานมีทั้ง code ที่เปลี่ยน และ run ชุดคำสั่งต่าง ๆ ใน command/terminal ให้ เช่น compile, build, download dependency และ test ให้เลย
• ตรวจสอบความถูกต้องของ code ให้ ถ้ามีปัญหาหรือ issue ต่าง ๆ จะแก้ไขให้ทันที

ในแต่ละขั้นตอนของการทำงานจะมี Agent tools เตรียมไว้ให้
และทำงานแบบ parallel อีกด้วย
มาลองใช้งานกัน

โดยสามารถใช้งานได้ก่อนใน Visual Studio Code Insiders

จากนั้นให้ทำการ enable agent ใน settings

จากนั้นจะมี Agent และ Edit mode มาให้เลือกใน Copilot Chat Edit ดังรูป

จากนั้นลองเขียน prompt สั่งได้เลย

หรือใครถนัดใช้ prompt template ก็สะดวกนะ
ตัวอย่างของ prompt ที่ใช้งานง่าย ๆ

จากนั้น Agent จะคิดและทำการ run ในแต่ละขั้นตอนให้เรา
โดยแต่ละขั้นตอนจะถามเราเสมอให้ continue หรือไม่ ?
เช่น

• สร้าง project
• Download dependency
• สร้างไฟล์ต่าง ๆ
• Run test ถ้าไม่ผ่านตัว agent จะทำการแก้ไขปัญหาให้

ตัวอย่างการถามของ Agent

ส่วนของการทำงานใน command/terminal จะทำให้เองแบบนี้

เท่าที่ลองใช้งานสะดวกขึ้นเยอะมาก ๆ
ลองใช้งานกันดู
ขอให้สนุกกับการ coding

คำถามจากการแบ่งปันเรื่อง AI for software development นั้น
สอบถามเกี่ยวกับการสร้าง Local LLMs server เพื่อใช้งานในองค์กร
เพื่อจัดการในแง่ของ privacy และ การทดสอบ
ว่ามีแนวทางอย่างไรบ้าง ?

โดยสิ่งที่แนะนำไปประกอบไปด้วย

• Ollama
• LMStudio
• LlamaCPP
• vLLM
• Jan.AI
• LLamaFile

ลองใช้งานกันดูครับ

คำถามที่น่าสนใจในการ review code ของระบบงาน
เราทำการเปลี่ยน code มาใช้ภาษาโปรแกรมที่เร็วมาก ๆ แล้ว
แต่ทำไมยังช้าอยู่ เมื่อทำการเชื่อมต่อ database !!
Database มีทั้ง SQL และ NoSQL
โดยที่ code ทำงานเร็วมาก ๆ ในระดับ nano หรือ milisecond กันเลย
ส่วน database กลับใช้เวลาการทำงานหลายวินาที !!

นั่นหมายความว่าระบบงานของเราจะตันที่ Database (bottleneck)

แล้วมันเกิดจากอะไรบ้าง ?
เพื่อที่จะแก้ไขได้อย่างถูกต้อง

• Database นั้นมักจะทำการอ่านและเขียนข้อมูลจาก disk และผ่านระบบ network ดังนั้น disk ต้องเร็ว network ต้องเยอะ
• Business logic ที่ซับซ้อน
• มีการใช้งาน CPU เยอะ
• ในการ query ข้อมูล มี lock CPU เยอะ
• ในการ query ข้อมูล ใช้ memory เยอะ เนื่องจากข้อมูลเยอะ ยิ่งนานไปยิ่งช้า ไม่ทำ index ที่เหมาะสม
• ในการ query ข้อมูล มีข้อมูลเยอะเกินไป มีการ join มากเกินไปไหม หรือ บางข้อมูลไม่ได้ใช้ก็ดึงออกมา มันเปลือง
• ในการ query ต่าง ๆ จำเป็นต้องทำการ explain หรือ ตรวจสอบ cost หรือ resource ที่ต้องใช้งาน รวมทั้งระบบ monitoring ที่ดี เพื่อดู query ต่าง ๆ ว่าใช้งานอย่างไร ทำงานอย่างไร และมี slow query ตรงไหนบ้าง
• ถ้าข้อมูลเยอะขึ้น แล้วส่งผลต่อการทำงาน น่าจะต้องทำ sahrding และ partioning เสมอไหม
• ในการ update เยอะ ๆ เกิดการ lock หรือ deadlock ขึ้นมาได้ แนะนำให้ใช้ update/delete in batch จะลดปัญหาลงได้เยอะ
• มีผู้ใช้งานจำนวนสูงขึ้น ทำให้ระบบช้าลง
• Architecture ของ database ไม่เหมาะสมต่อการใช้งาน เช่น single node ไม่รอด น่าจะต้องมี replica มารองรับการ read หรือไม่ หรือต้องทำแบบ multi-master เพื่อรองรับการ write ที่มากขึ้น หรือยังแยกการ read และ write ออกจากกันด้วยการใช้ database model ที่เหมาะสม (polyglot database)
• เราคนจริง ไม่มีการใช้งาน caching หรือ pre-aggregate ใด ๆ สำหรับ query ข้อมูลบ่อย ๆ หรือ หนัก ๆ ดังนั้นควรจัดการให้ดี แต่ก็ต้องดูเรื่อง cached invalidate ด้วย เพื่อให้ข้อมูลถูกต้องอยู่อย่างเสมอ
• ออกแบบ data model ไม่เหมาะสมกับงาน ทั้ง Normalization และ De-nomalization
• ถ้าลึกกว่านั้นคือ เรื่องของ data type ที่ใช้จัดเก็บไม่เหมาะสมกับงาน
• การจัดการ database connection ที่ไม่ดี ซึ่งต้องใช้งาน connection pool หรือ proxy เข้ามาช่วย เพื่อ reuse connection ให้ดีขึ้น
• ถ้ามี load เข้ามาหนัก ๆ จำเป็นต้องออกแบบเพื่อรองรับเพื่อให้ระบบไม่พังไปด้วย เช่น rate limit, circuit breaker หรือ แทนที่จะทำงานแบบ synchronous ก็ปรับมาเป็น asynchronous ด้วย

ลองดูระบบของเราสิว่า มีปัญหากันตรงไหนบ้าง ?
ขอให้สนุกกับการ coding ครับ

ระบบงานต่าง ๆ นั้น ยิ่งนานไประบบยิ่งมีส่วนการทำงานต่าง ๆ เยอะขึ้น ซับซ้อนมากขึ้น
ทั้ง product, domain, service และ messaging ต่าง ๆ
ดังนั้นเราจะจัดการสิ่งต่าง ๆ เหล่านี้อย่างไร
เพื่อให้เรารู้และเข้าใจภาพรวมของระบบมากยิ่งขึ้น
สามารถ maintain ได้ง่าย
สามารถหาได้ง่าย ทีมต่าง ๆ ทำงานร่วมกันได้ดีขึ้น
รวมทั้งวิเคราะห์ผลกระทบต่าง ๆ จากการแก้ไขได้ดีขึ้น
เราจะทำอย่างไรดี ?

หนึ่งในแนวทางคือ Centralize system นั่นเอง
มีระบบหนึ่งที่น่าสนใจคือ EventCatalog
แบ่งเป็นหลาย ๆ กลุ่มดังนี้

• Boundary context map
• Domain
• Service
• Event
• Command
• Query
• Channel
• Flow

ในแต่ละส่วนจะแสดงแบบสวย ๆ และเข้าใจได้ง่าย
ยกตัวอย่างเช่น Order service จะมีส่วนประกอบอะไรบ้าง
แสดงดังรูป

ในส่วนของ Event หรือ message จะพบว่า
ใช้งานที่ queue/topic อะไร
ใครบ้างที่เป็น producer และ consumer

โดย EventCatalog นั้นจะสนับสนุน

• OpenAPI หรือ Swagger
• AsyncAPI
• Backstage
• Amazon EventBridge

นั่นหมายความว่า เราสามารถ generate ข้อมูล
เข้ามายัง EventCatalog ผ่าน plugin ที่เรียกว่า generator ได้เลย
แสดงรูปการทำงานดังรูป

ลองใช้งานกันดูครับ Getting start ...
จากที่ใช้งานมานั้น ง่ายมาก ๆ ครับ