แนวคิดเรื่องการออกแบบเว็บแอพลิเคชัน

สวัสดีครับ วันนี้เรามาคุยกันสั้นๆ เกี่ยวกับประเด็นที่ว่า “เราควรออกแบบ Web Application อย่างไร” กันดีกว่า ก่อนอื่นมาดูกันก่อนว่าเว็บแอพที่ดีต้องมีคุณสมบัติอะไรบ้าง

  1. User Friendly – ในแง่ของการออกแบบระบบ หมายถึง มีการตอบสนองอย่างต่อเนื่องและเหมาะสม หรือพูดง่ายๆ ก็คือ ความรู้สึกที่ผู้ใช้บอกว่า “เร็ว” นั่นเอง (ซึ่งอาจไม่ได้เร็วจริงๆ หรอก มันมีเทคนิค)
  2. Team Friendly – มีโครงสร้างที่ทำให้สามารถทำงานกันเป็นทีมได้อย่างสะดวก
  3. High Maintainability – บำรุงรักษาได้ง่าย
  4. Flexible – ปรับปรุง เปลี่ยนแปลงง่าย
  5. Scalable – สามารถขยับขยายให้รองรับปริมาณผู้ใช้ที่เติบโตขึ้นได้ง่าย

โครงสร้าง Web Application ที่ควรจะเป็น

webapp

เราควรผลักภาระมาไว้ที่ฝั่ง Front-end ให้มากที่สุดเท่าที่จะมากได้ แล้วเหลืออะไรก็เอาไปไว้ที่ฝั่ง Server โดยคุยกันผ่าน API เนื่องจากปัจจุบันงานหลายๆ อย่างสามารถทำที่ฝั่ง Client ได้ทันที เพราะการเข้ามาของเทคโนโลยี HTML5 และพลังประมวณผลของ Device ที่เพิ่มขึ้นนั่นเอง (มือถือสมัยนี้แรงกว่าคอมเมื่อ 10 ปีที่แล้วเสียอีก)

รู้หมือไร่? HTML5 สามารถเรียกใช้กล้อง > ถ่ายภาพ > Crop > ใส่ Filter แบบ Instagram ได้โดยไม่ต้องมีฝั่ง Server ด้วยซ้ำ

ปัจจุบันมี Tools ช่วยทำ Front-end Application มากมาย ที่คุ้นหูกันดีก็คงหนีไม่พ้น ReactJS, AngularJS และที่มาแรงฉุดไม่อยู่อีกตัว VueJS
แนวทางการออกแบบโครงสร้างเว็บแบบนี้ พี่ใหญ่เค้าก็ทำกันมาทั้งนั้น อย่าง ReactJS นี่ก็ของ Facebook มาที่ AngularJS นี่ก็ของ Google
อย่าง LinkedIn เค้าก็มี DustJS เหมือนกัน เว็บระดับโลกเค้ามาทางนี้กันหมดเลย

ดังนั้นงานแรกหลังจากที่เราเก็บ Requirements มาแล้ว เราจะให้ Front-end Developer เข้ามาช่วยประเมินดูก่อนว่าอะไรที่ทำบนฝั่ง Client ได้ แล้วที่เหลือ ก็ไปทำฝั่ง server

ต้องการตัวอย่าง? ได้! ตัวอย่างงานที่ต้องทำที่ฝั่ง Server เท่านั้นก็เช่น การล็อคอินไง ใช่ เรื่องง่ายๆ อย่างการล็อคอินก็เป็นงานของฝั่ง Server เช่นกันนะ

สิ่งสำคัญที่ควรตระหนักไว้อีกข้อหนึ่งก็คือ “อย่าไว้ใจ Input จากฝั่ง Front-end” ควรวางแผนให้ดีว่าอะไรที่ API ต้อง Validate ก่อน เช่น ทำเว็บขายของ ถึงเวลาจะตัดเงินแล้วก็ไม่ควรรับค่าจำนวนเงินจากฝั่ง Front-end เพราะ user สามารถแอบแก้ไขค่าเหล่านี้ได้เองเสมอ

“Front-end Application มีไว้อำนวยความสะดวกให้ User ใช้ API ได้ง่ายขึ้นเท่านั้น”

โอเค ต่อไปมาดูฝั่ง API กันบ้าง หลังจากที่ตัดสินใจแล้วว่าอะไรที่ต้องมี API เราก็มาทำการแยกแยะกันเลยว่า อะไร Cache ได้มั่ง?
ตรงนี้สำคัญมาก ไม่ว่าเว็บจะเล็กหรือใหญ่ เราก็ควรทำ Cache ไว้ เพราะเราไม่มีทางรู้หรอกว่าวันไหนเว็บเราจะเป็น Viral ขึ้นมา
อย่างน้อยถ้ามันจะตายไป ก่อนตายมันก็ควรรับ Traffic ได้มากๆ ก่อน ไม่ใช่เข้าแค่ 30 คนก็ตาย

ประเด็นต่อมา มี API ไหนต้อง Authen บ้าง? ในส่วนนี้แนะนำให้ศึกษา JWT กันต่อเลยครับ คลิก

น่าจะพอเห็นภาพแล้วเนอะ โอเค กลับมาที่คุณสมบัติ 5 ข้อที่เกริ่นไว้ตอนต้นกันเถอะ

User Friendly

พอเมื่อเว็บเราคุยกันผ่าน API แล้ว นั่นแปลว่าหลังจากที่ Document Ready ต่อไปเมื่อมีการเปลี่ยนหน้า ตัว Front-end Application มันก็จะทำการ ajax เอาแค่เนื้อหาส่วนที่เปลี่ยนแปลงไป โดยไม่จำเป็นต้องไปไล่โหลดทั้ง index.html ไฟล์ css ทุกไฟล์ ไฟล์ javascript ทุกไฟล์กันใหม่อีกรอบ เหมือนเว็บยุค 5 ปีที่แล้ว

ผลก็คือเว็บดูเหมือนจะโหลดไวขึ้นมาก เหตุผลแรก เพราะจำนวน request น้อยลง เหตุผลที่สอง เราสามารถทำ loading indicator มาเบี่ยงเบนความสนใจ user ได้ ทำให้เค้าไม่รู้สึกว่ากำลังรอเพราะมีอะไรให้ดูคั่นเวลาในขณะที่โหลด (นี่แหละเทคนิคที่บอก)

Team Friendly

จะเห็นได้ว่า เรามีการแบ่งเว็บออกเป็นสองส่วนหลักๆ อย่างชัดเจน คือฝั่ง Front-end กับฝั่ง API ดังนั้นการแบ่งงานจึงสามารถทำได้ง่าย ไม่ต้องปวดหัวกับการแก้ Conflict ใน git กันอีกต่อไป (มาทะเลาะกับทีมฝั่งใครฝั่งมันแทน ฮา)

High Maintainability

ปัญหาฝั่ง Front-end ก็ถูกจำกัดไว้อยู่ที่ฝั่ง Front-end ในขณะที่ปัญหาฝั่ง API ก็ถูกจำกัดไว้ที่ฝั่ง API เช่นเดียวกัน – ในทางซอฟต์แวร์นั้นเรารู้ดีว่าการแบ่ง Layer ออกมาดีๆ ทำให้การบำรุงรักษานั้นทำง่าย เนื่องจากสาเหตุหลักที่ทำให้การบำรุงรักษาเกิดความยากนั้นเกิดจากการแก้แล้วไปกระทบกับส่วนอื่น การแบ่งเว็บออกเป็นสองส่วนจึงช่วยป้องกันการแก้ไขแล้วไปกระทบกันได้เป็นอย่างดี

Flexible

วันดีคืนดี เบื้องบนสั่งลงมาให้เปลี่ยนหน้าตาเว็บได้แล้ว เบื่อแล้ว หากเป็นการทำเว็บแบบเดิมๆ นี่แทบจะต้องรื้อทำใหม่เลยทีเดียว ต่อให้เป็น MVC ก็เถอะ ยังไงก็กระทบ C ไม่มากก็น้อยเพราะอาจต้องมี action ใหม่ๆ เพิ่มมา แต่หลังจากที่เราออกแบบเว็บเป็นสองฝั่งแบบนี้ ฝั่ง API เราก็ไม่ต้องทำอะไร มาแก้ฝั่ง Front-end ก็พอ ลดงานที่ต้องทำลงไปได้มากเลย

Scalable

ข้อนี้สำคัญที่สุด สมมุติตอนแรกเป็นโปรเจคเล็กๆ เราจึงเลือกใช้ภาษา PHP, MySQL ทำ API เนื่องจากคุ้นมืองานจะได้เสร็จไวๆ แต่ต่อมาเว็บเป็นที่นิยม มีคนเข้าชมเยอะขึ้นมากๆ จน PHP เริ่มจะไม่ไหวแล้ว เราก็สามารถทำ API ขึ้นมาใหม่ด้วยเทคโนโลยีที่ Lean กว่า Scale ได้ง่ายกว่าได้ทันที (เช่น ใช้ NoSQL แทน หรือใช้ Golang แทน) พอทำเสร็จก็สลับ DNS ชี้ไปที่เซิร์ฟใหม่ได้แบบเนียนๆ User ไม่รู้สึกตัวด้วยซ้ำ โค้ดฝั่ง Front-end ก็ไม่ต้องแก้

จบแล้วครับโครงสร้างเว็บแอพที่ควรจะเป็นในปัจจุบัน เพื่อนๆ คนไหนมีคำถามสามารถเข้ามาพูดคุยกับเราได้ที่เพจ https://www.facebook.com/domecloud.io/ นะครับ 🙂