เทคโนโลยีเบื้องหลัง TechEnvolved

ทุกการเลือกเทคโนโลยีคือการแลกเปลี่ยน การเลือกเครื่องมือเพราะมันเป็นที่นิยม หรือเพราะบทเรียนออนไลน์ใช้มัน คือวิธีที่โค้ดเบสสะสมความซับซ้อนที่ไม่จำเป็น สแต็กของเราเล็กโดยตั้งใจ: แต่ละชิ้นได้ที่ยืนของมันจากการแก้ปัญหาเฉพาะได้ดี และไม่มีอะไรมากกว่านั้น

// Core_Engine: Next.js 16

แพลตฟอร์มรันบน Next.js 16 เราเลือกมันเพราะ Server Components และ App Router ไม่ใช่เพราะเป็นเฟรมเวิร์กที่ทุกคนแนะนำ

เหตุผลตรงไปตรงมา: สิ่งที่เว็บไซต์คอนเทนต์ส่งมอบส่วนใหญ่เป็น static ทั้งข้อความบทความ การนำทาง และ metadata การส่ง JavaScript ไปให้เบราว์เซอร์ render เนื้อหาเหล่านั้นฝั่ง client คือการเสียเวลาและ bandwidth เปล่าๆ ด้วย Server Components งานหนักอยู่บนเซิร์ฟเวอร์ เบราว์เซอร์ได้รับ HTML ที่เสร็จแล้ว JavaScript ถูกส่งเฉพาะส่วนของหน้าที่ต้องใช้จริงๆ

ผลลัพธ์ในทางปฏิบัติคือการโหลดครั้งแรกที่เร็วและคะแนน Core Web Vitals ที่ดี โดยไม่ต้องปรับแต่งด้วยมือ crawler ของเสิร์ชเอนจินเห็นเนื้อหาเต็มทันที ซึ่งทำให้ SEO ง่ายขึ้น สถาปัตยกรรมนี้ยังทำให้โค้ดเบสเข้าใจง่ายขึ้น: การดึงข้อมูลเกิดใกล้กับจุดที่ใช้ข้อมูล โดยไม่มี prop drilling หรือ global state สำหรับสิ่งที่ควรเป็นแค่ query ฝั่งเซิร์ฟเวอร์

เราไม่ใช้ Pages Router เราไม่ใช้ getStaticProps หรือ getServerSideProps App Router กับ async Server Components ครอบคลุมทุกอย่างที่เราต้องการได้สะอาดกว่า

// Visual_Framework: Tailwind CSS

การออกแบบของเราตามกฎเดียว: อินเทอร์เฟซต้องไม่แข่งกับเนื้อหา พื้นหลังมืด ตัวอักษรคอนทราสต์สูง การตกแต่งน้อยที่สุด เป้าหมายคือการอ่านบทความที่นี่ ให้ความรู้สึกเหมือนอ่านใน text editor ไม่ใช่เหมือนเลื่อนดูเว็บการตลาด

Tailwind CSS เหมาะกับสิ่งนี้เพราะมันสร้างเฉพาะ CSS ที่ถูกใช้จริง ไม่มี stylesheet ส่วนกลางให้ตรวจสอบ ไม่มีปัญหา specificity ให้แก้ ไม่มีกฎที่ตายแล้วสะสมตามเวลา การเพิ่มคอมโพเนนต์ใหม่ไม่ต้องเปิดไฟล์ CSS แยก การลบก็ไม่ทิ้งสไตล์กำพร้าไว้

ภาษาการออกแบบที่เราสร้างบนมันมีทางเลือกที่คงเส้นคงวาไม่กี่อย่าง: เส้นขอบบางและโปร่งใสต่ำ ใช้เพื่อโครงสร้างไม่ใช่การตกแต่ง สีพื้นหลังเกือบดำแทนที่จะดำสนิท ซึ่งลดความล้าของตา ในการอ่านยาวๆ สีเน้นคือ teal ใช้อย่างประหยัดกับ active state และ callout ตัวอักษรใช้ Geist ซึ่งอ่านชัดทั้งขนาดเล็กและใหญ่

เอฟเฟกต์ glassmorphism ที่ใช้ใน header และการ์ดบางใบ (เบลอพื้นหลังบวกเส้นขอบจางๆ) เป็นความตั้งใจ มันสื่อความลึกโดยไม่เพิ่ม noise ทางสายตา เราใช้เฉพาะจุดที่ UI ต้องลอยเหนือเนื้อหา ไม่ใช่เป็นลวดลายตกแต่งทั่วไป

// Deployment_Node: Vercel Edge Network

เว็บไซต์ deploy ขึ้น Vercel เหตุผลไม่ใช่ความสะดวก แม้มันจะสะดวกก็ตาม เหตุผลคือโครงสร้างพื้นฐานแบบ edge

เซิร์ฟเวอร์ในดาต้าเซ็นเตอร์เดียวตอบสนองช้าต่อผู้ใช้อีกฟากของโลก edge network ของ Vercel รันโค้ดแอปพลิเคชันในดาต้าเซ็นเตอร์ที่กระจายทั่วโลก ผู้ใช้ในกรุงเทพฯ ได้คำตอบจาก node ใกล้กรุงเทพฯ ผู้ใช้ในลอนดอนได้จาก node ใกล้ลอนดอน ระยะทางกายภาพระหว่างผู้ใช้กับเซิร์ฟเวอร์ ส่งผลตรงต่อ latency และสถาปัตยกรรมนี้ทำให้มันต่ำที่สุด

สำหรับเว็บที่มีผู้อ่านหลายภูมิภาค เรื่องนี้สำคัญ ผู้ชมของเราอยู่ทั้งเอเชียตะวันออกเฉียงใต้ รัสเซีย ญี่ปุ่น และยุโรป การ deploy ภูมิภาคเดียวหมายถึงการโหลดที่ช้าลงชัดเจนสำหรับคนส่วนใหญ่

การ deploy เป็นอัตโนมัติ: push ขึ้น branch หลักคือ build และ deploy ทันที ทุก pull request ได้ preview ของตัวเอง ไม่มีสคริปต์ deploy ให้รันเอง ไม่มีเซิร์ฟเวอร์ให้ SSH เข้าไป

// Data_Layer: Supabase

เนื้อหาแบบไดนามิก (โพสต์ที่เผยแพร่ผ่านหน้าแอดมิน คอมเมนต์ ข้อมูลผู้ใช้) อยู่ใน Supabase ซึ่งคือฐานข้อมูล Postgres พร้อม REST API และ real-time subscriptions ที่สร้างครอบไว้

เราใช้มันเพราะต้องการ Postgres แบบ hosted โดยไม่ต้องดูแลโครงสร้างพื้นฐานเอง และเพราะ client library ฝั่ง JavaScript ใช้งานตรงไปตรงมา ระบบ row-level security จัดการสิทธิ์ที่ระดับฐานข้อมูล ซึ่งทำให้โค้ดแอปพลิเคชันสะอาดขึ้น เราไม่ต้องเขียน middleware ตรวจสอบความเป็นเจ้าของ record เอง

เนื้อหา static (บทความบนเว็บนี้ หน้าที่มีโครงสร้าง) เก็บในโค้ดเบสไม่ใช่ฐานข้อมูล เนื้อหานั้น deploy ไปพร้อมเว็บ โหลดทันทีจากเซิร์ฟเวอร์ และไม่ต้อง query ฐานข้อมูล ฐานข้อมูลสงวนไว้สำหรับเนื้อหาที่เปลี่ยนแปลงตอน runtime จริงๆ

สิ่งที่เราตัดสินใจไม่ใช้

เราประเมินและปฏิเสธเครื่องมือหลายตัวช่วงวางแผน ที่น่าพูดถึงมีไม่กี่ตัว:

CMS อย่าง Contentful หรือ Sanity เราดู headless CMS แล้วพบว่า abstraction นั้นไม่จำเป็นสำหรับโครงสร้างเนื้อหาของเรา บทความเก็บเป็นโค้ด ซึ่งให้การควบคุมการ render และโครงสร้างเต็มที่โดยไม่มี dependency ภายนอก

ไลบรารี CSS-in-JS เราลอง styled-components ในเวอร์ชันก่อนหน้าแล้วพบว่าต้นทุน runtime และความซับซ้อนของ build ที่เพิ่มมาไม่คุ้ม Tailwind ทำงานเร็วกว่าและได้ bundle เล็กกว่า

ไลบรารี state management แยก เราไม่มี Redux ไม่มี Zustand ไม่มี Jotai Server Components จัดการการดึงข้อมูล state ฝั่ง client จัดการด้วย useState และ useContext ในจุดที่มีอยู่จริง ซึ่งมีไม่กี่ที่ global state สำหรับเว็บคอนเทนต์มักเป็นสัญญาณของสถาปัตยกรรมที่ผิด ไม่ใช่ความจำเป็น

เอกสารนี้สะท้อนสแต็ก ณ เดือนมิถุนายน 2026 การเลือกเทคโนโลยีเปลี่ยนตามความต้องการที่พัฒนา เราอัปเดตเมื่อมีอะไรสำคัญเปลี่ยนแปลง