บันทึกการสร้าง Web Blog ใหม่ที่ตั้งเป้าให้ค่าใช้จ่ายรายเดือนเท่ากับ "ศูนย์"

ถือเป็นการเปิดประเดิม Blog แรกของเว็บใหม่ไปเลยแล้วกัน ด้วยการเขียนบันทึกกระบวนการสร้าง Web Blog ใหม่ตัวนี้ขึ้นมา

ย้อนความ

ผู้เขียนเองเคยมีความพยายามกับการทำ Web Blog มาก็หลายครั้ง ก่อนหน้านี้เคยใช้ทั้ง Ghost.js มาก็หลายเวอร์ชัน ตั้งแต่เปิดเครื่องบน Digital Ocean รันตรงๆ มี back office ใช้สบายๆ รวมถึงระบบจัดการ SEO ที่ครบในตัวอยู่แล้ว

ต่อมาก็อยากหาวิธีลดค่าใช้จ่ายลง เพราะเราเองก็เขียนบันทึกเฉยๆ ไม่ได้ทำรายได้ทางตรงจากเว็บไซต์ เลยปรับระบบมาเป็นการทำ Ghost.js as a backend เปิดรันบนเครื่องตัวเองใน local แล้วจับเอา Gatsby มาทำ Frontend โดยตั้งให้ Gatsby ดึงข้อมูลจาก Ghost.js Database มาทำสร้างหน้าต่างๆ ให้และ build ออกมาเป็น static HTML แน่นอนว่าข้อดีคือประหยัดมากกก แล้วก็จับเอาขึ้น Firebase Hosting ฟรีๆ กันไปเพราะยอดคนเข้าไม่ได้เยอะถึงเกณฑ์เสียเงิน

แน่นอนว่าเราแก้โจทย์เรื่องประหยัดได้ แต่ความลำบากในการเปิดระบบมาเขียน Blog และ workflow ต่างๆ มันกลายเป็นแรงเสียดทานในการเขียน Blog ไปในตัว ผลสุดท้ายคือในเวอร์ชันนี้ แทบไม่ได้เขียนอะไรลงเว็บเลย

เลยยอมกลับไปสูตรเดิมคือ กลับไปหา Digital Ocean เปิดเซิฟเวอร์รันเหมือนเดิม แล้วก็กลับมาเขียนลงเป็นระยะๆ จนได้

อ้าว แล้วทำไมงวดนี้มาปรับใหม่อีกล่ะ เหนื่อยแบบเดิมไม่เข็ดหรอ ... ก็ใช่แหละ แต่ความต้องการอันยิ่งใหญ่ของเรามันกลับมา คืออยากประหยัดเงิน!

เดิมจ่ายค่าเซิฟ Digital Ocean สำหรับรัน Ghost.js เนี่ยมันก็ตกเดือนละเกือบ 700 บาทนะ แล้วพอยุคนี้ยังมีค่าใช้จ่ายภาคบังคับอีกตัวคือ AI Subscription โผล่มาอีก ใช้ Gemini AI Pro ก็โดนไปอีก 750 บาทต่อเดือน เลยต้องมาชั่งน้ำหนักความสำคัญละ ก็คือปิดเซิฟ Digital Ocean ไปเลย

หลังจากนั้นเว็บไซต์ก็หายไปร่วมครึ่งปีได้ ขณะเดียวกันฝั่ง AI เองก็แอบมีความว้าวในมุมของการเอา AI มาเขียนโค้ดที่กระแสไม่แผ่วลงเลย จนได้มาลองใช้งาน Firebase Studio ที่ Google ทำครอบบน Firebase ให้เรา Vibe Code สร้าง Web หรือ App ได้ และเสริมความสะดวกด้วยการเชื่อมกับ service ต่างๆ ของ Firebase ที่มีอยู่ครบถ้วนอยู่แล้วสำหรับการใช้งานมาตรฐานทั่วไป และยังรองรับโหมดที่เปิด editor แก้ไขโค้ดเองได้ด้วยเช่นกัน

พอได้ลองทำ Web เล่นๆ ไปหนึ่งตัวก่อนหน้านี้ ไว้จัดการตารางเที่ยวของตัวเอง ก็พบว่า มันก็พอใช้ได้นะ ต้องนั่งแก้บั๊กเองประปราย แต่ก็ใช้สำหรับงานที่เราขี้เกียจทำเองได้ดีทีเดียว ตัว Web ที่ออกมาเป็น Next.js แล้วจังหวะพอดีที่ Firebase App Hosting ก็พร้อมแล้ว ทำให้เรา deploy Web app ลักษณะที่ต้องการเซิฟเวอร์ด้วยขึ้นไปได้เลย

เข้าใจว่าเบื้องหลังของ Firebase App Hosting ก็คือประยุกต์เอา Cloud Run ของ Google Cloud มาใช้ และมี workflow สำหรับ build, containerization, deploy หลังจากศึกษาไปนิดนึง ก็ดูฝั่งของราคา เลยพบว่ามันเหมือนกับ Firebase Service อื่นๆ คือมีช่วงการใช้งานที่ Free ถ้าใช้ไม่เกินกำหนด แล้วย้อนเช็คเว็บแรกที่ทำไป ก็ไม่เสียเงินสักกะบาท เลยเป็นที่มาของแผ่นการสร้าง Web Blog ใหม่ตัวนี้

วางแผน

จากประสบการณ์ Web ที่เขียนเองก็ด้วย และที่เคยลองใช้ Firebase Studio มาแล้วก่อนหน้านี้ ก็พอเข้าใจข้อจำกัดมันพอตัว และเพื่อที่เราจะบรรลุเป้าหมายในการลดค่าใช้จ่ายด้วย ก็ต้องหาข้อมูลให้รอบด้านในเชิงสเปคของ Web Blog ว่ามันใช้อะไรบ้าง

• Framework เรามีแล้วคือ Next.js

  • Frontend ทำ Server-side rendering ได้

  • Optimize Frontend ได้ด้วยท่าของ Incremental Side Regeneration (ISR) ช่วย caching และคุมการ invalidate cache เองได้

  • Metadata ต่างๆ ก็ตั้งค่าไม่ยาก เพียงพอสำหรับ SEO ทั่วไป

  • UI Back office สำหรับนั่งเขียน และจัดการ Blog

  • API ต่างๆ ก็ทำบน Next.js ได้เลย

  • Rich Text Editor ลองเอา TipTap มาใช้

• Database ใช้ Firebase Firestore

  • งวดนี้ต้องจัดการ Security Rules ดีๆ แล้ว เพราะไม่ได้ทำขำๆ แล้วทิ้ง 555

• Storage/CDN สำหรับเก็บภาพประกอบ Blog ใช้ Firebase Storage ไปก่อน เข้าใจว่าตั้งค่าในขา GCP Cloud Storage เพื่อทำ CDN อีกทีได้

Firebase Studio

ถ้าใครตามอัพเดทผลิตภัณฑ์จาก Google มาเรื่อยๆ คิดว่าคงเคยเห็นความสามารถของ Firebase Studio กันไปแล้ว พูดกันง่ายๆ ก็คือ Vibe Code สำหรับขายของ Firebase ฮ่าๆ

นั่นแหละครับ ก็มีกล่องแชทให้พิมพ์ๆ สั่งๆ ไป แล้วมันก็จะจัดการเองโดยอิงกับ tech stack ที่เป็นที่นิยมอยู่แล้ว ฝั่ง Web ก็เลยกลายเป็น Next.js นั่นเอง

แล้วมันดีมั้ย?

ผมขอเปรียบเทียบให้เห็นภาพด้วยกฏ 80/20 แล้วกันครับ

80/20 Rule ในโลก AI Coding

การพัฒนา Web Blog ใหม่ตัวนี้ ถ้านับวันแบบกลมๆ คิดว่าใช้เวลาประมาณ 2 วันครับ ถ้าเราลงเป็นชั่วโมงอาจจะน้อยกว่านั้นนิดนึง และใช่ครับ ในไม่กี่ชั่วโมงแรก ผมสามารถ Prompt ให้ Firebase Studio ขึ้นระบบได้จนเห็นหน้าตาครบทุกหน้าได้แล้ว

• Landing page

• About me

• CMS

  • Dashboard stats

  • Blog Post management

  • Site config

  • Script config (ลอกฟีเจอร์ plugin WordPress มาเลย แฮ่)

มาครบจนผมเกือบจะกด Deploy แล้วด้วยซ้ำ

แต่หลังจากนั้นแหละครับ บริบทก็เปลี่ยนทันที จากที่งานที่เหลือควรจะเป็นงาน AI มันกลายเป็นงานผมหมดเลย เพราะว่า Firebase Studio ขาดความเข้าใจในเรื่องรายละเอียดไปพอตัว ที่ผมเจอระหว่างทางก็ตามนี้ครับ

1. ระบบไม่ได้คิด Authentication ที่ดีมาแต่แรก -- Firebase Studio พยายามเลียนแบบ Blog ที่เราติดตั้งเองด้วยการให้กรอกอีเมลและรหัส เป็นการสมัคร Admin เสร็จทันที แน่นอนว่าใครใช้ WordPress มาก็อาจจะคิดว่าปกตินี่ แต่ระบบนี้หน้าที่กรอกข้อมูลได้ มันเป็นหน้า public น่ะสิ แล้วไม่ได้มีระบบจัดการปิดหน้าทิ้งหลังสร้าง Admin แล้วด้วย เพราะใช้ reuse เป็นหน้า Log in CMS ด้วย

   

2. ออกแบบ Database Structure ไม่ดี -- ผมอธิบายว่า Database ควรจะมี Collection อะไรบ้าง ซึ่งเวลาเราพูดถึง Collection กับ Developer ด้วยกันนี่ก็จะเข้าใจกัน ภาษาฝั่ง SQL มันก็คือ Table แต่ผลที่ได้คือมันทำ Nested ครับ เอา Posts ไปซ้อนอยู่ข้างใน Authors แล้วกว่าจะ debug เจอก็นั่งงงว่าทำไมมัน query อะไรแล้วระเบิดตลอด
   

   

   แล้วดูมันตอบตอนผมสั่งมันแก้ไป

3. Firebase Studio ไม่รับรู้ถึงปัญหาจาก console และขาดความเข้าใจ framework -- พอทุกอย่างดูเรียบร้อย ผมก็กด Publish เพื่อ Deploy แล้วก็พบว่ามันพัง เลยกดไปดู build message เจอว่าเป็นปัญหา TypeScript เลยย้อนกลับมาที่หน้า Code Editor เพื่อลอง build เองดู เลยพบว่ามีปัญหาเรื่อง Type ไม่ถูกต้องของหน้า Page Component ของ Next.js ที่การส่ง parameter (page/:param) มาจะมี Type เป็น Promise แต่ code ที่ได้ออกมาไม่ได้จัดการเอาไว้
   

   

   
   ส่วนนี้ไม่แน่ใจว่า Type มันผิดพลาดจาก lib หรือว่ายังไง แต่อิงจาก Document ของ Next.js และ build error ผมเลยต้องมาแก้ ตอนแรกสั่ง AI ให้มันแก้ มันก็บอกแก้แล้ว แต่เข้าไปดูคือยังผิดอยู่ เหมือนพยายามแก้ผิดจุด แล้วที่น่าโมโหที่สุดคือ หลังผมไปแก้มือเอง แล้วบอกมันว่าแก้แล้วนะ มันก็บอกว่า ไม่ๆ คุณผิด ผมจะแก้กลับ รวมถึงตอนปรับส่วนอื่นๆ ในหน้า page ที่มีการรับ param แบบนี้ในภายหลัง มันก็ไปลบ Promise type ออกอีก เสียเวลามากกับการตบตีนี้

ที่ผมบอกว่าจะหยิบยกกฏ 80/20 มาก็เพราะว่า ผมมองว่าเวลา 20% ของระบบนี้ผมสามารถได้ผลลัพธ์จาก AI ไปแล้วกว่า 80% ขณะเดียวกัน งานอีก 20% ผมกลับใช้เวลามากกว่ามากๆ ในการจัดการมันเอง ทั้งแก้ปัญหาต่างๆ และปรับจูนให้เนี้ยบขึ้น และปริมาณเวลาอาจจะนับเป็น 80% ของเวลาทั้งหมดที่ใช้ก็คงไม่ผิด

ขอบ่นเรื่อง App Hosting และ Custom Domain

อันนี้แอบนอกเรื่องประเด็นหลัก แต่คิดว่าอาจจะเป็นประโยชน์กับใครที่เข้ามาเล่น Firebase App Hosting แล้วจะตั้ง DNS ให้กับ Custom Domain ของตัวเอง ปกติเวลาจะตั้ง Custom Domain มันจะมีเมนูอยู่ใน setting ของ App Hosting แล้วให้เรากรอก Domain ของเรา มันก็จะโชว์ว่าเราต้องไปตั้ง DNS ยังไงบ้าง หลักๆ ก็จะมี 3 ตัวคือ

• A Record สำหรับทำ Domain IP Mapping

• TXT record แสดงว่าเราเป็นเจ้าของ Domain

• CNAME สำหรับให้ App Hosting ทำ SSL Certificate

แต่ปัญหาหลักๆ ที่ผมเจอมี 2 เรื่องคือ

1. คำแนะนำจากหน้า Firebase มันชวนสับสน -- ค่าที่ต้องเอาไปกรอกใน DNS มันมีห้อย full stop (.) มาด้วย พอมันมาอยู่กับค่าพวกนี้ มี Domain / Sub Domain มันก็ทำให้งงว่ามันต้องกรอกไปด้วยมั้ยนะ ถ้าบอกว่าตรงนี้ยังไม่งง ไอ้ปุ่ม copy ที่ App Hosting ทำไว้มัน copy full stop ติดไปด้วยไง มันเลยสับสน แต่หลังจากทำมา 2 เว็บแล้ว ตรงนี้บอกเลยว่า ไม่ต้องไปห้อยจุดต่อท้ายจ้า

2. CNAME acme challenge -- สำหรับการตั้งค่า CNAME มันจะต่างกันระหว่างตั้งให้ Domain กับ Sub Domain โดยค่ามันจะมีแพทเทิร์นหน้าตาประมาณนี้ _acme-challenge_xxxxxxx.domainname.com และถ้าเป็น Sub Domain ก็จะเป็น _acme-challenge_xxxxxxx.sub.domainname.com แบบนี้ ที้นี้คือตอนเอาไปใส่ใน DNS อะ ของ Sub Domain ใส่ทั้งยังงั้นได้เลย แต่ของ Domain เปล่าๆ เราต้องลบมันทิ้ง! ให้กลายเป็น _acme-challenge_xxxxxxx แล้วจาก App Hosting มันใส่มาเต็ม มันไม่บอกเรา นี่ก็งงอยู่นาน ไม่แน่ใจระหว่างค่าผิด หรือ DNS มันรออัพเดตนาน จนไม่เจอ Stack Overflow มีคนบอกให้ลบ Domain name ออก (ใช่ครับ สิ่งนี้ AI ก็ช่วยผมไม่ได้)
   

Verdict แล้วมันเป็นยังไง ทั้ง Vibe Code และค่าใช้จ่ายของ Blog?

ความคิดเห็นผมต่อ AI Assisted Coding ยังไม่เปลี่ยนไป แม้ว่าจะนั่ง Viber Coding ระบบนี้ขึ้นมา เพราะมันต้องการ Human in the loop มาคอยตรวจสอบและตัดสินใจอยู่ดี แม้ในตอนนี้เราจะเห็นคนเคลมเยอะขึ้นเรื่อยๆ ว่าเค้าใช้คนน้อยลงมาก (อันนี้เข้าใจได้หน่อย) หรืแม้กระทั่งไม่อ่าน code แล้ว (อันนี้ผมไม่ค่อย buy ระยะยาวนะ) ถ้าถามผมตอนนี้ผมก็ยังคิดว่าต้องมีคนคอยดูผลลัพธ์ตลอด

ส่วนค่าใช้จ่ายของ Web Blog นี้ เนื่องจากมันเพิ่งรันมาได้ไม่ถึงเดือน นับจริงๆ จนถึงเวลาที่เขียน Blog นี้น่าจะราว 2 สัปดาห์เอง ยังสรุปผลไม่ได้ แต่ถ้าตามการคำนวณแล้ว คิดว่าค่าใช้จ่ายรายเดือนจะเป็น 0 บาท จริงๆ ครับ เย้! ไว้อาจจะแวะมาอัพเดต Usage & Billing ไว้อีกครั้งหลังครบเดือนเต็มๆ ครับ

สวัสดี