Deploy Next.js บน Cloudflare Workers เหมาะกับโปรเจกต์แบบไหน แล้วแบบไหนควรมองข้าม

เมื่อ Next.js เริ่มถูก deploy ได้บน Cloudflare Workers ผ่าน adapter ที่ชุมชนพัฒนาขึ้นมา ทีมพัฒนาจำนวนหนึ่งเริ่มสนใจย้ายจาก Vercel หรือ Node server ทั่วไปมาใช้ Workers แทน ด้วยเหตุผลเรื่อง edge network ที่กระจายกว้างกว่าและโครงสร้างราคาที่ต่างออกไป

แต่คำถามที่สำคัญกว่า 'ทำได้ไหม' คือ 'ควรทำไหมสำหรับโปรเจกต์นี้' เพราะ Cloudflare Workers รันบน runtime ที่ออกแบบมาให้เบาและเร็ว ไม่ใช่ Node.js เต็มรูปแบบ ทำให้ dependency บางตัวที่พึ่งพา Node API เฉพาะทางใช้ไม่ได้ตรง ๆ หรือต้องหา alternative แทน

บทความนี้จะแยกให้เห็นว่าเงื่อนไขแบบไหนที่ทำให้ Next.js บน Cloudflare Workers เป็นตัวเลือกที่คุ้มค่า และแบบไหนที่ควรอยู่กับ Node runtime แบบเดิมไปก่อน เพื่อไม่ให้ทีมเสียเวลาย้าย stack แล้วเจอปัญหาที่ไม่คุ้มกับที่ได้มา

Cloudflare Workers Runtime ต่างจาก Node ตรงไหนบ้าง

Cloudflare Workers รันบน V8 isolate ซึ่งเป็นสภาพแวดล้อมที่เบากว่า container หรือ virtual machine มาก แต่ก็หมายความว่าไม่มี Node API เต็มรูปแบบให้ใช้ เช่นการเข้าถึง filesystem โดยตรง หรือ native module บางตัวที่ compile เป็น binary เฉพาะแพลตฟอร์ม

API ที่ Workers รองรับใกล้เคียงกับ Web API มาตรฐานมากกว่า เช่น fetch, Request, Response, ReadableStream ซึ่งเป็นชุดเดียวกับที่ browser ใช้ ทำให้โค้ดที่เขียนด้วย Web API มาตั้งแต่ต้นมักย้ายมาได้ง่ายกว่าโค้ดที่พึ่งพา Node-specific module หนัก ๆ

ข้อจำกัดอีกอย่างที่ต้องรู้คือเรื่องขนาดของ bundle และเวลาทำงานต่อ request Workers มีเพดานเวลาทำงานที่สั้นกว่า long-running process ทั่วไป ทำให้งานที่ต้องประมวลผลนานควรแยกไปทำใน background หรือ queue แทนการยัดไว้ใน request เดียวกัน

Adapter ที่ทำให้ Next.js รันบน Workers ได้จริง ทำงานยังไง

การ deploy Next.js บน Cloudflare Workers ไม่ได้ทำแบบ native ตรง ๆ แต่ผ่าน adapter ที่แปลง output ของ Next.js build (ทั้ง Server Component, API Route, Middleware) ให้กลายเป็นรูปแบบที่ Workers runtime รันได้ adapter เหล่านี้ต้อง map ฟีเจอร์ของ Next.js เช่น Incremental Static Regeneration หรือ Image Optimization ให้ทำงานผ่านบริการของ Cloudflare แทนของ Vercel เอง

เพราะ Next.js ถูกออกแบบมาให้ optimize สำหรับ deploy บน Vercel เป็นหลัก ฟีเจอร์บางตัวจึงต้องมีการ config เพิ่มเติมเมื่อย้ายมา Workers เช่นการตั้งค่า cache storage ให้ใช้ KV หรือ R2 ของ Cloudflare แทน built-in cache ของ Vercel ทีมที่ย้ายมาควรอ่าน documentation ของ adapter เวอร์ชันที่ใช้อยู่ให้ละเอียด เพราะความเข้ากันได้เปลี่ยนแปลงตามเวอร์ชันของทั้ง Next.js และ adapter เอง

จุดที่ควรตรวจก่อนตัดสินใจย้ายคือฟีเจอร์ของ Next.js ที่โปรเจกต์ใช้อยู่จริง ไม่ใช่ทุกฟีเจอร์ของ Next.js เวอร์ชันล่าสุดจะถูก adapter รองรับพร้อมกันทันที ควรทำ proof of concept เล็ก ๆ ก่อนย้ายทั้งโปรเจกต์ เพื่อดูว่าฟีเจอร์หลักที่ใช้งานจริงทำงานถูกต้องบน Workers หรือไม่

โปรเจกต์แบบไหนที่ใช้ Cloudflare Workers แล้วคุ้มค่าจริง

จากลักษณะของ Workers runtime มีกลุ่มโปรเจกต์ที่ได้ประโยชน์ชัดเจนจากการย้ายมาใช้

• แอปที่ผู้ใช้กระจายอยู่หลายภูมิภาคทั่วโลก — edge network ของ Cloudflare กระจายกว้างมาก การ render หน้าใกล้ผู้ใช้มากขึ้นช่วยลด latency ได้ชัดสำหรับ workload ที่เน้นความเร็วในการตอบสนอง
• โปรเจกต์ที่ dependency เบาและใช้ Web API เป็นหลัก — เช่นแอปที่ไม่พึ่งพา native module หรือ library เฉพาะทางของ Node จะย้ายมาได้ราบรื่นกว่า
• ทีมที่ใช้บริการอื่นของ Cloudflare อยู่แล้ว — เช่น D1, R2 หรือ Queues การรวม stack ไว้ที่แพลตฟอร์มเดียวช่วยลดความซับซ้อนของการจัดการหลาย provider พร้อมกัน อ่านเพิ่มเติมเรื่องการใช้ D1 ร่วมกับ Workers ได้ในบทความ Cloudflare D1 คืออะไร
• โปรเจกต์ที่ค่าใช้จ่ายต่อ request เป็นปัจจัยสำคัญ — โครงสร้างราคาของ Workers มักต่างจาก Vercel โดยเฉพาะเมื่อ traffic เยอะ ควรเทียบราคาจริงตามปริมาณ request ที่คาดการณ์ไว้ก่อนตัดสินใจ

ธุรกิจแบบไหนที่ยังไม่ควรลงทุนกับ Workers ตอนนี้

ในทางกลับกัน มีสถานการณ์ที่การย้ายมา Cloudflare Workers อาจไม่คุ้มกับความเสี่ยงและเวลาที่ต้องใช้

ทีมที่มี dependency ผูกกับ Node API เฉพาะทางหนัก ๆ เช่น library ประมวลผลภาพหรือไฟล์ PDF ที่ compile เป็น native binary ควรตรวจให้แน่ใจก่อนว่ามีทางเลือกที่รองรับ Workers runtime หรือไม่ ถ้าไม่มีและไม่มีเวลาเขียนใหม่ การย้ายอาจทำให้โปรเจกต์ค้างกลางทาง

ทีมที่ต้องการฟีเจอร์ Next.js เวอร์ชันล่าสุดทันทีที่ออก ควรระวังว่า adapter สำหรับ Workers อาจตามหลังการรองรับฟีเจอร์ใหม่อยู่บ้าง เพราะต้องรอให้ community หรือทีมพัฒนา adapter อัปเดตให้เข้ากันได้ก่อน การอยู่กับ Vercel ซึ่งเป็นเจ้าของ Next.js เองอาจได้ฟีเจอร์ใหม่เร็วกว่า

โปรเจกต์ที่ทีมยังเล็กและไม่มีเวลาศึกษา runtime ใหม่ ควรชั่งน้ำหนักว่าความเร็วที่ได้จาก edge network คุ้มกับเวลาที่ต้องเสียไปกับการ debug ปัญหาความเข้ากันไม่ได้หรือไม่ ถ้าแอปไม่ได้มีผู้ใช้กระจายทั่วโลกจริง ประโยชน์ด้าน latency อาจไม่ชัดเจนพอจะคุ้มกับความซับซ้อนที่เพิ่มขึ้น

เทียบ Vercel กับ Cloudflare Workers ในมุมการตัดสินใจจริง

เพื่อสรุปปัจจัยที่ควรใช้ตัดสินใจ นี่คือตารางเทียบมุมสำคัญระหว่างสองแพลตฟอร์มสำหรับ deploy Next.js

ตัวอย่างสมมติ: ขั้นตอนประเมินก่อนย้ายโปรเจกต์จริงมา Workers

สำหรับทีมที่กำลังพิจารณาย้าย ลองทำตามลำดับขั้นตอนประเมินนี้ก่อนตัดสินใจย้ายทั้งโปรเจกต์ (ตัวอย่างสมมติของลำดับงานที่ควรทำ ไม่ใช่ script สำเร็จรูป)

1. ลิสต์ dependency ทั้งหมดของโปรเจกต์ แล้วตรวจทีละตัวว่ารองรับ Workers runtime หรือไม่ผ่าน documentation ของแต่ละ library
2. ทำ proof of concept แยกต่างหาก deploy หน้าเว็บง่าย ๆ สักหนึ่งหน้าที่ใช้ฟีเจอร์หลักของโปรเจกต์จริง เช่น Server Component ที่ query database
3. วัด latency จริงจากหลายภูมิภาคเทียบกับที่ deploy บน Vercel เดิม เพื่อดูว่าความต่างชัดเจนพอจะคุ้มกับการย้ายหรือไม่
4. ประเมินค่าใช้จ่ายจริงตามปริมาณ request ที่คาดการณ์ ไม่ใช่ดูแค่ราคาเริ่มต้นของแต่ละแพลตฟอร์ม
5. ถ้าผลออกมาคุ้มค่า วางแผนย้ายทีละส่วน เริ่มจากหน้าที่ไม่ critical ก่อน แล้วค่อยขยายไปหน้าที่สำคัญเมื่อมั่นใจว่าเสถียร

สับสนกับ Supabase Edge Functions ไหม ทั้งสองไม่ใช่ตัวเดียวกัน

หลายคนที่เริ่มศึกษาเรื่อง edge computing มักสับสนระหว่าง Cloudflare Workers กับ Supabase Edge Functions เพราะชื่อคล้ายกันและแนวคิดคล้ายกัน ทั้งคู่เป็น serverless function ที่รันบน edge network แต่เป็นคนละบริการ คนละ provider และมี use case หลักต่างกัน

Cloudflare Workers เหมาะกับการรันทั้งแอปหรือ logic ทั่วไปที่ต้องการ edge network กว้าง ส่วน Supabase Edge Functions ผูกอยู่กับ Supabase project โดยตรง เหมาะกับ logic ที่ต้องอยู่ใกล้ Postgres database ของ Supabase เป็นพิเศษ เช่น Webhook handler ที่ต้องเขียนข้อมูลกลับทันที อ่านเปรียบเทียบละเอียดได้ในบทความ Cloudflare Workers vs Supabase Edge Functions

ทีมที่ใช้ทั้ง Cloudflare Workers สำหรับรันแอป Next.js และ Supabase Edge Functions สำหรับ logic เฉพาะที่ต้องอยู่ใกล้ database สามารถใช้ทั้งสองร่วมกันได้ ไม่จำเป็นต้องเลือกอย่างใดอย่างหนึ่งเพียงอย่างเดียว

ตัวอย่างสมมติ: เทียบ Latency และค่าใช้จ่ายก่อนตัดสินใจย้ายจริง

เพื่อให้เห็นวิธีคิดที่เป็นรูปธรรมมากขึ้น ลองดูตัวอย่างสมมติของทีมที่ทำแอป dashboard ให้ลูกค้าในหลายภูมิภาค (ตัวเลขทั้งหมดเป็นตัวอย่างสมมติเพื่อประกอบการอธิบายวิธีคิด ไม่ใช่ benchmark จริงจากระบบใด)

ทีมนี้มีผู้ใช้กระจายอยู่ในเอเชียตะวันออกเฉียงใต้ ยุโรป และอเมริกาเหนือใกล้เคียงกัน ตอนใช้ Vercel วัด latency เฉลี่ยของ request แรกที่เข้าหน้า dashboard ได้ประมาณ 280 มิลลิวินาทีสำหรับผู้ใช้ที่อยู่ไกลจาก region หลักที่ deploy ไว้ ขณะที่ผู้ใช้ที่อยู่ใกล้ region เดียวกันได้ latency ราว 90 มิลลิวินาที ความต่างนี้ทำให้ผู้ใช้บางกลุ่มรู้สึกว่าแอปโหลดช้ากว่ากลุ่มอื่นอย่างชัดเจน

หลังทำ proof of concept ย้ายหน้า dashboard หลักมารันบน Cloudflare Workers latency ของกลุ่มผู้ใช้ที่เคยไกลจาก region หลักลดลงมาอยู่ที่ราว 120 มิลลิวินาที เพราะ request ถูกตอบจากจุด edge ที่ใกล้กว่า ขณะที่กลุ่มผู้ใช้ที่เดิมได้ latency ต่ำอยู่แล้วแทบไม่เปลี่ยนแปลง เพราะจุดคอขวดของกลุ่มนี้ไม่ได้อยู่ที่ระยะทางเครือข่ายตั้งแต่แรก

ในแง่ค่าใช้จ่าย ทีมเปรียบเทียบปริมาณ request ต่อเดือนที่คาดการณ์ไว้ (สมมติราว 4 ล้าน request) กับโครงสร้างราคาของทั้งสองแพลตฟอร์ม พบว่าความคุ้มค่าด้านราคาขึ้นกับรูปแบบการใช้งานจริง ไม่ใช่ตัวเลขราคาตั้งต้นที่โฆษณาไว้ จึงตัดสินใจย้ายเฉพาะหน้าที่ผู้ใช้กระจายทั่วโลกจริง ส่วนหน้าที่ใช้เฉพาะทีม internal ในประเทศเดียวยังปล่อยไว้บน Vercel ตามเดิม เพราะไม่ได้ประโยชน์ด้าน latency เพิ่มเติมจากการย้าย

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

ทำแบบนี้แล้วพัง เพราะอะไร

มีข้อผิดพลาดที่ทีมย้ายมา Cloudflare Workers ครั้งแรกมักเจอซ้ำ ๆ เพราะความเคยชินจาก Node runtime

• ย้ายทั้งโปรเจกต์ในครั้งเดียวโดยไม่ทำ proof of concept ก่อน — เจอปัญหา dependency ไม่รองรับหลังย้ายไปแล้วครึ่งทาง ทำให้ต้อง rollback ทั้งหมด
• ลืมตั้งค่า cache storage ให้ใช้บริการของ Cloudflare — ทำให้ฟีเจอร์อย่าง Incremental Static Regeneration ทำงานผิดจากที่คาดไว้ตอนอยู่บน Vercel
• ไม่ตรวจ Node API compatibility ของ library หลักก่อนย้าย — เจอ error ตอน build หรือ runtime ที่แก้ไม่ได้เพราะ library นั้นไม่มีเวอร์ชันรองรับ Workers
• คาดหวังฟีเจอร์ Next.js เวอร์ชันล่าสุดทันที — โดยไม่เช็คว่า adapter ที่ใช้รองรับฟีเจอร์นั้นแล้วหรือยัง ทำให้ build ล้มเหลวหรือฟีเจอร์บางตัวใช้ไม่ได้

สรุป

Cloudflare Workers ไม่ใช่ตัวเลือกที่ดีกว่า Vercel เสมอไปสำหรับทุกโปรเจกต์ Next.js แต่เป็นตัวเลือกที่ดีกว่าสำหรับโปรเจกต์ที่มีเงื่อนไขตรงกับจุดแข็งของมันจริง เช่นผู้ใช้กระจายทั่วโลกและ dependency เบาพอที่จะรัน runtime ที่ไม่ใช่ Node เต็มรูปแบบได้

การตัดสินใจที่ดีต้องเริ่มจากทำ proof of concept และวัดผลจริง ไม่ใช่ตัดสินใจจากกระแสหรือคำโฆษณาเรื่องความเร็วเพียงอย่างเดียว เพราะต้นทุนของการย้าย stack ที่ผิดพลาดมักแพงกว่าที่คิดตอนเริ่มต้น

• Workers เหมาะกับโปรเจกต์ที่ผู้ใช้กระจายทั่วโลกและ dependency เบา ใช้ Web API เป็นหลัก
• ตรวจ Node API compatibility ของ dependency หลักก่อนตัดสินใจย้ายทั้งโปรเจกต์เสมอ
• ทำ proof of concept และวัด latency ค่าใช้จ่ายจริงก่อนย้าย ไม่ตัดสินใจจากราคาเริ่มต้นอย่างเดียว

คำถามที่พบบ่อย