สร้างช่อง WhatsApp สอนคำศัพท์ภาษาเยอรมัน: บทเรียนยากกว่าที่คิด

ไอเดียเริ่มต้นนั้นเรียบง่ายมาก เพียงแค่ต้องการสร้างช่องบน WhatsApp ที่ส่งคำศัพท์ภาษาเยอรมันระดับ A1 พร้อมตัวประโยคตัวอย่างและเทคนิคช่วยจำทุกๆ เช้า ซึ่งตัว AI อย่าง Gemini สามารถสร้างเนื้อหาเหล่านี้เสร็จได้ภายในพริบตาเดียว แต่ทว่าโปรเจกต์จริงกลับกลายเป็นการต่อสู้กับระบบเซสชันของ WhatsApp แพลตฟอร์มโฮสติ้งสองแห่ง และการแก้ไขประวัติ Git ของเรโปซิโทรีตัวเองในท้ายที่สุด

ไลบรารีอย่าง whatsapp-web.js มักเป็นตัวเลือกแรกๆ ที่คนส่วนใหญ่เลือกใช้ เนื่องจากจำลองการทำงานของเบราว์เซอร์ Chrome แบบ headless เพื่อเข้าสู่ระบบเว็บ WhatsApp ซึ่งใช้งานได้จริงในเครื่องส่วนท้องถิ่น แต่ทันทีที่พยายามนำไปdeploy บนคลาวด์ จะต้องพบกับปัญหาเดิมที่ทุกคนต้องเจอ นั่นคือเซสชันที่จำเป็นต้องใช้ในการคงสถานะการล็อกอินคือโพรไฟล์ Chromium เต็มรูปแบบ ทั้งคุกกี้, IndexedDB, และแคช ซึ่งโพรไฟล์ของผู้พัฒนาเองมีขนาดใหญ่ถึง 43 เมกะไบต์

เนื่องจากความลับบน GitHub มีข้อจำกัดขนาดเพียงระดับกิโลไบต์ วิธีแก้ปัญหาเฉพาะหน้าตามที่หลายบทแนะนำเสนอคือ การบีบอัดไฟล์เป็น tar, เข้ารหัสด้วย base64, แล้วยัดใส่เข้าไปใน GitHub Secrets ก่อนจะถอดรหัสกลับมาใช้งานในทุกครั้งที่ CI ทำงาน ซึ่งผู้พัฒนาเองก็เคยทำวิธีนี้โดยมีสคริปต์ชื่อ setup.ts คอยพิมพ์ก้อนข้อมูล base64 ขนาดยักษ์เพื่อให้คัดลอกไปวางในหน้าจัดการความลับด้วยมือ

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

เบื้องหลังปัญหาการทำระบบอัตโนมัติบน WhatsApp คือความพยายามของแพลตฟอร์มในการป้องกันบอทสแปม การจำลองเบราว์เซอร์หรือการใช้โปรโตคอลที่ไม่เป็นทางการมักจะมีความเปราะบางสูงและขัดกับนโยบายการใช้งานของโฮสติ้งหลายแห่ง นักพัฒนาจึงต้องระมัดระวังเรื่องการจัดการเซสชันและความปลอดภัยของข้อมูลรับรอง (Credentials) เสมอเมื่อต้องเชื่อมต่อกับแอปพลิเคชันแชทเชิงพาณิชย์

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง

สำหรับการโฮสต์โปรเจกต์นี้ เคยถูกนำไปติดตั้งบนสามแพลตฟอร์มพร้อมกันคือ Railway, Render และ GitHub แต่ไม่มีแพลตฟอร์มไหนใช้งานได้สำเร็จ โดย Railway มีนโยบายการใช้งานที่เป็นธรรมซึ่งห้ามใช้ userbots อย่างชัดเจน เช่น บอทที่ล็อกอินผ่านบัญชีส่วนตัวด้วยโปรโตคอลที่ไม่เป็นทางการ ส่วน Render พบปัญหาที่ไลบรารี RemoteAuth เก็บเซสชันผ่าน Mongo แล้วไม่สามารถกู้คืนได้อย่างเสถียรจนต้องสแกนคิวอาร์โค้ดใหม่ซ้ำๆ

ทางออกที่ใช้งานได้จริงคือการเปลี่ยนไปใช้ไลบรารี Baileys ที่เชื่อมต่อกับโปรโตคอลหลายอุปกรณ์ของ WhatsApp ผ่าน WebSocket โดยตรง โดยไม่ต้องพึ่งพา Chromium หรือ Puppeteer ทำให้เซสชันเหลือเพียงไฟล์ JSON ขนาดเล็กระดับกิโลไบต์เท่านั้น

"I wanted something dumb simple - a WhatsApp Channel that posts one German word every morning... The actual project turned out to be an argument with WhatsApp's session model, two hosting platforms, and, at one point, my own repo's git history."

ผู้พัฒนาโปรเจกต์

การเปลี่ยนแปลงครั้งนี้ช่วยแก้ปัญหาได้สองอย่างพร้อมกัน เซสชันมีขนาดเล็กจนสามารถเก็บไว้ในคลัสเตอร์ MongoDB Atlas แบบฟรีได้ และไม่ต้องรันเบราว์เซอร์บนเซิร์ฟเวอร์ ทำให้รันบนเครื่องเซิร์ฟเวอร์ฟรีเทียร์ที่มีทรัพยากรจำกัดได้อย่างราบรื่น นอกจากนี้ ความต้องการจริงคือการโพสต์ข้อความวันละครั้ง ซึ่งใช้เวลาประมวลผลเพียง 60 วินาทีต่อวัน ทำให้สามารถเปลี่ยนไปใช้ GitHub Actions cron job ได้ฟรีๆ โดยลบ Dockerfile, Render และ Railway ทิ้งทั้งหมด

ในระหว่างช่วงแรกที่ยังยุ่งเหยิง มีการเผลอคอมมิตโฟลเดอร์เซสชัน .wwebjs_auth ที่มีไฟล์ถึง 204 ไฟล์ รวมถึงไฟล์ดัมพ์ tar/base64 ขนาด 27MB และ 41MB ขึ้นไปบน Git ซึ่งโฟลเดอร์นี้คือเซสชันการล็อกอินที่ใครก็ตามที่อ่านเรปอนี้สามารถนำไปใช้สวมรอยบัญชี WhatsApp ได้ทันที วิธีแก้ปัญหาที่แท้จริงไม่ใช่แค่การใช้คำสั่ง git rm แต่ต้องใช้คำสั่ง git filter-repo เพื่อล้างเส้นทางนั้นออกจากประวัติทั้งหมดแล้วบังคับพุชขึ้นไปใหม่

สำหรับการเรียกใช้โมเดล AI อย่าง Gemini ผู้พัฒนาได้สร้างระบบ fallback chain เพื่อป้องกันปัญหาความล้มเหลว โดยหากโมเดลล่าสุดอย่างรุ่น 3.7 เกิดข้อผิดพลาดระดับ 503 Service Unavailable ขึ้นมากลางคัน ระบบจะสลับไปใช้โมเดลตัวถัดไปในรายการโดยอัตโนมัติ ทำให้โพสต์ข้อความได้ทันทีโดยไม่ต้องเข้าไปแก้ไขใดๆ

ที่มา: Dev.to