Aesthetic study notes about Nuxt.js, SSR, and SSG on an iPad screen

1. 🎯 ตอนที่ 39: ทลายขีดจำกัดของเว็บแอปพลิเคชันด้วยพลังแห่ง Server-Side Rendering

2. 📖 เปิดฉาก (The Hook)

น้องๆ เคยเจอฝันร้ายเรื่องนี้ไหมครับ? เราใช้เวลาเป็นเดือนเขียนแอปพลิเคชัน Vue.js อย่างสุดฝีมือ โค้ดคลีน UI สวยงาม หน้าเว็บเปลี่ยนลื่นไหลปานสายน้ำ แต่พอเราเอาลิงก์เว็บไปแชร์ลงใน Facebook หรือ LINE ปรากฏว่า… ไม่มีรูปภาพพรีวิว ไม่มีหัวข้อ ไม่มีคำอธิบายอะไรโผล่ขึ้นมาเลย! ซ้ำร้ายกว่านั้น ผ่านไปเป็นเดือน ค้นหาชื่อเว็บตัวเองใน Google ก็ยังหาไม่เจอ!

สาเหตุที่เป็นแบบนี้ เพราะ Vue.js พื้นฐานที่เราเขียนกันมาตั้งแต่ต้น เป็นสถาปัตยกรรมแบบ Client-Side Rendering (CSR) หรือ Single-Page Application (SPA) ครับ เวลาที่หุ่นยนต์เก็บข้อมูล (Crawlers) ของ Google หรือ Facebook วิ่งเข้ามาดูเว็บเรา สิ่งที่พวกมันเห็นมีแค่ไฟล์ index.html โล่งๆ ที่มีแท็ก <div id="app"></div> หน้าตาว่างเปล่า เพราะหุ่นยนต์บางตัวไม่มีความอดทนพอที่จะรอให้ JavaScript ของเราดาวน์โหลดและวาดหน้าจอจนเสร็จ

เพื่อแก้ปัญหานี้ระดับ Enterprise เราจึงต้องย้ายการวาดหน้าจอ (Rendering) จากฝั่งเครื่องผู้ใช้งาน (Client) กลับไปทำที่ฝั่งเซิร์ฟเวอร์ (Server) แทน และพระเอกขี่ม้าขาวที่จะมาช่วยเราจัดการเรื่องที่แสนจะปวดหัวนี้ให้กลายเป็นเรื่องง่ายนิดเดียว ก็คือเฟรมเวิร์กขั้นเทพที่ชื่อว่า Nuxt.js ครับ! จิบกาแฟให้พร้อม แล้วมาอัปเกรดความรู้สถาปัตยกรรมระดับสูงกันครับ

3. 🧠 แก่นวิชา (Core Concepts)

ก่อนจะไปเขียนโค้ด พี่ขอเปรียบเทียบสถาปัตยกรรมการเรนเดอร์ (Rendering) ทั้ง 3 แบบให้เห็นภาพเหมือนการไปทานอาหารที่ร้านครับ:

🍽️ 1. Client-Side Rendering (CSR) - ชุดทำอาหารกินเอง

ในโหมด CSR (Vue SPA ปกติ) เมื่อผู้ใช้ขอเข้าเว็บ เซิร์ฟเวอร์จะส่งแค่ “เตาแก๊สและวัตถุดิบ (JavaScript)” มาให้ที่โต๊ะ (Browser) จากนั้นเบราว์เซอร์ต้องใช้เวลาในการประกอบอาหาร (Execute JS) จนกว่าจะเสร็จถึงจะกินได้ (มองเห็นเนื้อหา)

  • ข้อดี: หลังจากโหลดเสร็จ การเปลี่ยนหน้าจะลื่นไหลมาก ไม่ต้องโหลดหน้าใหม่
  • ข้อเสีย: โหลดครั้งแรกช้า (Slow time-to-content) และไม่เป็นมิตรกับ SEO เพราะหุ่นยนต์กินของดิบไม่เป็น!

👨‍🍳 2. Server-Side Rendering (SSR) - อาหารทำเสร็จจากครัว

ในโหมด SSR เซิร์ฟเวอร์จะทำหน้าที่เป็นพ่อครัว ปรุงอาหาร (Execute Vue Code) ให้เสร็จสมบูรณ์ตั้งแต่หลังร้าน แล้วเสิร์ฟเป็น “อาหารจานพร้อมทาน (HTML String)” มาให้ผู้ใช้เลย จากนั้นเบราว์เซอร์จะทำการ “ชุบชีวิต (Hydration)” ใส่ความสามารถในการคลิกและการโต้ตอบ (Interactive) เข้าไปในภายหลัง

  • ข้อดี: ผู้ใช้และหุ่นยนต์ (Crawlers) เห็นเนื้อหาทันที ดีเยี่ยมสำหรับ SEO และคนเน็ตช้า
  • ข้อเสีย: เซิร์ฟเวอร์ต้องทำงานหนักขึ้น (ใช้ CPU เยอะขึ้น) เพราะต้องวาดหน้าใหม่ทุกครั้งที่ถูกร้องขอ

🍱 3. Static Site Generation (SSG) - ข้าวกล่องทำสำเร็จรูป

สำหรับ SSG เราจะปรุงอาหารทุกเมนูเตรียมใส่กล่องไว้ตั้งแต่ตอน “Build (ก่อนนำขึ้น Server)” เซิร์ฟเวอร์มีหน้าที่แค่หยิบกล่อง (ไฟล์ HTML นิ่งๆ) ยื่นให้ลูกค้า ทำให้เสิร์ฟได้ไวปานสายฟ้าแลบโดยไม่ต้องพึ่งพาระบบหลังบ้าน

  • ข้อดี: โหลดไวที่สุด ประหยัดค่าเซิร์ฟเวอร์ (วางบน CDN ได้เลย) ปลอดภัยสูง
  • ข้อเสีย: ไม่เหมาะกับเว็บที่มีข้อมูลเปลี่ยนแปลงตลอดเวลา (Real-time) เพราะต้องรันคำสั่ง Build ใหม่ทุกครั้งที่ข้อมูลเปลี่ยน

🚀 Nuxt.js: ผู้รวบรวมทุกศาสตร์ไว้ในหนึ่งเดียว

การจะเซ็ตอัป Vue.js ให้ทำ SSR หรือ SSG ด้วยตัวเองจากศูนย์นั้นยากและซับซ้อนมาก (ต้องยุ่งกับ Webpack/Vite และ Node.js) แต่ Nuxt.js เป็นเฟรมเวิร์กที่ครอบ Vue.js ไว้อีกชั้น มันจัดการเรื่องน่าปวดหัวเหล่านี้ให้หมด เราสามารถเลือกได้เลยว่าจะให้เว็บเรนเดอร์แบบ SSR หรือ SSG ได้ง่ายๆ!

Diagram showing the difference between Client-Side Rendering (CSR) and Server-Side Rendering (SSR)

4. 💻 ร่ายมนต์โค้ด (Show me the Code)

เรามาดูความแตกต่างระหว่างการเขียน Vue ธรรมดา กับการเขียน Nuxt 3 กันครับ สมมติว่าเราต้องการสร้างหน้าแสดงรายละเอียดสินค้าที่ดึงข้อมูลจาก API

✨ มนต์บทใหม่ใน Nuxt 3 (pages/products/[id].vue) ใน Nuxt.js เราไม่ต้องติดตั้ง Vue Router เองครับ แค่เราสร้างไฟล์ในโฟลเดอร์ pages/ มันจะสร้าง Route ให้เราอัตโนมัติเลย (File-based routing) และนี่คือการใช้ Composition API ร่วมกับพลังของ SSR:

<template>
  <div class="product-page">
    <!-- Nuxt จัดการเรื่อง Loading ให้เราเสร็จสรรพ -->
    <div v-if="pending" class="loading">กำลังเตรียมอาหาร... ⏳</div>
    
    <!-- หาก API ล่ม ก็มี state รองรับ -->
    <div v-else-if="error" class="error">ขออภัย! {{ error }} ❌</div>
    
    <!-- เนื้อหานี้จะถูก Render มาจาก Server พร้อมส่งให้ SEO Crawler อ่านทันที! -->
    <div v-else class="product-details">
      <h1>{{ product.name }}</h1>
      <p>{{ product.description }}</p>
      <button @click="addToCart">หยิบใส่ตะกร้า 🛒</button>
    </div>
  </div>
</template>

<script setup>
// ใน Nuxt ไม่ต้อง import useRoute หรือ ref เลยครับ (Auto-imports)
const route = useRoute()

// 🌟 พระเอกของเรา useFetch()
// ตอนเป็น SSR: มันจะดึงข้อมูลจาก API ฝั่ง Server แล้วฝังมากับ HTML เลย
// ตอนเป็น CSR: มันจะดึงข้อมูลผ่านฝั่ง Client ตามปกติ
const { data: product, pending, error } = await useFetch(`/api/products/${route.params.id}`)

function addToCart() {
  // โลจิกนี้ทำงานฝั่ง Client แน่นอนเวลากดปุ่ม
  console.log(`เพิ่ม ${product.value.name} ลงตะกร้าแล้ว!`)
}
</script>

เห็นไหมครับ! โค้ดสั้น กระชับ แตกต่างจาก CSR ธรรมดาที่เราต้องมานั่งสร้าง ref(null), เขียน try...catch, และใช้ onMounted ในการดึงข้อมูล ซึ่ง onMounted จะไม่ถูกเรียกบน Server นะครับ การใช้ useFetch ใน Nuxt จึงเป็นทางออกที่สวยงามที่สุด

5. 🛡️ เคล็ดลับจากคัมภีร์ลับ (Under the Hood / Pro-Tips)

🚨 1. ระวังหายนะ “Hydration Mismatch” ปัญหาที่พบบ่อยที่สุดของนักพัฒนาที่เพิ่งย้ายมาทำ SSR คือ Hydration Mismatch ครับ มันคืออาการที่ HTML ที่ Server วาดมาให้ ดัน “ไม่ตรง” กับสิ่งที่ Vue ฝั่ง Client คาดหวัง สาเหตุคลาสสิกคือ การเขียน HTML ซ้อนกันผิดกฎ เช่น เอา <div> ไปใส่ไว้ใน <p> เซิร์ฟเวอร์ส่งมาแบบนึง แต่เบราว์เซอร์แอบแก้ไขโค้ด HTML ให้ถูกต้อง พอ Vue ฝั่ง Client ตื่นขึ้นมาตรวจเช็ก ก็จะโวยวาย (Error ใน Console) ว่าต้นฉบับกับของจริงไม่เหมือนกัน! ดังนั้นจงเขียน HTML ให้ถูกต้องตามมาตรฐานเสมอครับ

⏳ 2. Lifecycle Hooks ไหนใช้ได้ บน Server? จำไว้ให้ขึ้นใจเลยครับว่า บน Server จะไม่มีการปฏิสัมพันธ์กับผู้ใช้และไม่มี DOM! ดังนั้น Hooks ยอดฮิตอย่าง onMounted หรือ onUpdated จะ ทำงานแค่ฝั่ง Client เท่านั้น หากน้องๆ ต้องการดึงข้อมูลหรือตั้งค่าอะไรที่อยากให้เสร็จตั้งแต่บน Server ต้องเขียนลอจิกไว้นอก Hooks (ใน Script Setup ตรงๆ) หรือใช้ฟังก์ชันเฉพาะของ Nuxt อย่าง useFetch / useAsyncData ครับ

🔀 3. เลือกอาวุธให้ถูกงาน: SSR หรือ SSG?

  • ทำบล็อกส่วนตัว (Blog), เว็บเอกสาร (Docs), หรือเว็บที่เนื้อหาไม่ค่อยเปลี่ยน? -> เลือก SSG (โหลดไวดั่งแสง!)
  • ทำเว็บข่าว, ระบบ E-Commerce, หรือเว็บที่ข้อมูลเปลี่ยนทุกนาทีแต่อยากได้ SEO? -> เลือก SSR
  • ความเจ๋งของ Nuxt 3 คือ เราสามารถทำ “Hybrid Rendering” ได้ครับ! คือตั้งค่าให้หน้า Home เป็น SSR ส่วนหน้าเงื่อนไขการใช้งาน (Terms) เป็น SSG ปะปนกันในโปรเจกต์เดียวได้เลย!

6. 🏁 บทสรุป (To be continued…)

การขยับจาก Client-Side Rendering (CSR) มาสู่สถาปัตยกรรมระดับสูงอย่าง Server-Side Rendering (SSR) และ Static Site Generation (SSG) ถือเป็นก้าวกระโดดที่สำคัญมากของ Frontend Developer ครับ ไม่ใช่แค่ช่วยแก้ปัญหาเรื่อง SEO เพื่อให้ลูกค้าค้นหาธุรกิจของเราเจอเท่านั้น แต่มันยังเป็นการยกระดับประสิทธิภาพ (Performance) และมอบประสบการณ์การใช้งานที่รวดเร็วทันใจให้กับผู้ใช้อีกด้วย

Nuxt.js เกิดมาเพื่อเป็นสะพานเชื่อมให้เราก้าวข้ามความซับซ้อนนี้ไปได้อย่างสง่างาม เมื่อเราสร้างแอปพลิเคชันระดับ Enterprise เสร็จสมบูรณ์แล้ว ก็ถึงเวลาปล่อยของสู่สายตาชาวโลก! ในบทความตอนหน้า เราจะมาปิดจบซีรีส์นี้ด้วยศาสตร์แห่ง Deployment การนำแอปพลิเคชันขึ้นสู่ระบบ Cloud อย่างแท้จริง เตรียมตัวออกเดินทางกันได้เลยครับ!

ต้องการที่ปรึกษาและพัฒนาระบบ Web Application หรือ Frontend Architecture ให้กับธุรกิจของคุณ? ทีมงาน WP Solution พร้อมให้บริการออกแบบและพัฒนาซอฟต์แวร์แบบครบวงจร ดูรายละเอียดบริการของเราได้ที่: www.wpsolution2017.com หรือพูดคุยปรึกษาเบื้องต้นได้ที่ Line: wisit.p