รีวิว 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 เดือน ผมทำเป็นงานเพิ่มเติมหลังงานประจำ และสาเหตุที่ผมอยากทำโปรเจคนี้เพราะผมอยากทดลองใช้เทคนิคต่าง ๆ ในเงื่อนไขกับงานจริงที่มีข้อจำกัดต่าง ๆ อีกทั้งถ้าทำเสร็จผมเองที่อาศัยในหมู่บ้านนี้ก็จะได้ใช้ด้วย 😊
โปรเจคนี้เริ่มใช้งานจริงแล้วในเดือนสิงหาคมนี้ และทุกคนในหมู่บ้านแฮปปี้และพอใจพอสมควรเพราะช่วยให้ทำงานง่ายขึ้น และฟรี 😅

