พอจะทำระบบใหม่ที่หน้าเว็บเขียนด้วย React คำถามแรกที่ต้องตอบคือ หน้าเว็บกับหลังบ้านจะอยู่ในแอปเดียวกัน หรือแยกเป็นสองแอปที่คุยกันผ่าน API คำตอบนี้กำหนดว่าต้องมีกี่ทีม deploy กี่ครั้ง ใช้เซิร์ฟเวอร์แบบไหน และระบบจะต่อยอดไปทางไหนได้ง่าย เปลี่ยนใจทีหลังก็ทำได้ แต่ต้องรื้อกันพอสมควร
สามทางที่ใช้ React กับระบบหลังบ้าน
Inertia รวมทุกอย่างไว้ใน Laravel การแยกสองแอปให้ Next.js คุยกับ Laravel ผ่าน API ส่วน Next.js ตัวเดียวต้องหาของหลังบ้านมาเติมเอง
- แอปเดียว Laravel ดูแลทั้ง route ข้อมูล และสิทธิ์ แล้วส่งข้อมูลให้หน้า React ผ่าน Inertia โดยไม่ต้องเขียน API
- แยกสองแอป Next.js ดูแลหน้าเว็บ ส่วน Laravel ส่ง JSON ให้อย่างเดียว ตั้งค่าทั้งสองฝั่งตามที่เล่าไว้ในวิธีใช้ Laravel เป็น API ให้หน้าเว็บ Next.js
- Next.js ตัวเดียว ใช้ Server Actions หรือ Route Handlers ของ Next.js แทนหลังบ้าน แล้วต่อฐานข้อมูลด้วย ORM ฝั่ง JavaScript อย่าง Prisma หรือ Drizzle
Inertia เหมาะกับระบบที่ทีมเดียวทำทั้งหมด
Inertia เป็นตัวเชื่อม controller ของ Laravel เข้ากับหน้า React โดยตรง controller ส่งข้อมูลเข้าหน้าเหมือนเวลาส่งเข้า Blade ที่เราคุ้นมือ
ได้อะไร
- มี repo เดียว deploy ครั้งเดียว ไม่ต้องเขียน API ไม่ต้องคิดเรื่อง token หรือ CORS
- ล็อกอินใช้ session กับ CSRF ที่ Laravel มีให้อยู่แล้ว validation error ก็ส่งกลับเข้าฟอร์มได้เลย
- Wayfinder ทำให้ route ใน React เป็นฟังก์ชันที่มี type เปลี่ยนชื่อ route แล้วรู้ตั้งแต่ตอน build
- queue, งานตั้งเวลา, การแจ้งเตือน และหน้าแอดมินด้วย Filament อยู่ในแอปเดียวกัน
- เริ่มได้เร็วจาก starter kit ของ Laravel ที่มี React กับ Inertia ตั้งไว้ให้แล้ว
ต้องแลกกับอะไร
- หน้าเว็บผูกกับ controller ของ Laravel ถ้าวันหนึ่งมีแอปมือถือหรือระบบภายนอกมาเรียก ต้องทำ API แยกอีกชุด
- ใช้ความสามารถเฉพาะของ Next.js ไม่ได้ เช่น ISR, React Server Components หรือ
next/image - คนทำหน้าเว็บต้องเข้าใจ Laravel ด้วย จะแยกทีม frontend ออกไปทำงานและ deploy เองได้ยาก
เว็บนี้เองก็ใช้ Inertia กับ React ทั้งหน้าเว็บสาธารณะและหลังบ้านที่ใช้เขียนโพสต์ หน้าที่ต้องให้ Google อ่านเปิด SSR ไว้ ส่วน SSR ของ Inertia ต้องมี Node รันอยู่บนเซิร์ฟเวอร์ แต่ไม่เปิดก็ได้ถ้าเป็นระบบภายในที่ไม่ต้องติด Google
Laravel API + Next.js เหมาะเมื่อหน้าเว็บมีทีมของตัวเอง
ทางนี้ Laravel ส่ง JSON อย่างเดียว ส่วนหน้าเว็บเป็นอีกแอปที่เขียนด้วย Next.js
ได้อะไร
- แยกทีมและรอบ deploy ได้จริง ทีม frontend ทำงานใน repo ของตัวเองโดยไม่ต้องรู้จัก Laravel
- API ชุดเดียวใช้ได้ทั้งหน้าเว็บ แอปมือถือ และระบบภายนอกที่มาเชื่อม
- ใช้ความสามารถของ Next.js ได้เต็มที่ เหมาะกับหน้าเว็บสาธารณะที่ต้องติด Google
- ฝั่ง Laravel ยังได้ queue, งานตั้งเวลา, Filament, Reverb และ Eloquent ครบเหมือนเดิม
ต้องแลกกับอะไร
- ต้องดูแลสอง codebase สอง pipeline และ build หน้าเว็บแยกตาม environment
- หน้าตาของ JSON และรูปแบบ error กลายเป็นสัญญาที่สองทีมต้องตกลงกัน และไม่มี type ใช้ร่วมกัน ถ้าไม่ทำเอกสาร API อย่าง OpenAPI เพิ่ม
- ล็อกอินซับซ้อนขึ้น ทั้ง token, CORS และ cookie ข้ามโดเมน
- ต้องมีเซิร์ฟเวอร์ Node สำหรับ Next.js อีกตัว และหน้าที่ render บน server ต้องเรียก API อีกทอดหนึ่ง
อย่างระบบสั่งซื้อของตัวแทนจำหน่ายที่เราทำหลังบ้านกับ API ให้ หน้าเว็บที่ตัวแทนใช้สั่งของเป็นแอป Next.js ที่ทำร่วมกับทีมพาร์ทเนอร์ ส่วนแอดมินใช้หลังบ้าน Filament ในแอป Laravel ตัวเดียวกับ API แบ่งแบบนี้แต่ละทีมทำงานในส่วนของตัวเองได้ แต่ทุกครั้งที่ API เปลี่ยน สองทีมก็ต้องคุยกันก่อน
Next.js ตัวเดียว หรือหลังบ้านภาษาอื่น
ถ้าไม่ใช้ Laravel ก็ยังมีอีกหลายทาง แต่ละทางเหมาะกับทีมคนละแบบ
| ทาง | ได้อะไร | ต้องแลกกับอะไร |
|---|---|---|
| Next.js ตัวเดียว | TypeScript ทั้งระบบ ใช้ type ร่วมกันได้ deploy ครั้งเดียว | queue งานตั้งเวลา อีเมล migration และหน้าแอดมิน ต้องหามาประกอบเอง |
| NestJS หรือ Express | ภาษาเดียวกับหน้าเว็บ NestJS มีโครงสร้างชัด มี controller และ dependency injection | ยังเป็นสองแอปเหมือนทางที่สอง และของสำเร็จรูปน้อยกว่า |
| Django, .NET หรือ Go | เหมาะเมื่อทีมถนัดภาษานั้นอยู่แล้ว Django มีหน้าแอดมินในตัว | ต้นทุนการแยกสองแอปเท่ากับทางที่สอง |
| Supabase หรือ Firebase | เริ่มเร็ว ได้ทั้งล็อกอิน ฐานข้อมูล และ realtime | กฎทางธุรกิจไปกระจายอยู่ใน rule และ function ย่อย ๆ และย้ายออกไปทีหลังได้ยาก |
แถวสุดท้ายเริ่มง่าย แต่ระบบที่มีกฎทางธุรกิจเยอะจะเริ่มติดขัด อย่างระบบสั่งซื้อที่เล่าไว้ข้างบน แชตใช้ Firestore ส่งข้อความแบบ realtime ข้อความจึงต้องเขียนลงทั้งฐานข้อมูลของ Laravel และ Firestore คู่กันไป ตอนนี้กำลังย้ายส่วน realtime มาใช้ Reverb ใน Laravel ทีละกลุ่มผู้ใช้ ให้ข้อมูลกลับมาอยู่ที่เดียว
ระบบหลังร้านมีงานเบื้องหลังมากกว่าที่เห็นบนหน้าจอ
ตอนเลือกเรามักดูแต่หน้าจอ แต่ระบบหลังร้านส่วนใหญ่มีงานที่ไม่มีหน้าจออยู่อีกมาก เช่น ดึงราคาจาก ERP ทุกเช้า ส่งอีเมลใบเสนอราคา สร้าง PDF ส่งออก Excel ลองส่งข้อมูลให้ระบบภายนอกใหม่เมื่อรอบแรกล้มเหลว หรือหน้าแอดมินให้พนักงานแก้ข้อมูล
Laravel มีของพวกนี้ครบในตัว ทั้ง queue, scheduler, mail, notification และ Filament ไม่ว่าเราจะเลือก Inertia หรือแยก Next.js ก็ยังได้ของชุดนี้ ต่างกันแค่หน้าเว็บอยู่ตรงไหน ทางที่เสียของชุดนี้ไปคือ Next.js ตัวเดียว ต้องหา queue หา cron และทำหน้าแอดมินเอง และงานที่รันนาน ๆ ก็ไม่เหมาะกับ serverless ที่จำกัดเวลาทำงานของแต่ละ request
เรื่องเซิร์ฟเวอร์และค่าใช้จ่าย
- Laravel + Inertia รันได้ทุกที่ที่มี PHP ตั้งแต่ VPS ตัวเล็กไปจนถึง shared hosting ที่รองรับ Laravel ถ้าเปิด SSR ค่อยต้องมี Node เพิ่ม
- Laravel API + Next.js ต้องมีที่รัน PHP สำหรับ Laravel และที่รัน Node สำหรับ Next.js จะวางเครื่องเดียวกันหรือแยกเครื่องก็ได้ แต่เป็นสองบริการที่ต้องดูแล
- Next.js ตัวเดียว รันบน VPS ที่มี Node หรือใช้บริการที่ทำมาเพื่อ Next.js อย่าง Vercel ก่อนเลือกให้ดูเงื่อนไขของแพ็กเกจฟรีด้วย อย่างแพ็กเกจ Hobby ของ Vercel ใช้ได้เฉพาะงานส่วนตัวที่ไม่ใช่เชิงพาณิชย์
ถ้าตอนนี้ใช้ shared hosting ที่มี cPanel อยู่ ให้เช็กก่อนว่าเปิดใช้ Node ได้ไหม และเปิดค้างไว้ได้หรือเปล่า
คำถามที่ช่วยเลือก
- มีทีม frontend แยกไหม ถ้าไม่มี และทีมเดียวกันทำทั้งระบบ เลือก Inertia
- มีแอปมือถือหรือระบบอื่นต้องใช้ข้อมูลชุดเดียวกันไหม ถ้ามีตั้งแต่วันแรก การแยก Laravel API กับ Next.js จะไม่ต้องทำ API ซ้ำสองรอบ
- หน้าเว็บส่วนใหญ่เป็นหน้าสาธารณะที่ต้องติด Google หรือเป็นหน้าจอทำงานหลังล็อกอิน ถ้าเป็นหน้าทำงาน Inertia ก็พอ ถ้าเป็นหน้าสาธารณะจำนวนมาก Next.js ช่วยได้มากกว่า
- ระบบมีงานเบื้องหลังเยอะแค่ไหน ถ้าต้องเชื่อม ERP ส่งเอกสาร หรือมีงานตามรอบเยอะ ให้มี Laravel อยู่ข้างหลังไว้ก่อน
- ทีมถนัดภาษาอะไร ถ้าทีมเขียน TypeScript อย่างเดียวและระบบไม่มีงานเบื้องหลังมาก Next.js ตัวเดียวก็พอ
ถ้ายังไม่แน่ใจ เริ่มจาก Inertia แล้วค่อยทำ API เพิ่มเมื่อมีระบบอื่นต้องใช้ ง่ายกว่าเริ่มจากสองแอปแล้วต้องดูแลของที่ยังไม่ได้ใช้
