เราจะก้าวไปสู่ระดับความซับซ้อนในปัจจุบันได้อย่างไรทีละขั้นตอน
การพัฒนาเว็บไซต์ โดยเฉพาะส่วนหน้า ถือเป็นอาชีพที่ท้าทายที่สุดอย่างหนึ่งในการพัฒนาซอฟต์แวร์อย่างไม่ต้องสงสัย ภูมิทัศน์มีการพัฒนาอย่างต่อเนื่อง เครื่องมือและเทคโนโลยีล้าสมัยและถูกแทนที่ด้วยสิ่งใหม่อย่างรวดเร็วอย่างน่าประหลาดใจ มันยังกลายเป็นสาขาที่กว้างใหญ่เกินกว่า HTML, CSS และ Javascript ย้อนกลับไปสิบปี คุณลองนึกภาพดูไหมว่า Frontend Developer ที่ใช้ภาษาที่ตีความในการเขียนโค้ด จะต้องยุ่งกับเครื่องมือการคอมไพล์ทุกประเภทในงานประจำวันของพวกเขา ค่อนข้างบ้าใช่มั้ย?
แต่กรุงโรมไม่ได้สร้างเสร็จในวันเดียว ย้อนเวลากลับไปเพื่อดูว่าเรามาถึงที่นี่ได้อย่างไรทีละขั้นตอน
“ประวัติศาสตร์ไม่สามารถให้แผนงานสำหรับอนาคตแก่เราได้ แต่สามารถทำให้เราเข้าใจตนเองและมนุษยชาติร่วมกันของเราได้ครบถ้วนยิ่งขึ้น เพื่อที่เราจะสามารถเผชิญกับอนาคตได้ดีขึ้น”
— โรเบิร์ต เพนน์ วอร์เรน
เซิร์ฟเวอร์ไฟล์แห่งความสุข
สถาปัตยกรรมเว็บเริ่มต้นด้วย ไม่มีสถาปัตยกรรมเลย เว็บไซต์แรกสุดเป็นเพียงเซิร์ฟเวอร์ไฟล์ที่เข้าถึงได้แบบสาธารณะซึ่งเข้าใจคำขอ HTTP และส่งคืนไฟล์ HTML ไปยังไคลเอนต์
หลายคนต้องประหลาดใจที่เว็บไซต์ดังกล่าวยังคงอยู่และทำงานได้ดีมาก ตัวอย่างเช่น Craigslist ดูเหมือนฟอสซิลที่มีชีวิต — เนื้อหาคงที่อย่างสมบูรณ์, ไฟล์ HTML ล้วนๆ, ไม่มีภาพ, ไม่มีการออกแบบ; อย่างไรก็ตาม มันยังคงอยู่ในอันดับที่ #78 ของการเข้าชมจากเว็บไซต์ทั้งหมดทั่วโลก เป็นข้อพิสูจน์ถึงพลังแห่งความเรียบง่าย
แต่ไม่ใช่ว่าทุกธุรกิจจะสามารถดำรงตัวเองไว้ได้ในฐานะฟอสซิลที่มีชีวิต ข้อมูลที่บริษัทออนไลน์เป็นเจ้าของในไม่ช้าก็ซับซ้อนเกินกว่าจะจัดการเป็นไฟล์ธรรมดาได้ ในเวลาเดียวกัน ผู้ใช้ไม่พอใจกับการมีส่วนร่วมทางอินเทอร์เน็ต พวกเขาต้องการปฏิสัมพันธ์ ปัจจัยทั้งสองนี้ทำให้เกิดการก้าวกระโดดครั้งแรกของสถาปัตยกรรมเว็บ
การเปลี่ยนไปสู่เนื้อหาแบบไดนามิก
มีการเปลี่ยนแปลงที่สำคัญสองประการ ประการแรกคือฐานข้อมูลเริ่มเข้ามาเกี่ยวข้อง — มีความหลากหลายมากกว่าไฟล์แบบคงที่ ประการที่สองคือเซิร์ฟเวอร์เริ่มรันโปรแกรมเพื่อสร้างเอกสาร HTML ทำให้ไคลเอนต์ที่แตกต่างกันสามารถดูเนื้อหาที่แตกต่างกันได้
จากมุมมองของลูกค้า ทุกอย่างค่อนข้างจะเหมือนกัน หน้าเว็บถูกเติมโดยคำขอเอกสาร HTML เดียว เมื่อผู้ใช้นำทางหรือส่งข้อมูล ทั้งหน้าจะรีเฟรช พอร์ทัลและเว็บไซต์ข่าวเป็นตัวอย่างที่ดีของสถาปัตยกรรมดังกล่าว พวกเขาจัดเก็บและสร้างเนื้อหาจำนวนมากและสามารถให้บริการจัดส่งที่ปรับแต่งตามโปรไฟล์ของผู้ใช้ พวกเขายังอนุญาตให้มีการโต้ตอบบ้างแต่น้อยมากเมื่อเทียบกับเว็บแอปสมัยใหม่
ทั้งหมดนี้ทำงานได้ดีมาระยะหนึ่งแล้วจนกระทั่งเว็บไซต์มีการโต้ตอบมากมายจนทำให้หน้าเว็บที่รีเฟรชอยู่ตลอดเวลากลายเป็นเรื่องที่น่ารำคาญจนทนไม่ไหว ดังนั้นก้าวกระโดดครั้งต่อไปของสถาปัตยกรรมเว็บคือการทำให้การโต้ตอบคล่องมากขึ้น
การเพิ่มขึ้นของสปา
อย่างที่คุณเห็น จู่ๆ สิ่งต่างๆ ก็เริ่มวุ่นวายทั้งฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ ภาวะแทรกซ้อนนี้มีเหตุผลหลายประการ:
- เว็บกลายเป็นช่องทางการสื่อสารสองทางช่างพูด การโต้ตอบของผู้ใช้เกิดขึ้นตลอดเวลา ทำให้เนื้อหาของหน้าเปลี่ยนแปลงไปด้วย มันเกี่ยวข้องกับการแลกเปลี่ยนข้อมูลแบบไดนามิกจำนวนมากและการจัดการองค์ประกอบของหน้าอย่างรวดเร็ว
- เว็บไซต์หลายแห่งได้รับปริมาณการเข้าชมและข้อมูลจำนวนมหาศาล และความสามารถในการ "ขยายขนาด" ได้กลายเป็นหัวข้อที่สำคัญ
ความก้าวหน้าทางเทคโนโลยีหลายประการมาทันเวลาและทำให้การก้าวกระโดดนี้เกิดขึ้นได้:
- เบราว์เซอร์มีความแข็งแกร่งขึ้นมาก โดยเฉพาะอย่างยิ่งในการดึงข้อมูลแบบไดนามิก ("AJAX") และการจัดการ DOM
- โครงสร้างพื้นฐานเครือข่ายมีความแข็งแกร่งและรวดเร็วยิ่งขึ้น โดยปัจจุบัน CDN เป็นสินค้าโภคภัณฑ์
- เทคโนโลยีการจำลองเสมือนฝั่งเซิร์ฟเวอร์ (Docker, Linux Container ฯลฯ) ได้พัฒนาเต็มที่แล้ว
- เฟรมเวิร์กส่วนประกอบ Dawn of UI - Angular, React, Vue
ต่างจากสถาปัตยกรรมก่อนหน้านี้ SPA (แอปพลิเคชันหน้าเดียว) เป็นแอปพลิเคชันของแท้ที่ทำงานภายในเบราว์เซอร์ พวกเขามีกรอบการพัฒนาของตัวเอง มีการปรับใช้แยกกัน มีสถานะที่สมบูรณ์ และอาจซับซ้อนเท่ากับโค้ดหลายล้านบรรทัด พอร์ทัลของ Microsoft Azure อ้างว่าเป็น SPA ที่ใหญ่ที่สุดในโลก และนี่คือ LOC ภายในปี 2559
วิธีการทำงานของ SPA นั้นแตกต่างไปจากเว็บไซต์ก่อนหน้านี้อย่างสิ้นเชิง แอปพลิเคชันส่วนหน้าจะรวมอยู่ในไฟล์ Javascript ขนาดใหญ่สองสามไฟล์ เบราว์เซอร์โหลดจาก CDN เรียกใช้เพื่อดึงข้อมูลจาก API แบ็กเอนด์ จากนั้นเรนเดอร์ UI
นี่เป็นช่วงเวลาที่จิตใจของนักพัฒนาส่วนหน้าระเบิดและงานของพวกเขาเริ่มแตกสลาย วันดีๆเก่าๆก็หายไป มีหลายสิ่งที่ต้องเรียนรู้ เครื่องมือที่ต้องรัน และปัญหาที่ต้องแก้ไข เป็นผลให้ความซับซ้อนของการพัฒนาส่วนหน้าถึงระดับใหม่
ยุคไฮบริด
สปานั้นค่อนข้างเจ๋ง แต่ก็ไม่ได้ไร้ข้อบกพร่อง นี่คือปัญหาสำคัญสองประการ:
- แม้ว่าพวกเขาจะมอบประสบการณ์การโต้ตอบที่ยอดเยี่ยม แต่เวลาในการโหลดครั้งแรกก็ค่อนข้างช้า ต้องดาวน์โหลดและดำเนินการแอปพลิเคชันทั้งหมดก่อนจึงจะแสดงเนื้อหาที่มีความหมายชิ้นแรกได้ พวกเขายังมีแนวโน้มที่จะแสดงสปินเนอร์แล้วสปินเนอร์เนื่องจากน้ำตกของการโหลดข้อมูลแบบไดนามิก
- สิ่งเหล่านี้ไม่ดีสำหรับ SEO เพราะสิ่งที่เซิร์ฟเวอร์ส่งคืนไม่ใช่ HTML แม้กระทั่งทุกวันนี้ โปรแกรมรวบรวมข้อมูลของเครื่องมือค้นหาก็ยังไม่สามารถรองรับเว็บไซต์ SPA ส่วนใหญ่ได้
เมื่อมีข้อสงสัย ให้พัฒนาสถาปัตยกรรม 😄
แนวคิดนี้ค่อนข้างง่าย: ลองใช้เซิร์ฟเวอร์ไฟล์คงที่แบบเก่าเพื่อให้บริการเอกสาร HTML เริ่มต้น จากนั้นปล่อยให้ SPA เข้ามาดูแลส่วนที่เหลือ ด้วยวิธีนี้ เวลาโหลดครั้งแรกจะลดลงอย่างมาก และปัญหา SEO ได้รับการแก้ไข
สิ่งใหม่ๆ ที่เปิดใช้งานกระบวนทัศน์ใหม่นี้คือ “meta-framework” เช่น Next.js, Nuxt.js เป็นต้น ซึ่งล้อมรอบเฟรมเวิร์กส่วนประกอบ UI และเปลี่ยนให้เป็นเฟรมเวิร์กแอปพลิเคชัน ตอบสนองต่อคำขอ HTTP และส่ง HTML ที่แสดงผลล่วงหน้า นอกจากนี้ยังให้วิธีการแสดงหน้าคงที่ล่วงหน้าและพุชไปยัง CDN ในขณะสร้าง
ผลข้างเคียงที่น่าทึ่งอย่างหนึ่งเกิดขึ้นที่นี่: ส่วนหน้าเริ่มมี "แบ็กเอนด์" ของตัวเองแล้ว เราควรเรียกมันว่า "fronckend" หรือ "middle-end" หรือไม่? แม้ว่าความรับผิดชอบหลักคือการแสดงหน้าเว็บล่วงหน้า แต่เมื่อเวลาผ่านไป ผู้คนก็เริ่มมีความคิดสร้างสรรค์และปล่อยให้มันรับหน้าที่มากขึ้น เราค่อยๆ เลื่อนเข้าสู่ขั้นตอนต่อไปของสถาปัตยกรรมเว็บ
Serverless คือสีดำตัวใหม่
ตอนนี้เราอยู่ในการพัฒนาสถาปัตยกรรมครั้งล่าสุด พูดตามตรง ฉันคิดว่า "ไร้เซิร์ฟเวอร์" เป็นคำที่ไม่ดีในที่นี้ เพราะมันอาจหมายถึงหลายสิ่งหลายอย่างและซ้อนทับกับสิ่งที่เกิดขึ้นที่นี่เพียงบางส่วนเท่านั้น แต่ฉันจะใช้มันต่อไป
ทุกอย่างเริ่มต้นด้วยคำถามโง่ๆ: “ในเมื่อส่วนหน้าของฉันตอนนี้มีแบ็กเอนด์ที่เป็นประกายของตัวเอง ทำไมฉันยังต้องการแบ็กเอนด์แยกต่างหาก?” คำตอบคือคุณไม่ทำ ในหลายกรณี เมตาเฟรมเวิร์กสามารถครอบคลุมความต้องการแบ็กเอนด์ทั้งหมดของคุณได้
การเปลี่ยนแปลงที่สำคัญบางประการ:
- แบ็กเอนด์ที่แยกจากกันหายไป
- แบ็กเอนด์ของส่วนหน้าของเราถูกแทนที่ด้วย "ขอบ" เป็นส่วนใหญ่ Edge คือโหนดการคำนวณสายพันธุ์ใหม่ที่มีการปรับใช้ทั่วโลก พวกมันเหมือนกับ CDN แต่สามารถรันโค้ดแบบกำหนดเองได้ ทำให้พวกมันเหมาะสำหรับการจัดการการคำนวณทางเว็บ
- พื้นที่เก็บข้อมูลได้รับการจัดการโดยฐานข้อมูล "ไร้เซิร์ฟเวอร์" สายพันธุ์ใหม่ (โฮสต์แยกกัน) ซึ่งเกิดมาเพื่อให้ทำงานได้ดีกับการเชื่อมต่อจากขอบ
สถาปัตยกรรมใหม่มีการปรับปรุงสองประการ:
- เมื่อแบ็กเอนด์ที่แยกจากกันหมดไป ชิ้นส่วนที่เคลื่อนไหวก็น้อยลง และระบบก็ง่ายขึ้นมากในแง่ของการพัฒนา การปรับใช้ และการดำเนินงาน
- เนื่องจากการคำนวณเกิดขึ้นที่ Edge การเรนเดอร์เพจฝั่งเซิร์ฟเวอร์และการโหลดข้อมูลแบบไดนามิกจึงเร็วขึ้นมากเนื่องจากอยู่ใกล้กันมากขึ้น
ค่าใช้จ่าย? ตอนนี้คุณไม่เพียงแต่ต้องปรับใช้เมตาเฟรมเวิร์กเท่านั้น แต่ยังต้องปรับใช้แอปของคุณกับแพลตฟอร์มแบบไร้เซิร์ฟเวอร์ที่เข้ากันได้ด้วย — Vercel, Netlify, Fly.io ฯลฯ
สถาปัตยกรรมมีวิวัฒนาการ และความรับผิดชอบเปลี่ยนไป
ตอนนี้ถึงเวลาแล้วที่นักพัฒนาส่วนหน้าจะเรียกตนเองว่านักพัฒนาแบบฟูลสแต็คอย่างภาคภูมิใจ พวกเขาเป็นอิสระจากข้อจำกัดของทีมแบ็กเอนด์และสามารถให้บริการแบบ end-to-end ได้โดยอัตโนมัติ อย่างไรก็ตาม พลังที่ยิ่งใหญ่มาพร้อมกับความรับผิดชอบที่ยิ่งใหญ่ สิ่งสำคัญในการเป็นนักพัฒนาแบบฟูลสแตกนั้นมีมากกว่า HTML/CSS/JavaScript เมื่อสถาปัตยกรรมรวมตัวกัน หน้าที่ก็เช่นกัน:
มันเป็นช่วงเวลาที่ดีที่สุดหรือแย่ที่สุด? อาจเป็นทั้งสองอย่าง เครื่องมือและกรอบการทำงานที่เรามีอยู่ในปัจจุบันเป็นสิ่งที่ไม่อาจจินตนาการได้เมื่อสิบปีก่อน ในขณะเดียวกัน เมื่อความคาดหวังของผู้ใช้เพิ่มขึ้นและความต้องการทางธุรกิจมีความซับซ้อนมากขึ้น ความซับซ้อนที่แท้จริงที่การพัฒนาแบบฟูลสแตกจำเป็นต้องจัดการกับการแพร่หลาย
ชุมชนเริ่มตระหนักมากขึ้นว่าสิ่งที่ซับซ้อนได้พัฒนาไปอย่างไร และเริ่มลดความซับซ้อนอย่างเป็นระบบ แทนที่จะเคลื่อนปัญหาไปมา นั่นคือเหตุผลที่เรากำลังสร้าง "ZenStack" เพื่อปรับปรุงการสร้างส่วนแบ็กเอนด์ของเว็บแอป เพื่อให้นักพัฒนาสามารถมุ่งเน้นไปที่สิ่งที่สำคัญได้ดีขึ้น เช่น ประสบการณ์ผู้ใช้และมูลค่าทางธุรกิจ
ไม่ว่าจะชอบหรือไม่ วิวัฒนาการของสถาปัตยกรรมก็จะก้าวไปอย่างรวดเร็วยิ่งขึ้น แม้ว่าการเปลี่ยนแปลงทั้งหมดจะมาพร้อมกับความรู้สึกไม่สบายอย่างหลีกเลี่ยงไม่ได้ แต่การเรียนรู้และการทำงานในขอบเขตที่มีชีวิตชีวาเช่นนี้ถือเป็นโชคดีอย่างยิ่ง
Want to Connect? I'm the creator of ZenStack. Our goal is to let you save time writing boilerplate code and focus on building what matters - the user experience.
