คำถาม :: เขียนส่วนของ Business Logic ไว้ที่ไหนกันบ้าง ?

จากการ์ตูนขำ ๆ เรื่อง Business logic on the Frontend ก่อให้เกิดคำถามหนึ่งขึ้นมาคือ เราเขียน Business logic ของระบบไว้ที่ไหนกันบ้าง ?

1. Frontend ฝั่ง Client side เช่น JavaScript, Mobile app เป็นต้น
2. Frontend ฝั่ง Server side หรือเรียกว่า Web/Presentation Tier
3. Backend
4. Database เช่น Store procedure เป็นต้น

ผมเชื่อว่า developer หลาย ๆ คนน่าจะทำมาทั้งหมดแล้ว ล้วนแล้วแต่มีเหตุผล มีเงื่อนไข มีข้อจำกัดที่แตกต่างกันไป รวมทั้งต่างมีข้อดีและข้อเสีย แต่ถ้าทุกอย่างมันลงตัว จะอยู่ตรงไหนน่าจะสมเหตุสมผลมั้ง !!

บางคนอาจจะบอกว่า สิ่งที่เกิดขึ้นแล้วมันดีเสมอ !! สิ่งที่อยู่บน production ที่ทำงานได้ ก็ดีนะ !!

ยกตัวอย่างเช่น

ระบบงานพัฒนาด้วยภาษา JavaScript stack ในส่วนของ Frontend ฝั่ง client side นั้น ก็ใช้พวก JavaScript framework ต่าง ๆ ไม่ว่าจะเป็น React, Angular และ Vue บ่อยครั้งพบว่า นำ business logic รวมทั้งการควบคุม flow หรือ ขั้นตอนการทำงานไว้ในส่วนนี้ ส่วนของ Backend ก็เพียงสร้าง REST APIs ที่ทำงานเพียง CRUD (Create Read Update Delete) เท่านั้น ผลที่ตามมาคือ ส่วนมากจะแบ่งออกเป็น 2 ทีมคือ Frontend และ Backend งานในช่วงแรก ๆ Backend ดูเหมือนจะเยอะ แต่ไม่เยอะ เพราะว่า ทำเพียง CRUD เท่านั้น แต่งานในส่วนของ Frontend ดูเหมือนจะง่ายและน้อย กลับเยอะมาก ๆ ไหนจะส่วนของ UI ไหนจะส่วนของการจัดการกับ event/interaction จากผู้ใช้งาน ไหนจะส่วนการควบคุม flow การทำงาน มักจะเรียกว่า ร้อย flow การทำงาน ไหนจะจัดการกับ exception/error ต่าง ๆ ไหนจะ ... ดูแล้วเยอะไปหมด ยังไม่พอนะ เมื่อมีการเปลี่ยน UI และ Flow การทำงานมันจะนรกมาก ๆ พอปิดการ execute JavaScript ใน browser ก็ตายตามระเบียบ ทำการ validate ข้อมูลเฉพาะฝั่ง Frontend เท่านั้น !! จะจัดการ transaction กันอย่างไร ? ยังไม่พอนะ เราเห็นขั้นตอนการทำงานต่าง ๆ หมดเลย ฝั่ง Backend ก็ไว้ใจฝั่ง Frontend อีก ส่งข้อมูลอะไรมาก็ทำตามหมด โดยไม่สนใจ ไม่ตรวจสอบอะไรเลย เรื่อง security issue หนักเลย ปัญหาที่ตามมาอีกคือ ในแต่ละส่วนการทำงานนั้น เรียกใช้งาน Backend เยอะมาก ๆ เช่น การกดเพียง 1 ปุ่มเท่านั้น ก็ทำการเรียกฝั่ง Backend หลักสิบครั้งขึ้นไป !! มันเหมือนเป็นการระดมยิงระบบ แถมถ้าระบบ network ที่ใช้งานมีปัญหาก็น่าจะเกิดข้อผิดพลาดบ่อย ๆ ความน่าเชื่อถือของระบบก็น่าจะลดลงมั้ง มาถึงตรงนี้ชีวิตน่าจะนรกน่าดู

ดังนั้นเมื่อพัฒนาไปได้สักระยะหนึ่งเริ่มเจอปัญหาต่าง ๆ ที่ผ่านมา

จึงมีแนวคิดว่า เราน่าจะย้ายส่วน business logic และการควบคุม flow การทำงานมาไว้ที่ฝั่ง Backend นะ แต่เมื่อถึงเวลาทำก็ย้ายมาซะหมดเลย !! นั่นหมายความว่า งานฝั่ง Frontend มีเพียง การแสดงผล และ การจัดการ event ต่าง ๆ จากผู้ใช้งานเท่านั้น ส่วนการทำงานโยนมาฝั่ง Backend หมดเลย ผลที่ตามมาคือ จัดการเรื่อง transaction ได้ง่าย จัดการเรื่อง security ได้ง่าย แต่ งานฝั่ง Backend เยอะมาก ๆ บาง business logic มีขั้นตอนการทำงานที่เยอะและยาวนาน ฝั่ง Frontend ก็รอไป นานมาก ๆ ก็กำหนด timeout เยอะ ๆ ในส่วนการแสดงผลก็ดู loading กันไป แก้ไข business logic หนึ่งก็ไปกระทบส่วนอื่นอีก งานเยอะก็ bug เยอะ และปัญหาอื่น ๆ อีกเพียบ

ดูเหมือนว่าสองทางก็ไม่ค่อยรอดทำอย่างไรดีละ ?

บางครั้งก็เกิดสิ่งที่เรียกว่า Middleware ขึ้นมา ถ้าไปฝั่งใดฝั่งหนึ่งมันไม่ดี ดังนั้นเราหาระบบกลางขึ้นมาเพื่อจัดการ business logic ซะ !! ซึ่งเราจะเจอได้เยอะ เช่นพวก Enterprise Service Bus, API gateway รวมไปถึง GraphQL เป็นต้น แน่นอนว่าลดงานในส่วนของ Frontend และ Backend แต่เราได้เพิ่มความซับซ้อนของระบบ บ่อยครั้งจะกลายเป็น Single Point of Failure อีก (SPoF) เหมือนเรากำลังเจอปัญหา N + 1 นะ !! ชีวิตดูยากนะ แต่ผมเชื่อว่าแต่ละระบบมันมีคุณลักษณะที่แตกต่างกัน มีข้อจำกัด ไม่ใช่สิต้องบอกว่า ความท้าทายที่ต่างกัน ดังนั้นแบบไหนอาจะไม่ถูกหรือไม่ผิด แต่มันเหมาะสมไหม ? ทั้งจากองค์กรและทีม ดังนั้นระบบงานที่ดีมันจึงต้องพร้อมรับต่อการเปลี่ยนแปลงเสมอ ซึ่งการเปลี่ยนแปลงมันบ่อยเสียด้วย ระบบที่คุณกำลังสร้างมันตอบโจทย์เหล่านี้หรือไม่ ? ลองถามใจดูเอานะ

ยังไม่พอ บางระบบทำการเขียน business ไว้ใน Data Store เช่น Store procedure ใน RDBMS

เราจะเจอได้บ่อยกับของ Commercial และ Enterprise !! ถามว่า performance ดีไหม ? ตอบได้เลยว่าดี ถามว่า scale ได้ไหม ? ตอบได้เลยว่าได้ แต่ต้องแพงหน่อยนะ ถามว่าย้ายออกไปใช้อย่างอื่นได้ไหม ? ตอบเลยว่าได้ แต่ไม่มีใครกล้าหรอกนะ เพราะว่าของเดิมมันทำงานได้ !! คำถามที่น่าสนใจคือ คุณจะทำอย่างไรกับระบบเหล่านี้ บางคนอาจจะตอบว่า ทำใจ ถ้าเป็นคุณจะทำอย่างไร ?

คำถาม developer เขียน business logic ไว้ในส่วนใดบ้าง ?