รีวิว App จ่ายค่าส่วนกลางของหมู่บ้านพัฒนาด้วย Line LIFF ไม่มีค่าใช้จ่าย และใช้งานฟรี
Table of contents
Intro
สวัสดีครับ บทความรีวิวอีกแล้ว 😄 แต่บทความนี้จะยาวหน่อยนะครับ โดยเป็นการรีวิว App จ่ายค่าส่วนกลางของหมู่บ้านพัฒนาด้วย Line LIFF ที่ผมเป็นผู้พัฒนาขึ้นมาเอง โดยที่ไม่มีค่าใช้จ่าย และใช้งานฟรี โดยจะมีแยกเป็น 2 ส่วนคือ
App ระบบจ่ายค่าส่วนกลางของหมู่บ้าน ใช้เวลาพัฒนาประมาณ 1 เดือน ทำงานบน LINE Front-end Framework (LIFF) สำหรับใช้งานในหมู่บ้านจัดสรร โดยเป็น App ที่พัฒนาบนพื้นฐานให้ใช้งานง่ายสำหรับผู้ใช้งาน และ พยายามใช้ Tools ฟรีให้มากที่สุด
ที่มาและปัญหา
เนื่องจากหมู่บ้านที่ผมได้อาศัยอยู่ได้จัดตั้งคณะกรรมการหมู่บ้าน นิติบุคคล วัตถุประสงค์คือดำเนินการจัดการและดูแลทรัพยากรต่าง ๆ ในหมู่บ้าน อีกทั้งก็ได้มีการ จัดเก็บค่าส่วนกลาง เพื่อเป็นงบประมาณสำหรับบำรุค่าใช้จ่ายต่าง ๆ เช่น ค่าไฟฟ้า, ค่า รปภ., ค่าทำความสะอาด, ค่าตัดหญ้า และอื่น ๆ
ปัญหา
- การทำงานแบบเดิมที่ไม่เป็นระบบ เช่น การส่งสลิปแจ้งโอนค่าส่วนกลาง ในไลน์กลุ่มหมู่บ้าน
- ลูกบ้านบางท่านอยากทราบว่าแต่ละเดือนมีค่าใช้จ่ายเท่าไหร่ เช่น ค่าไฟฟ้า
- ลูกบ้านบางท่านอยากทราบว่า
เงินที่เป็นงบประมาณส่วนกลาง
คงเหลืออยู่เท่าไหร่ - อยากให้มีตารางสรุปรายงานค้างชำระค่าส่วนกลางของแต่ละหลัง
ผมในฐานะเป็น Developer และได้อาศัยอยู่ในหมู่บ้านนี้ ก็คิดว่าเราน่าจะสามารถทำ App เพื่อช่วยแก้ปัญหาได้
จึงเสนอตัวในกลุ่มหมู่บ้านว่า เดี๋ยวผมทำ App แจ้งค่าส่วนกลางของหมู่บ้านให้ไหมครับ
อีกทั้ง ลงท้ายด้วยว่า เดี๋ยวทำให้ฟรี ๆ ครับ 😅
นี่จึงเป็นโจทย์ที่ผมต้องหาวิธีที่คำนึงถึง 2 อย่างคือ
- เน้นใช้ Services ที่ฟรี
- ออกแบบให้ง่ายเข้าไว้ (เดี๋ยวจะไม่มีใครอยากใช้ 😅)
- หากต้องมีค่าใช้จ่าย ต้องน้อย ถึงขั้นน้อยมาก ๆ เพราะไม่อยากให้เสียงบประมาณแต่ละเดือนกับ App เยอะ
เพราะส่วนตัวมองว่าหากการจัดเก็บค่าส่วนกลางหมู่บ้าน ไม่ค่อยเป็นระบบ และการออกรายงานค้างชำระช้า ก็จะไม่เห็นความสำคัญ และอาจจะทำให้บ้านบางหลังจ่ายบ้าง ไม่จ่ายบ้าง เพราะหากไม่มีระบบติดตามที่ดีพอ ก็ อาจจะส่งผลให้การจัดกับงบประมาณ ได้น้อยลง
Line LIFF คืออะไร
Solutions หรือวิธีการสำหรับการแก้ปัญหาที่เล่ามาด้านบนก็มีอยู่ไม่กี่อย่างคือ
- Web App PWA เป็นตัวเลือกที่ดี แต่ขาดตรงที่ถ้าอยากให้มีการแจ้งเตือน (Notifications) อาจจะต้องทำให้เชื่อมต่อกับ Line ด้วยก็น่าจะยุ่งยากพอสมควร
- App เป็นตัวเลือกที่ตัดออกไปเลย เพราะจำเป็นต้องส่ง App ขึ้น Store และ ผู้ใช้ต้องติดตั้ง App ลงเครื่องอีก และอาจจะต้องใช้เวลาพัฒนานานเกินไป
- Line LIFF เป็นตัวเลือกที่เหมาะสมที่สุดเพราะว่า
- ใช้งานง่ายไม่ต้องติดตั้ง App (ใช้งาน Line)
- มีเมนูให้ใช้งาน (Rich Menu)
- สามารถใช้ Line Account ผูกกับ App ที่พัฒนาขึ้นได้เลยทำให้การยืนยันตัวว่าอยู่บ้านหลังที่เท่าไหร่ง่ายดาย
- ใน Line มีระบบการแจ้งเตือนให้ใช้
Line LIFF คือ LINE Front-end Framework (LIFF) Web View ที่อยู่ภายในแอปพลิเคชั่น LINE ที่ทำให้เราสามารถเชื่อมต่อเพื่อทำงานร่วมกันระหว่าง ห้องแชต
กับ เว็บ
ให้สามารถทำงานพร้อม ๆ กันได้อย่างมีประสิทธิภาพ ทำให้การใช้งานของผู้ใช้ง่ายขึ้น ผู้ใช้งานมี UX ในการใช้ LINE Official Account (Line OA) ที่ดีขึ้น
รูปภาพตัวอย่างของการใช้งาน LIFF
รูปภาพตัวอย่างของ Line Rich Menu ที่สามารถนำประยุกต์ใช้กับ LIFF สำหรับงานต่าง ๆ เช่น ระบบ Shopping, ระบบนัด, ระบบเชื่อมต่อกับลูกค้า CRM (ที่มา VTAC E-Commerce – Rich Menu)
Village App (LIFF)
สำหรับ LIFF App ที่พัฒนาขึ้นมาสำหรับใช้งานในหมู่บ้านประกอบไปด้วย 6 เมนู เมื่อเชื่อมต่อกับ App ครั้งแรกจำเป็นต้องผูก บัญชีผู้ใช้งาน
กับ บ้านเลขที่
ก่อนโดยมีข้อมูลทั่วไปของ App ดังนี้
ข้อมูลทั่วไป
- หมู่บ้านจัดสรรขนาดเล็กประมาณ 40 หลัง
- ให้สามารถรับโหลดผู้ใช้งานพร้อมกัน ๆ 50 คนได้
- ไม่จำเป็นต้องใช้ระบบ Online payment เพราะมีค่าธรรมเนียมและต้องติดต่อธนาคาร แต่ใช้วิธีแจ้งสลิปแทน
- มีแอดมิน 1 คน (หรือมากกว่า 1 คนได้)
- ใช้งาน App ผ่าน Line LIFF
- เชื่อมด้วย Line Account กับ App ด้วยการเลือกแค่บ้านเลขที่
- ไม่จำเป็นต้อง Login ด้วย Username, Password
- เพื่อไม่ให้การใช้งานยากเกินไป เพราะระบบไม่ได้มีข้อมูลสำคัญอะไร
- UI และเมนูต่าง ๆ ใช้งานง่ายแบบไม่จำเป็นต้องอ่านคู่มือ
- บ้านแต่ละหลังรองรับการเริ่ม
เดือนและปี
จ่ายค่าส่วนกลางที่แตกต่างกันได้ (เพราะบ้านบางหลังยังไม่ถึงกำหนดจ่าย เนื่องจากมีการเก็บล่วงหน้า 2 ปี) - ภายใน App มีเมนู AppDrawer สำหรับใช้เป็นเมนูไปหน้าต่าง ๆ


รูปภาพตัวอย่างของ LIFF App ที่พัฒนาขึ้นมาสำหรับใช้งานในหมู่บ้าน
หน้าผู้ใช้งาน (ลูกบ้าน)
1. หน้าแสดงรายการค้างชำระค่าส่วนกลาง
- มีหน้ารายการ Invoices ของทุกเดือน
- แสดงข้อมูลบ้านตนเองได้แก่ เช่น
- บ้านเลขที่, ขนาด, อัตรา, ค่าส่วนกลาง/เดือน
- เปิด-ปิด สถานะแจ้งเตือนเมื่อใกล้ครบกำหนดชำระ
- เริ่มชำระตั้งแต่ (เดือนและปี ที่เริ่มชำระ เนื่องจากแต่ละหลังไม่เหมือนกัน)
- แสดงข้อมูลบ้านตนเองได้แก่ เช่น
- แสดงสถานะ
- รอชำระ
- ชำระแล้ว
- รออนุมติ
- รองรับการดูประวัติชำระของแต่ละปีได้
- แสดงข้อมูลของแต่ละ Invoice
- สามารถ Download ใบเสร็จรับเงินได้
- แจ้งโอนชำระเมื่อ
- ชื่อผู้แจ้งชำระโอน


2. หน้าแจ้งชำระค่าส่วนกลาง
- แสดงข้อมูลธนาคาร (สำหรับโอนค่าส่วนกลาง)
- ชื่อธนาคาร
- ชื่อบัญชี
- เลขที่บัญชี
- แบบฟอร์มอัปโหลดสลิป
- ไม่จำเป็นต้องใช้ระบบ Payment เพราะมีค่าธรรมเนียมและต้องติดต่อธนาคาร
- แสดงเดือนที่ค้างชำระ (Default)
- เลือกยอดที่ต้องการชำระ (สามารถชำระได้หลายเดือน)
- ชำระ 1 เดือน (xxx บาท)
- ชำระ 2 เดือน (xxx บาท)
- ชำระ 3 เดือน (xxx บาท)
- ชำระทั้งหมดทุกเดือน (xxx บาท)
- แนบไฟล์ได้ไม่เกิน 2048KB
- แนบได้หลายไฟล์
- สามารถลบไฟล์ได้เอง
- เมื่อกด
แจ้งโอน
ให้มีหน้าต่างเพื่อยืนยันอีกครั้ง (สำหรับ re-check)
- มีหน้ารายการประวัติการแจ้งโอน
- ของทุกเดือน
- มีตัวเลือกสำหรับดูปีย้อนหลังได้
3. หน้ารายงาน
- รายงานค้างชำระ
- มีตัวเลือกปีเพื่อดูย้อนหลังได้ทุกปี
- แสดงเป็น PDF เพื่อให้สามารถปริ้น หรือ Save เป็นไฟล์ไปแสดงในไลน์กลุ่มได้
- แสดงข้อมูลบ้านของแต่ละหลัง
- อัตราค้างชำระ
- รวมยอดค้างทุกเดือนของแต่ละหลัง
- รวมยอดค้างทั้งหมด
- รายงานรายรับ/จ่าย
- แสดงจำนวนเงินคงเหลือทั้งหมด
- แสดงจำนวนเงิน รายรับ
- แสดงจำนวนเงิน รายจ่าย
- รายละเอียดรายการ (รายรับ/รายจ่าย)
- ยอดเงิน
- ประเภท
- ข้อความอธิบาย
- วันเวลาที่ทำรายการ
- มีตัวเลือกสำหรับดูปีย้อนหลังได้
4. หน้าข่าวประกาศ
(รออัปเดตเนื้อหา)
5. หน้าแจ้งปัญหา
(รออัปเดตเนื้อหา)
6. หน้าการตั้งค่า
- Login และสามารถยกเลิกการเชื่อมต่อกับ App ได้ (หากต้องการเปลี่ยนบ้านเลขที่)
- แสดงข้อมูลบ้านตนเองหลังจากการ Login ได้แก่ เช่น
- บ้านเลขที่, ขนาด, อัตรา, ค่าส่วนกลาง/เดือน
- เริ่มชำระตั้งแต่
- กำหนดชื่อจริง (สำหรับใช้ออกใบเสร็จรับเงิน)
- ปุ่มสำหรับยกเลิกการเชื่อมต่อกับ App
- ภายใน App มีเมนู AppDrawer สำหรับใช้เป็นเมนูไปหน้าต่าง ๆ
หน้าผู้จัดการ (แอดมิน)
- สำหรับแอดมินจะมีเมนูเพิ่มเติมจากผู้ใช้งานทั่วไป
- ผู้งานในโหมดลูกบ้าน และโหมดแอดมินได้พร้อม ๆ กัน
1. หน้ายืนยันการโอนชำระเงิน
- เมนูรายการรออนุมัติ
- นับจำนวน
- แสดงรายการแบบ Minimal
- แสดงยอดที่แจ้งชำระ (บาท)
- สถานะ รออนุมัติ
- สามารกดดูรายละเอียด (หน้าต่าง Modal)
- แสดงแบบฟอร์ม
- ปุ่มอนุมัติ
- ปุ่มไม่อนุมัติ
- เพิ่มหมายเหตุ (ถ้ามี)
- ปุ่มยืนยัน (อีกครั้ง)
- เมนูรายการตรวจสอบแล้ว
- แสดงรายการแบบ Minimal
- แสดงยอดที่แจ้งชำระ (บาท)
- สถานะ อนุมัติ/ไม่อนุมัติ
- สามารกดดูรายละเอียด (หน้าต่าง Modal)
- แสดงแบบฟอร์ม
- ปุ่มอนุมัติ (แก้ไขไม่ได้)
- ปุ่มไม่อนุมัติ (แก้ไขไม่ได้)
- เพิ่มหมายเหตุ (ถ้ามี)
- ปุ่มยืนยัน (อีกครั้ง)
- มีตัวเลือกสำหรับดูปีย้อนหลังได้
2. หน้าจัดการบัญชี (รายรับ/รายจ่าย)
- แสดงข้อมูลเหมือนหน้า รายงานรายรับ/จ่าย
- มีปุ่มสำหรับสร้างรายการ
- ประเภทค่าใช้จ่าย
- ประจำเดือน
- ค่าใช้จ่าย
- ค่า รปภ.
- ค่าไฟฟ้า
- ค่าทำความสะอาด
- ค่าตัดหญ้า
- ค่าอื่น ๆ
- จำนวนเงิน (บาท)
- หมายเหตุ (ถ้ามี)
- แก้ไข้หรือลบรายการได้
- ไม่สามารถแก้ไขหรือลบประเภทค่าส่วนกลางได้ เนื่องจากเป็นประเภทที่ถูกเพิ่มอัตโนมัติจากระบบ
3. หน้าเพิ่มสิทธิ์ผู้จัดการ (แอดมิน)
- รองรับการแต่งตั้งแอดมินได้หลายคน

Tech stacks
ในส่วน Tech stacks คือส่วนที่พูดถึงรายละเอียดของ Tools และ เทคโนโลยีที่ใช้กับ Project นี้ทั้งหมดโดยแบ่งเป็น
Frontend stacks
- TypeScript v4.7.4 ภาษาที่ใช้พัฒนาในส่วนของ Frontend App
- React v18.2.0 ใช้ TypeScript และ React Library ในการพัฒนาในส่วนของการติดต่อกับผู้ใช้งาน
- Redux Toolkit v.1.8.4 ใช้ Redux Toolkit ใช้เก็บ Global state
- Ant-Design v4.21.5 และ Ant-Design Icons v4.7.0 ในส่วนของ UI Components ทั้งหมด
- LIFF v2.21.0 สำหรับส่วนที่เชื่อม Web view กับห้องแชตของ Line
- Line Rich Menu สำหรับเมนูในการใช้งานใน Line OA โดยประยุกต์ใช้ร่วมกับ LIFF
- Line Flex Messages สำหรับใช้กับ Line API Messaging เพื่อแสดงข้อมูลต่าง ๆ ในรูปแบบ Card
เทคนิคที่ใช้เพิ่มเติม
- เพิ่มประสิทธิภาพลดขนาด App bundle size ด้วย Dynamically Importing กับ React.lazy
- Debouncing
- Throttling คืออะไร แตกต่างกับ Debouncing อย่างไร
- การใช้งานและความแตกต่างระหว่าง useMemo และ useCallback ของ React Hooks
Backend stacks
- PHP v8.1.8 ภาษาที่ใช้พัฒนาในส่วนของ Backend App ทีแรกว่าจะไม่เลือกใช้ PHP เพราะอยากใช้ Stacks ที่เป็น TypeScript ทั้งหมดแต่เพราะว่า
มีปัญหาเรื่อง Cost ในตอน Deploy ระบบ
เนื่องจากงานนี้ใช้ VM ของ Google Cloud (ตัวฟรี) มีสเปคเครื่องที่จำกัดมาก และหากไม่สามารถรองรับผู้ใช้งานได้ไม่มากพอ อาจจะต้องย้ายไปเช่า Shared Hosting ต่อปีแทน (เพราะค่าใช้จ่ายจะถูกกว่าการสเกล VM) - Laravel v9.3.3 สำหรับ Backend framework ร่วมกับ PHP ในการพัฒนา API แต่ได้ดัดแปลง Framework ค่อนข้างเยอะเนื่องจากได้ตัดในส่วน Web, Views, Services Providers และ Middlewares ที่ไม่จำเป็นออกทำให้ Framework นั้นมีความเร็วขึ้นมาก เพราะนำมาใช้พัฒนาแต่ในส่วนของ API เท่านั้น
- APCu ใช้ Driver APCu เพิ่มสำหรับการ Cache ค่าต่าง ๆ ภายใน Framework ส่งผลให้มีความเร็วขึ้นมากขึ้นมากอีก
- OPcache และ Just-In-Time (JIT) เปิดใช้งาน OPcache และกำหนดค่า Buffer size ของ JIT (tracing) สำหรับเพิ่มประสิทธิภาพของ PHP หลัง Compiled แล้วที่ใกล้ชิดในชั้นของ run-time ทำให้ส่งผลให้การทำงานเร็วขึ้นมากขึ้นมาก
- PostgreSQL v14.5 คือ Database สำหรับจัดเก็บข้อมูลทั้งหมด เพราะช่วงหลัง ๆ เลิกใช้ MariaDB กับงานใหม่ ๆ แล้ว เนื่องจากชอบ Features ของ PG มากกว่าและดูเหมือนว่าการใช้ RAM ของ PG จะน้อยกว่า MariaDB อาจจะเป็นเพราะมีการคืน RAM ที่ดีกว่า
- Imgur API สำหรับเก็บรูปภาพต่าง ๆ ที่ผู้ใช้งานได้อัปโหลดจาก App แทนการจัดเก็บข้อมูลใน Local storage เพราะเนื่องจาก VM ของ Google Cloud (ตัวฟรี) ที่ใช้งานอยู่ให้ Storage เพียงแค่ 30GB (ยังไม่หักในส่วนพื้นที่ของ OS และของ Database) ทำให้อาจจะไม่เพียงพอสำหรับใช้งานในอนาคต ทำให้เปลี่ยนมาใช้ Imgur API แทนซึ่งก็เพียงพอสำหรับงานนี้
- สามารถอัปโหลดรูปภาพได้ไม่เกิน 1,250 รูปภาพ/วัน
- หรือ 12,500 requests/วัน
- NGINX สำหรับทำ Web Server และติดตั้ง SSL ของ Cloudflare
เทคนิคที่ใช้เพิ่มเติม
- ระบบ Queues
- ระบบ Queues สำหรับสร้าง Invoices (ปีละครั้ง)
- ระบบ Queues สำหรับส่งข้อความแจ้งเตือน (Notifications) เพื่อแจ้งเตือนผู้ใช้งานหากยังไม่ได้ชำระค่าส่วนกลางเมื่อใกล้ครบกำหนดชำระ
- สำหรับการ Tuning เพื่อเพิ่มประสิทธิภาพให้กับ PostgreSQL นั้นไม่ยุ่งยากเหมือนของ MariaDB หรือของ MySQL เลย เพราะสามารถสร้าง Configs จากเว็ปไซต์นี้ https://pgtune.leopard.in.ua/ แล้วสามารถนำค่าที่ได้มาใช้ได้เลย
ที่จริงเรื่อง ระบบ Queues สามารถนำไปเขียนเป็นบทความนึงได้เลย เนื่องจากเป็นระบบที่มีประโยชน์พอสมควร เพราะว่าแทนที่เราจะรันโปรแกรมกับบาง Process ที่ต้องรันนาน ๆ กว่าจะเสร็จ และกินทรัพยากรเครื่อง ก็เปลี่ยนเป็นการแยกย่อยงานเป็น Queue จากนั้นก็ส่งไปทำงานทีละรายการแทน เช่น ตัวอย่างปัญหา
หากมีผู้ใช้ในระบบ 1,000 คน และต้องการส่งข้อความที่แตกต่างกันไปที่ Line
- แบบปกติเราก็จะวน (Loop) ข้อมูล 1,000 รายการแล้วส่งข้อความทั้งหมดทีเดียว
- แบบที่ใช้ Queue หลักการคือจะแยกงานจาก 1,000 รายการเป็น 1 คิว และทำงานทีละคิว (เป็น Background processing)
Deployment stack
ในส่วนนี้จะอธิบายการ Deploy ระบบทั้งในส่วนของ Frontend และ Backend App โดยมีการใช้เครื่องมือต่าง ๆ ดังนี้
- Cloudflare DNS พอดีว่าไม่ได้ซื้อ Domain name สำหรับโปคเจคนี้ก็เลยใช้
2my.xyz
(ของส่วนตัว 😅) สำหรับออก Sub-domain name เพื่อใช้กับ Frontend และ Backend - Cloudflare SSL / TLS
- เปิดใช้งานโหมด
Full (strict)
บน SSL / TLS แบบความปลอดภัยสูงสุด
แต่การเปิดใช้งานโหมดนี้จำเป็นต้องติดตั้งCloudflare Origin CA certificate
บน Webserver (NGINX) ด้วย - เปิดใช้งาน Cloudflare DNS Proxied ทำให้ได้รับการป้องกันการโจมตีแบบ DDoS และ ได้รับคุณสมบัติ
CDN Cached
ที่จะช่วยลด Traffic bandwidth จากพวก Web Assets
- เปิดใช้งานโหมด
- GitHub สำหรับเก็บ Code ทั้งของ Frontend และ Backend
- Google Cloud Always Free Tier Compute Engine (e2-micro) Google มี Cloud แบบใช้ฟรีตลอดชีพด้วยนะ แต่ให้สเปคค่อนข้างน้อยมากทำให้เป็นงานที่ยากที่จะออกแบบ App และ Tuning ระบบให้ใช้งานและรองรับผู้ใช้งานไหว
- Compute Engine สเปค e2-micro 0.25 vCPU และ RAM 1 GB
- 30GB (standard persistent disk)
- ภายในติดตั้ง Ubuntu Server จากนั้นติดตั้ง Services ต่าง ๆ ดังนี้
- PostgreSQL
- NGINX
- PHP-FPM
- Docker เป็นตัวช่วยในการ Deploy ทั้งหมดไม่ว่าจะเป็น NGINX, PostgreSQL และ PHP-FPM
- Cloudflare Pages สำหรับ Frontend Deploy แบบอัตโนมัติ
- เชื่อมต่อกับ Cloudflare DNS สำหรับออก Domain name
- เชื่อมต่อกับ Github หาก Code มีการอัพเดตก็จะ Deploy แบบอัตโนมัติทันที
สำหรับใครอยากอ่านวิธีการ Deploy ด้วย Cloudflare Pages สามารถอ่านได้จากบทความนี้ มารู้จักกับ Cloudflare Pages ของฟรีและดีสำหรับสาย JAMstack platform
การใช้ทรัพยากรใน Compute Engine e2-micro
ตามที่พูดเอาไว้ข้างต้นว่าโปรเจคนี้เน้นใช้ของฟรี และพยายามไม่ใช้เกิดใช้จ่ายใด ๆ ดังนั้นจึงเลือกใช้ Google Cloud Always Free ที่เป็นแบบใช้ฟรีตลอดชีพ แต่ให้สเปคค่อนข้างน้อยมากคือ
- Compute Engine สเปค e2-micro 0.25 vCPU และ RAM 1 GB
- 30GB (standard persistent disk)
ทำให้จึงต้องพยามจูนและการ Coding เพื่อให้กินทรัพยากรเครื่องน้อยที่สุดเท่าที่เป็นไปใด้
จากรูปภาพข้างบนจะเห็นว่าทั้งระบบใช้ RAM ทั้งหมดประมาณ 300MB (รวมทั้ง OS แล้ว) โดยถ้าสังเกตดู PostgrsSQL นั้นใช้แรมน้อยมากแค่ 30MB เอง 😅 (ผู้ใช้งานพร้อมกันประมาณ 20 คน)
รวมค่าใช้จ่าย
Tools/Services | ราคา (บาท) |
---|---|
Frontend stack | 0.00 |
Backend stack | 0.00 |
Google Cloud Compute Engine สเปค e2-micro 0.25 vCPU 1 GB RAM | 0.00 |
Cloudflare SSL | 0.00 |
Cloudflare Pages | 0.00 |
LIFF, Line Rich Menu, Flex Messages | 0.00 |
Imgur API | 0.00 |
Total | 0.00 |
สรุป
ขอบคุณที่อ่านจนจบครับ 😊 สาระที่สำคัญของบทความนี้คือต้องการเล่า Tech stacks ที่พูดถึงรายละเอียดของ Tools และ เทคโนโลยีทั้งหมดที่ใช้กับ Project นี้โดยแบ่งออกเป็น Backend stacks, Frontend stacks และวิธีการทำอย่างไรให้โปรเจคนี้มีค่าใช้จ่ายน้อยที่สุด หรือฟรี ซึ่งมันทำได้จริง 😄 🎉
โปรเจคนี้จะพยายามพึ่งพา Services ฟรีต่าง ๆ ไม่ว่าจะเป็น Imgur API
สำหรับเก็บรูปภาพฟรี ๆ หรือ Google Cloud Always Free
ที่เป็นแบบใช้ฟรีตลอดชีพ และ Cloudflare Services
ต่าง ๆ ที่ช่วยในการ Deploy เป็นของฟรีและดีมาก ๆ
สำหรับโปรเจคนี้ใช้เวลาพัฒนา 1 เดือน ผมทำเป็นงานเพิ่มเติมหลังงานประจำ และสาเหตุที่ผมอยากทำโปรเจคนี้เพราะผมอยากทดลองใช้เทคนิคต่าง ๆ ในเงื่อนไขกับงานจริงที่มีข้อจำกัดต่าง ๆ อีกทั้งถ้าทำเสร็จผมเองที่อาศัยในหมู่บ้านนี้ก็จะได้ใช้ด้วย 😊
โปรเจคนี้เริ่มใช้งานจริงแล้วในเดือนสิงหาคมนี้ และทุกคนในหมู่บ้านแฮปปี้และพอใจพอสมควรเพราะช่วยให้ทำงานง่ายขึ้น และฟรี 😅