บทความ IT เจ๋งๆ

ในบทความนี้เราจะกล่าวถึงข้อดีหลักๆ ของการใช้ SPA (Single Page Applications) Architecture ในขณะที่สร้าง Angular Applications ของเรา รวมทั้งมาดูคำตอบของคำถามที่มักพบบ่อยเกี่ยวกับ SPA กัน เชื่อว่าจะมีประโยชน์อย่างยิ่งสำหรับ Developer ทั้ง ”มือใหม่” และ “มือเก๋า”

ทำไมต้องใช้ SPA Architecture?

มาเริ่มคำถามแรกกันด้วย ทำไมต้องใช้ SPA Architecture? Application ชนิดนี้มีใช้กันมาหลายปีแล้ว แต่ก็ยังไม่เป็นที่นิยมแพร่หลายเท่าที่ควร

แล้วทำไมเป็นเช่นนั้น? มีทั้งเหตุผลที่ดีสำหรับสิ่งนั้น และเหตุผลที่ดีกว่าว่า ทำไมสิ่งนี้ถึงสามารถเปลี่ยนแปลงได้ในอนาคตอันใกล้

SPAs ได้ถูกนำเอาไปใช้อย่างมากมายในช่วงไม่กี่ปีที่ผ่านมา สำหรับการสร้างส่วนของ Private Dashboard ของ SaaS (Software as a Service) platforms หรือ Internet Services โดยทั่วไป รวมทั้งการสร้าง Enterprise Data-Driven และ Form-Intensive Applications

แล้ว Angular จะบังคับให้เราสร้าง Applications เป็นแบบ SPAs ไหม?

คำตอบคือ ไม่ได้บังคับ แต่นั่นเป็นความเป็นไปได้ที่น่าสนใจที่จะนำมาซึ่งการได้รับประโยชน์มากมายจากการสร้าง Applications ในแบบนั้น และนำเราไปสู่คำถามสำคัญ:

ทำไมคุณต้องการสร้าง Applications เป็นแบบ SPAs?

นี่เป็นสิ่งที่มักถูกมองข้ามไป ทุกคนกำลังสร้าง Applications ด้วยวิธีนี้ แต่ข้อดีของมันคืออะไรล่ะ? ต้องมี Features เด็ดๆ ที่ไม่เหมือนใครอย่างน้อยสัก 2-3 อย่างใช่ไหม?

มาเริ่มด้วย Features ที่ไม่ค่อยได้กล่าวถึงกันบ่อยนักคือ Production Deployment การเข้าใจถึงข้อดีของการใช้ SPA ใน Production จะช่วยตอบคำถามสำคัญได้

Single Page Application คืออะไร?

บางครั้งชื่อในแวดวง Software Development ก็ไม่ได้ถูกคัดเลือกมาดีเท่าใดนัก และอาจทำให้เกิดความสับสนได้ แต่นั่นไม่ใช่กรณีของ SPA: Single Page Application ที่แท้จริงแล้วมีเพียงหน้าเดียวเท่านั้น!!

หากคุณต้องการเห็นการใช้งาน Single Page Application เดียว คุณก็ลองเข้าไปที่ AngularUniv (https://angular-university.io) แล้วคลิกที่ Home page ใน List ของ Courses ล่าสุด ที่อยู่ตรง Menu ด้านบนดูสิ

หากคุณเริ่มต้นสำรวจดู คุณจะเห็นว่า Page นั้นไม่ได้ Reload มาทั้งหมด – เฉพาะ Data ใหม่ที่ได้รับการส่งผ่านมาขณะที่ Users สำรวจผ่านทาง Application ซึ่งนี่เป็นตัวอย่างของ Single Page Application

ต่อไปเรามาดูข้อดีของการสร้าง Application แบบนั้นมีอะไรบ้าง และวิธีการทำงานของมัน

ใช้ Chrome Dev Tools ในการช่วยตรวจสอบ index.html ของ AngularUniv website ที่ Download อยู่บน Home page (หรือ Page อื่นๆ ก็ได้ แล้วกด Refresh)

Page ที่ได้รับการ Download นั้นเป็น Request แรกที่คุณจะเห็นใน Chrome Network tab panel ซึ่งเป็น Single Page ของ Application ของเรา มีข้อสังเกตอย่างหนึ่งคือ Page นี้เกือบจะว่างเปล่า ยกเว้น Tag ที่ไม่มีอะไรเกิดขึ้นกับมัน

หมายเหตุ: บน Website จริงนั้น Page ที่ Download มามี HTML ที่ถูก Pre-Render ไว้บน Server โดยใช้ Angular Universal

สังเกตชื่อของ CSS และ JavaScript bundles: CSS ทั้งหมดและแม้แต่ JavaScript ทั้งหมดของ Application (ซึ่งรวมถึง Angular) ไม่ได้มาจาก Server เดียวกันกับ index.html แต่มาจาก Static Server ที่ต่างกันโดยสิ้นเชิง:

"ในกรณีนี้ Bundles ทั้ง 2 ชุดนั้นมาจาก Amazon S3 Bucket"

นอกจากนี้ สังเกตได้ว่า ชื่อของ Bundles เหล่านั้น ก็คือ Version: มันประกอบด้วย Timestamp ของการสร้าง Deployment ที่ถูก Execute ซึ่งได้ Deploy Application ใน Version นั้นโดยเฉพาะ

ข้อดีเกี่ยวกับ Production Deployment ของ Single Page Applications

จากสถานการณ์ที่เราได้เห็นข้างต้น ถือเป็นข้อดีที่ยอดเยี่ยมมากของ Single Page Applications:

"Single Page Applications นั้นง่ายต่อการ Deploy ใน Production เป็นอย่างมาก รวมทั้งทราบถึง Version ต่างๆ ของพวกมันอีกด้วย"

Single Page Applications นั้นใช้งานง่ายกว่า เมื่อเทียบกับ Server-Based Applications แบบดั้งเดิม: มันเป็นเพียง index.html File 1 File โดยมี CSS bundle และ JavaScript bundle

Static File ทั้ง 3 นี้ สามารถถูก Upload ไปยัง Static Content Server อย่าง Apache, Nginx, Amazon S3 หรือ Firebase Hosting ได้

แน่นอนว่า Application จะต้องเรียกไปที่ Backend เพื่อทำการดึงข้อมูลมา แต่นั่นเป็น Server ที่แยกกันต่างหากซึ่งสามารถถูกสร้างขึ้นมาได้หากจำเป็น ด้วยเทคโนโลยีที่แตกต่างอย่างสิ้นเชิง เช่น Node, Java หรือ PHP

อันที่จริงแล้ว ถ้าเราจะสร้าง REST API ของเราหรือ Backend ประเภทอื่นใน Node เราก็สามารถสร้างมันใน Typescript ได้เช่นกันเพื่อให้สามารถใช้ภาษาเดียวกันได้ทั้งบน Server และ Client และสามารถ Share Code ได้ระหว่างพวกมันเอง

Version ของ Single Page Applications ใน Production

ข้อดีอีกประการของการ Deploy Frontend เป็น Single Page Application ก็คือ การกำหนด Version และ Rollback สิ่งที่เราต้องทำคือ การสร้าง Version ของ Output ที่เราสร้างขึ้นมา

เราสามารถ Configure ค่าบน Server ที่รองรับ SPA ของเราอยู่ ด้วย Parameter ที่ระบุ Version ของ Frontend Application เพื่อสร้างมันขึ้นมา ซึ่งมันง่ายมาก

การ Deploy ประเภทนี้ สามารถปรับขนาดได้เป็นอย่างดี: Static Content Servers อย่าง Nginx สามารถปรับขนาดเพื่อรองรับ User เป็นจำนวนมากๆ ได้

แน่นอนว่า การ Deploy ประเภทนี้และการกำหนด Version สามารถใช้ได้เฉพาะกับส่วนของ Frontend ของ Application ซึ่งจะไม่สามารถใช้ได้กับ Backend Server แต่ถึงกระนั้นมันก็ยังคงเป็นข้อดีที่จำเป็นต้องมี

แต่ Production Deployment ถือเป็นข้อดีเพียงอย่างเดียวของ Single Page Application ใช่หรือไม่? แน่นอนว่า “ไม่” มันยังมีข้อดีอื่นๆ อีก

Single Page Applications และ User Experience

หากคุณเคยใช้ Web Application ที่ทำการ Reload ทุกสิ่งจาก Server อย่างต่อเนื่องในเกือบจะทุกๆ Interaction ของ User คุณจะรู้ได้ทันทีว่า Application ประเภทนั้นให้ User Experience ที่ไม่ดี เนื่องจาก

• มีการ Reload Full Page อย่างต่อเนื่อง
• เนื่องจาก Network นั้น เดินทางทั้งไปและกลับ ไปยัง Server เพื่อดึงข้อมูล HTML ทั้งหมด

ใน Single Page Application เราสามารถแก้ไขปัญหานี้ได้โดยใช้แนวทางของสถาปัตยกรรมที่แตกต่างกันโดยพื้นฐาน:

บน SPA หลังจาก Load Page มาแล้ว จะไม่มีการส่ง HTML ผ่าน Network อีก มีเพียงแต่ Data ที่จะได้รับการ Request จาก Server เท่านั้น (หรือส่งไปยัง Server)

ดังนั้นขณะที่ SPA กำลัง Run อยู่ จะมีเฉพาะ Data ที่ถูกส่งผ่านสายสัญญาณซึ่งใช้เวลาและ Bandwidth น้อยกว่าการส่ง HTML อย่างต่อเนื่อง ลองมาดูประเภทของ Payload ที่ส่งผ่านสายสัญญาณใน SPA

ตัวอย่างเช่น ใน AngularUniv SPA หากคุณคลิกที่ Course จะไม่มีการส่ง HTML ผ่านสายสัญญาณ แต่เราจะได้ Ajax Request ที่รับ JSON Payload ด้วย Data ของ Course ทั้งหมด:

จะเห็นว่า HTML Version จะมีขนาดใหญ่กว่ามาก เมื่อเทียบกับ JSON Object เนื่องจาก Opening และ Closing Tags ทั้งหมด แต่จะมี Duplicate HTML มากมาย หากเรา Load Page ที่คล้ายกันอย่างต่อเนื่องซ้ำแล้วซ้ำอีก

ตัวอย่างเช่น ส่วนของ Headers และ Footers ของ Page จะถูกส่งไปยัง Browser อย่างต่อเนื่อง แต่พวกมันก็ไม่ได้มีอะไรที่เปลี่ยนไป

ด้วยเหตุนี้ เราจึงมีข้อดีอย่างมากอีกข้อของ Single Page Application: มีการปรับปรุงเรื่องของ User Experience ได้ดีขึ้นมาก เนื่องจากมีการ Reload Full Page ที่น้อยลง และเพิ่มประสิทธิภาพโดยรวมให้ดีขึ้นเนื่องจากการใช้ Bandwidth ที่น้อยลงถือเป็นเรื่องจำเป็น

แล้วทำไม เราถึงไม่ใช้ SPAs กันทั้งหมดล่ะ

หาก SPAs มีข้อดีอยู่มากมาย แล้วเหตุใดจึงไม่ถูกนำไปใช้ใน Scale ที่ใหญ่ขึ้นอย่าง Internet สาธารณะล่ะ?

เมื่อไม่นานมานี้ Search Engine ย่าง Google มีช่วงที่ยากลำบากในการจัดทำ Index สำหรับ Single Page Application ให้ถูกต้อง แล้วตอนนี้ล่ะ?

ในอดีตมีการแนะนำให้ใช้ Ajax Crawling Scheme แบบพิเศษซึ่งตอนนี้เลิกใช้ไปแล้ว ดังนั้น ตอนนี้ Google ก็สามารถ Render Ajax ได้อย่างสมบูรณ์แล้ว ใช่หรือไม่?

ในการประกาศอย่างเป็นทางการ มีข้อมูล Google Search ที่บอกว่าขณะนี้สามารถ Crawl Ajax ได้แล้ว แต่ก็มีบางรายงานที่ระบุว่ายังไม่สามารถทำได้

อีกทั้งมีการแนะนำให้ใช้ Progressive Enhancement แทน นั่นหมายถึงว่า ณ ตอนนี้มีความเป็นไปได้ที่จะใช้ SPAs ใน Internet สาธารณะ แล้วหรือไม่?

Search Engine ทำงานร่วมกันได้ดีกับ SPAs หรือไม่?

มันเป็นไปได้ ที่จะมี Performance และ User Experience ของ SPA พร้อมด้วย SEO Properties ที่ดี: การใช้ Angular Universal Pre-Rendering Engine ช่วยให้เรา:

• ทำการ Pre-Render Application บน Backend ได้
• ส่ง HTML ไปยัง Browser พร้อมกับ Angular
• มี Angular bootstrap บน Client side และ ทำหน้าที่เหมือนเป็น SPA

จะพบเห็นการใช้ SPAs บ่อยมากขึ้นในอนาคตใช่ไหม?

ลองนึกภาพ SEO friendly version ของ Amazon ที่จะไม่ Refresh ตัวเองในแต่ละ Page ที่ Reload ขึ้นมา พร้อมทั้งมีการปรับปรุง Performance และ User Experience ให้ดีกว่าเดิมขึ้นมาก: มันน่าจะส่งผลดีอย่างมากในเรื่องของเวลาที่ลูกค้าใช้งานใน Site

ข้อดีในด้านเทคนิคของ SEO-friendly SPAs นั้นมีความสำคัญ โดยเฉพาะอย่างยิ่งบน Mobile และเป็นที่คาดหวังว่า SEO Friendly SPA Applications ประเภทนี้ จะถูกใช้งานบ่อยขึ้นในอนาคต รวมทั้งบนอิน Internet สาธารณะด้วย

แต่คำถามสุดท้ายของ Session นี้ยังไม่ได้รับคำตอบ คุณต้องคิดเอาหลังจากที่ได้อ่านหัวข้อท้ายๆ แล้ว:

หากมีการ Load HTML เพียงเล็กน้อยเท่านั้นจาก Server ในช่วงเริ่มต้น แล้ว Page จะมีการเปลี่ยนแปลงไปเรื่อยๆ ไหม? ซึ่งจะนำเราไปสู่คำถามสุดท้ายของ Section นี้ และอาจสำคัญที่สุดด้วย

Single Page Application ทำงานอย่างไร

ที่จริงแล้ว พวกมันทำงานเพราะเราโหลด HTML เพียงเล็กน้อยจาก Server ใช่ไหม? เมื่อ Application เริ่มถูกใช้งาน จะมีเพียง Data ผ่านสายสัญญาณ แล้ว HTML ใหม่มาจากไหน?

เนื่องจาก ต้องมี HTML ใหม่ที่ถูกสร้างขึ้นที่ไหนสักแห่ง ทำให้นั่นเป็นทางเดียวที่ Browser จะเปลี่ยนสิ่งที่แสดงอยู่ใช่หรือไม่?

คำตอบนั้นง่ายมาก และเกี่ยวข้องกับวิธีที่ Single Page Application ใช้งานได้จริง เมื่อเปรียบเทียบกับ Server-Based Applications แบบดั้งเดิม

ใน Applications แบบดั้งเดิม (ซึ่งรวมถึง Internet สาธารณะส่วนใหญ่ในปัจจุบัน) นั้น การแปลง Data ไปเป็น HTML (หรือ Rendering) จะถูกดำเนินการในฝั่งของ Server

ในทางกลับกัน Single Page Application กลับทำในลักษณะที่แตกต่างไปมาก:

"ใน SPA นั้น หลังจากเริ่มใช้ Application กระบวนการในการแปลง Data ไปเป็น HTML ถูกย้ายจากฝั่ง Server ไปยัง Client - SPA มี Template Engine ที่ทำงานใน Browser ของคุณ"

ดังนั้น ด้วยข้อมูลที่มีอยู่ในมือของเราทั้งหมด เรามาสรุปประเด็นสำคัญเกี่ยวกับ Single Page Application กัน

สรุป : ข้อดีของ SPA และแนวคิดหลักเกี่ยวกับวิธีการทำงานของมัน

การสร้าง Application เป็นแบบ SPA จะมีประโยชน์กับเราหลายประการ คือ:

• เราจะสามารถนำ Experience ที่ได้รับการปรับปรุงให้ดีขึ้นไปสู่ User
• จะรู้สึกว่า Application เร็วมากขึ้น เนื่องจากมีการใช้ Bandwidth ที่น้อยลง และไม่มีการ Refresh Full Page เมื่อ User ใช้งาน Application
• Application จะถูก Deploy ใน Production ได้ง่ายกว่า อย่างน้อยก็ในส่วนของ Client: ทั้งหมดที่เราต้องการคือ Static Server ที่คอย Serve อย่างน้อย 3 ไฟล์ คือ Single Page index.html ของเรา, CSS bundle และ JavaScript bundle
• นอกจากนี้เรายังสามารถแบ่ง Bundles ออกเป็นหลายส่วน หากจำเป็นต้องมีการแยก Code ออกเป็นส่วนๆ
• ในส่วนของ Frontend ของ Application จะสามารถกำหนด Version ใน Production ได้ง่ายมาก รวมทั้งง่ายในการ Deploy และ Rollbacks กลับไปสู่ version ก่อนๆ ของ Frontend หากจำเป็น

สถานการณ์อื่นๆ เกี่ยวกับ Production

สถานการณ์อื่นๆ ในที่นี้ เช่น การ Pre-Rendering ในส่วนที่มีขนาดใหญ่ของ Application และ Upload ทุกสิ่งทุกอย่างไปยัง Static Hosting Server, In-Memory Caching บน Server ของ Pages ปัจจุบัน, สร้าง Version โดยใช้ DNS เป็นต้น

ปัจจุบันการสร้าง SEO-Friendly SPAs นั้นง่ายกว่าแต่ก่อนมาก ดังนั้น พวกมันจึงมีแนวโน้มที่จะถูกนำไปใช้งานมากขึ้นในอนาคต หรือในสถานการณ์ที่ SPAs ไม่ได้ถูกใช้งานบ่อยนัก

วิธีการทำงานของ SPA

วิธีการที่ Single Page Applications จะนำข้อดีเหล่านี้ไปเชื่อมโยงกับวิธีการทำงานภายในของมัน:

• หลังจากการเริ่มใช้งาน Data จะถูกส่งผ่านสายสัญญาณ เป็น JSON Payload หรือในรูปแบบอื่นๆ แต่จะไม่มีการส่ง HTML หรือ CSS อีกต่อไปหลังจากที่ Application กำลัง Run อยู่

ประเด็นสำคัญ ในการทำความเข้าใจว่า Single Page Applications ทำงานอย่างไร มีดังต่อไปนี้:

"แทนที่จะแปลง Data ไปเป็น HTML บน Server แล้วส่งผ่านสายสัญญาณไป แต่ใน SPA ได้ย้ายกระบวนการแปลงนั้นจาก Server ไปเป็น Client"

การเปลี่ยนแปลงเกิดขึ้นในฝั่ง Client ซึ่งทำให้เราสามารถมอบ User Experience ที่ดียิ่งขึ้นให้กับ User

ถึงตรงนี้ เชื่อว่าคุณคงเห็นแล้วว่า ข้อดีของ Single Page Applications มีอะไรบ้าง เชื่อว่ามันจะเป็นประโยชน์กับคุณอย่างมากในการนำมันไปประยุกต์ใช้กับงานจริงของคุณ

ที่มา:  https://blog.angular-university.io/