เบื้องหลัง AI Workflow Studio: จากไอเดียใน Portfolio สู่ระบบ Production ที่ตรวจสอบได้
Case study การพัฒนา AI Workflow Studio ให้เป็น operations console ที่ใช้งานจริง มี secure controls, execution stages รายรัน, SSE แบบ live, audit trail และระบบ deploy ที่ rollback ได้
- เผยแพร่
- เวลาอ่าน
- 12 นาที
AI Workflow Studio เริ่มจากช่องว่างสำคัญใน Portfolio ของผม ตอนนั้นมีทั้งเว็บไซต์ portfolio, Go backend, custom Open WebUI theme และ AI skills ที่นำกลับมาใช้ซ้ำได้แล้ว แต่ทั้งหมดนั้นยังไม่ได้แสดงให้เห็นว่าผมจะดูแล agentic product ตั้งแต่ต้นจนจบอย่างไร เป้าหมายจึงไม่ใช่การเพิ่มเดโมสวย ๆ อีกหนึ่งหน้า แต่คือการสร้าง control plane ที่จัดการ workflow, เริ่ม execution, ติดตาม timeline ของแต่ละ run, ป้องกันคำสั่งสำคัญ และรับมือกับ deployment failure ได้จริง
ทำไม Portfolio จึงต้องมีระบบ Operations จริง
Chat interface แสดงได้ว่าแอปสื่อสารกับโมเดล แต่ยังไม่ตอบคำถามที่สำคัญกว่าในงาน production เช่น ใครมีสิทธิ์เริ่มหรือยกเลิกงาน นิยาม workflow ถูกเก็บไว้ที่ไหน ผู้ดูแลเห็น stage ของ execution แต่ละรายการได้หรือไม่ และระบบจะทำอย่างไรเมื่อ backend ใช้งานไม่ได้ มี request ซ้ำ หรือ deployment ล้มเหลว AI Workflow Studio จึงถูกออกแบบให้ทำเรื่องเหล่านี้มองเห็นและตรวจสอบได้ แทนที่จะซ่อนไว้หลังกล่อง prompt ที่ดูดี
โครงสร้างสุดท้ายแบ่งหน้าที่ชัดเจน portfolio-2026 ใช้เล่าเรื่องและแสดง case study, AI Workflow Studio เป็น operations interface แบบ responsive, portfolio-backend-2026 ดูแล authentication, mutation rules, streaming และการเข้าถึงข้อมูล ส่วน Supabase เก็บ workflows, executions, stages และ audit records สำหรับ custom-ai-skills กับ n8n/workers ผมระบุไว้ตรงไปตรงมาว่าเป็น integration points สำหรับขั้นต่อไป ไม่ได้อ้างว่าเชื่อมอยู่ใน runtime ที่ deploy แล้ว
เริ่มจากโครงสร้างที่พร้อมขยายเป็น Production
Studio ถูกแยกเป็น repository ของตัวเอง ใช้ Next.js 16, React 19, TypeScript, Tailwind CSS และ Bun พร้อม standalone Docker image ที่รันแบบ non-root หน้า page.tsx ทำหน้าที่ประกอบหน้าเพียงเล็กน้อย ส่วน state และ effects แยกไปอยู่ใน hooks ขณะที่ workflow inventory, execution details, admin access และ forms แยกเป็น components ตามหน้าที่ ทำให้ control plane ขยายต่อได้โดยไม่กลายเป็นไฟล์ขนาดใหญ่ที่ดูแลยาก
การเชื่อมต่อ Backend ครั้งแรกตั้งใจให้ public เป็น read-only เท่านั้น GET /api/studio/overview ส่งเฉพาะข้อมูล workflow และ execution ที่ปลอดภัยจาก Go backend ฝั่ง UI มี request timeout, ตรวจสอบ response contract และมี seeded fallback เมื่อ backend สะดุด หน้า flagship demo จึงไม่กลายเป็นหน้าว่าง และผู้ใช้มองเห็นชัดเจนว่ากำลังดูข้อมูล live หรือ safe fallback
ปิดช่องโหว่ด้าน Security ก่อนเพิ่ม Controls
Control proxy รุ่นแรกไม่เปิดเผย server token แต่ public route ยังสามารถถูกใช้เป็น mutation oracle ได้ วิธีแก้จึงต้องเปลี่ยน architecture: ผู้เข้าชมทั่วไปเป็น read-only ส่วนคำสั่งสำคัญต้องผ่าน admin session ที่ยืนยันตัวตนแล้ว Browser ได้รับ cookie แบบ host-only, Secure, HttpOnly และ SameSite=Lax ขณะที่ same-origin BFF ส่งต่อเฉพาะ session cookie ที่กำหนดไว้ Privileged credentials และ internal backend origin จึงอยู่ฝั่ง server เท่านั้น
Authorization แยกตาม role โดย Admin และ Editor เปลี่ยนข้อมูลได้ ส่วน Viewer อ่าน authenticated lists และ audit records ได้ การ login ถูกจำกัดที่ 5 ครั้งต่อ IP ใน 15 นาที และ Studio mutations ถูกจำกัดที่ 30 ครั้งต่อ IP และ identity ต่อนาที Redis ใช้เป็น atomic counter พร้อม local fallback ระบบจะเชื่อ forwarded client address เฉพาะเมื่อเปิด proxy trust ชัดเจน และเลือก right-most valid hop ที่ Caddy append แทนการเชื่อ header ตำแหน่งแรกซึ่งปลอมได้ง่าย
ทุก protected action สร้าง persistent audit record โดยไม่เก็บ password, raw token, cookie, Authorization header หรือ credential อื่น ๆ ทำให้การสร้าง workflow, เริ่ม execution, pause, retry, approve และ cancel ตรวจสอบย้อนหลังได้ โดยไม่เปลี่ยนระบบ observability ให้กลายเป็นที่เก็บ secret
ทำให้ Execution เป็นข้อมูลจริง ย้อนสถานะได้ และติดตามได้
ข้อมูล workflow และ execution ถูกย้ายจาก presentation fixtures ไปเก็บใน Supabase ด้วย additive migrations API สำหรับสร้าง execution รับเฉพาะ active workflow และสร้าง run สถานะ running พร้อมค่า cost และ duration ที่ normalize แล้ว Production smoke tests เรียก create, pause, retry, approve และ cancel ผ่าน Studio boundary จริง การทดสอบ Approve และ Cancel ใช้ record ที่คืนสถานะได้ หลังตรวจเสร็จจึง restore demo state เดิม ขณะที่ audit trail ยังคงอยู่
Node list ระดับ workflow อย่างเดียวไม่เพียงพอสำหรับ live inspector เพราะ execution สองรายการของ workflow เดียวกันอาจอยู่คนละ stage จึงเพิ่ม StudioExecutionStage เพื่อเก็บ timeline ที่เรียงลำดับของแต่ละ execution พร้อม status, timestamps, safe detail และ tool metadata PostgreSQL RPC สร้าง execution และ stages ใน transaction เดียว ลดความเสี่ยงของ run ที่สร้างไม่ครบ ส่วน execution เดิมถูก seed stages แบบ idempotent ผ่าน migration ใหม่โดยไม่แก้ migration ที่ apply ไปแล้ว
Backend เปิด public read-only API สำหรับ stage snapshot และ SSE stream ตัว stream ส่ง initial snapshot, change events, heartbeat, event ID, reconnect guidance และกำหนดขอบเขต polling กับอายุ connection พร้อม cleanup timer เมื่อ client disconnect Browser เชื่อมผ่าน same-origin Next.js proxy และ React hook ที่ตรวจสอบ payload, จัดการ reconnect backoff, cleanup, connection status และ fallback ทำให้ panel แสดง stages ที่บันทึกไว้ของ run ที่เลือกจริง ไม่ใช่ animation กลาง ๆ ที่ใช้ร่วมกันทุก execution
Deploy ด้วย Immutable Image และ Rollback ได้
Pipeline ตรวจ tests, lint, builds, Go vet, deployment scripts และ Docker images ก่อน publish ทั้ง Backend และ Studio ใช้ image tag เป็น commit SHA เต็ม 40 ตัวแทน latest การเชื่อมต่อใช้ native OpenSSH พร้อม pinned known_hosts, ลบ temporary registry authentication หลังใช้งาน และ deployment script เปลี่ยนเฉพาะ image variable ของ service ที่เกี่ยวข้องโดยไม่เขียนทับ shared production environment file
Concurrency ใน GitHub repository เดียวไม่พอ เพราะ Backend และ Studio deploy มาจากคนละ repository จึงเพิ่ม VPS-wide flock เพื่อ serialize การเปลี่ยน Compose deployment หลังเริ่ม candidate image ระบบจะตรวจ public health gate ของ API หรือ Studio หากไม่ผ่านจะคืน previous successful immutable image อัตโนมัติ และ workflow_dispatch รองรับ manual rollback ไปยัง full SHA ที่เลือก เส้นทาง deployment และ rollback ถูกตรวจบน VPS จริง ไม่ได้หยุดอยู่ที่เอกสารหรือสมมติฐาน
สิ่งที่ Final QA ช่วยค้นพบ และก้าวต่อไป
รอบสุดท้ายทดสอบ Desktop, Tablet และ Mobile ทั้งหน้า Studio และ case study สองภาษา QA พบปัญหาที่ unit tests มองไม่เห็น ได้แก่ admin form ทำให้ viewport 390px กว้างเกินหน้าจอ, keyboard focus หลุดออกจาก dialog, session check ของผู้ใช้ read-only สร้าง 401 noise ใน console และคอลัมน์ execution ซ้อนกันบน mobile การแก้ไขจึงเพิ่ม dialog ที่จำกัดขนาดตาม viewport, initial focus และ focus trap, การคืน focus เมื่อกด Escape หรือ Cancel, clean read-only session response และ compact mobile execution cards จากนั้นตรวจซ้ำด้วย Playwright screenshots และ Production endpoints
ผลลัพธ์ไม่ได้เป็นเพียง interface ที่ดูเป็น AI แต่เป็นเส้นทางครบจากเรื่องราวใน Portfolio ไปสู่ control plane ที่ deploy แยก, Go API, Supabase persistence, secure sessions, rate limits, auditability, execution-specific streaming และ rollback-aware operations ขั้นต่อไปที่ตรงกับความจริงคือเชื่อม custom-ai-skills และ n8n หรือ dedicated workers เข้ากับ execution model ที่มีอยู่ แล้วเพิ่ม evaluation, token และ latency telemetry โดยยังรักษา security boundary ที่วางไว้ในระบบปัจจุบัน