Firebase Cloud Functions — คืออะไร ทริกเกอร์ และวิธีเขียนฟังก์ชัน

Firebase Cloud Functions คืออะไรและทำงานอย่างไร

Firebase Cloud Functions คือแพลตฟอร์มการคำนวณที่สร้างขึ้นบน Google Cloud Functions (GCF) ซึ่งปรับให้เข้ากับระบบนิเวศของ Firebase ฟังก์ชันคือโค้ด JavaScript หรือ TypeScript ทั่วไปที่ส่งออกจากโมดูลและลงทะเบียนสำหรับเหตุการณ์ประเภทใดประเภทหนึ่ง เมื่อเหตุการณ์เกิดขึ้น (เช่น ผู้ใช้ลงทะเบียนหรืออัปโหลดไฟล์) Firebase Cloud Functions จะรันโค้ดที่เกี่ยวข้อง โดยส่งบริบทของเหตุการณ์ไปให้

สถาปัตยกรรมของ Cloud Functions เป็นไปตาม หลักการความรับผิดชอบเดียว: ฟังก์ชันหนึ่งจัดการเหตุการณ์หนึ่งประเภทและดำเนินการแบบอะตอมมิกหนึ่งรายการ ตัวอย่างเช่น ฟังก์ชัน sendWelcomeEmail ถูกเรียกเมื่อผู้ใช้ใหม่ถูกสร้างขึ้นใน Firebase Authentication และส่งอีเมลต้อนรับ การแยกส่วนดังกล่าวช่วยให้การดีบัก การทดสอบ และการนำฟังก์ชันไปใช้ซ้ำในโปรเจกต์ต่าง ๆ ง่ายขึ้น

แต่ละฟังก์ชันทำงานในคอนเทนเนอร์ที่แยกจากกันโดยมีวงจรชีวิตชั่วคราว เวลาดำเนินการสูงสุด โดยค่าเริ่มต้นคือ 60 วินาที (ฟังก์ชัน HTTPS — 9 นาที) หากฟังก์ชันไม่เสร็จสมบูรณ์ภายในเวลาที่กำหนด คำขอจะล้มเหลวด้วยข้อผิดพลาด 500 สำหรับการดำเนินการที่ใช้เวลานาน ให้ใช้ Cloud Tasks หรือ Pub/Sub พร้อมการลองใหม่ คอนเทนเนอร์สามารถนำกลับมาใช้ใหม่สำหรับการเรียกครั้งต่อไป (keep-alive) ซึ่งช่วยลดความหน่วงในการสตาร์ทเย็นหลังจากเรียกครั้งแรก

สภาพแวดล้อมรันไทม์และเวอร์ชัน Node.js

Firebase Cloud Functions รองรับ Node.js หลายเวอร์ชัน: 18, 20 และ 22 (แนะนำสำหรับโปรเจกต์ใหม่) เวอร์ชันถูกระบุในฟิลด์ engines ของไฟล์ package.json Firebase CLI จะกำหนดค่าสภาพแวดล้อมรันไทม์โดยอัตโนมัติตามเวอร์ชันที่ระบุ สิ่งสำคัญ: Firebase Cloud Functions ไม่รองรับการรันคอนเทนเนอร์ Docker ตามอำเภอใจ — สภาพแวดล้อมถูกกำหนดตายตัวโดย Google Cloud Functions

สำหรับโปรเจกต์ใหม่ แนะนำให้ใช้ Node.js 22 เนื่องจากมีการปรับแต่ง V8 ล่าสุด การรองรับโมดูล ESM ที่ดีขึ้น และการรองรับ WebSocket ในระดับแพลตฟอร์ม หากโปรเจกต์ใช้การพึ่งพาที่สร้างขึ้นสำหรับเวอร์ชัน Node โดยเฉพาะ (เช่น โมดูล C++ ดั้งเดิม) ต้องตรวจสอบความเข้ากันได้เป็นรายบุคคล — ไม่ใช่โมดูลดั้งเดิมทั้งหมดที่คอมไพล์ได้ภายใต้สภาพแวดล้อม GCF

ความแตกต่างระหว่าง Firebase Cloud Functions และ Google Cloud Functions

Firebase Cloud Functions เป็นตัวหุ้มรอบ Google Cloud Functions ที่มี Firebase SDK ติดตั้งไว้ล่วงหน้าและการรวมเข้ากับบริการ Firebase นักพัฒนาเขียนโค้ดโดยใช้ firebase-functions SDK ซึ่งให้ทริกเกอร์ที่พิมพ์แล้วสำหรับบริการ Firebase ทั้งหมด Google Cloud Functions เป็นแพลตฟอร์มระดับต่ำกว่าที่กำหนดค่าทริกเกอร์อย่างชัดเจนผ่าน Eventarc หรือ Pub/Sub

ความแตกต่างที่สำคัญ: ใน Firebase Cloud Functions ทริกเกอร์จะถูกลงทะเบียนแบบประกาศผ่าน functions.firestore.document('path').onWrite() ในขณะที่ใน Google Cloud Functions จะถูกกำหนดค่าผ่าน Eventarc พร้อมการกรองแอตทริบิวต์เหตุการณ์ Firebase Cloud Functions ยังมาพร้อมกับ Admin SDK ที่เริ่มต้นโดยอัตโนมัติด้วยข้อมูลประจำตัวบัญชีบริการของโปรเจกต์ ซึ่งให้การเข้าถึงบริการ Firebase ทั้งหมดอย่างสมบูรณ์โดยไม่ต้องตั้งค่าเพิ่มเติม

ประเภทของทริกเกอร์: รองรับเหตุการณ์ใดบ้าง

Firebase Cloud Functions รองรับทริกเกอร์ 8 ประเภท แต่ละประเภทสอดคล้องกับบริการ Firebase หรือ Google Cloud ที่เฉพาะเจาะจง ทริกเกอร์คือเงื่อนไขที่เมื่อเป็นจริงแล้วจะเรียกใช้ฟังก์ชันโดยอัตโนมัติ นักพัฒนาไม่ได้จัดการวงจรชีวิตของฟังก์ชันโดยตรง: Firebase CLI ลงทะเบียนทริกเกอร์ใน Google Cloud Eventarc และแพลตฟอร์มคลาวด์จะรันฟังก์ชันเมื่อเหตุการณ์เกิดขึ้น

ทริกเกอร์ที่ได้รับความนิยมมากที่สุดคือ ทริกเกอร์ Firestore: onWrite, onCreate, onUpdate, onDelete ทริกเกอร์เหล่านี้จะทำงานเมื่อเอกสารในคอลเล็กชัน Firestore เปลี่ยนแปลง ฟังก์ชันได้รับภาพรวมของเอกสารก่อนและหลังการเปลี่ยนแปลง ซึ่งช่วยให้สามารถเปรียบเทียบค่าและตอบสนองต่อการเปลี่ยนแปลงเฉพาะได้ ตัวอย่างเช่น เมื่อสถานะคำสั่งซื้อเปลี่ยนจาก “รอดำเนินการ” เป็น “จัดส่งแล้ว” สามารถส่งการแจ้งเตือนแบบพุชไปยังผู้ใช้

ทริกเกอร์ Authentication (onCreate, onDelete) จะทำงานเมื่อสร้างหรือลบบัญชีผู้ใช้ ใช้สำหรับเริ่มต้นข้อมูลผู้ใช้: การสร้างเอกสารผู้ใช้ใน Firestore การส่งอีเมลต้อนรับ การเขียนในการวิเคราะห์ หมายเหตุ: ฟังก์ชันไม่สามารถยกเลิกการสร้างผู้ใช้ได้ — จะดำเนินการหลังจากที่สร้างบัญชีแล้ว สำหรับการตรวจสอบล่วงหน้า ให้ใช้ Blocking Functions ที่มีใน Identity Platform

ทริกเกอร์ HTTPS และ CORS

ฟังก์ชัน HTTPS (onRequest) ช่วยให้สามารถสร้างปลายทาง REST API ที่สมบูรณ์ซึ่งเข้าถึงได้ผ่าน HTTP แตกต่างจากทริกเกอร์ที่ใช้เหตุการณ์ ฟังก์ชัน HTTPS จะถูกเรียกผ่าน URL ในรูปแบบ https://{region}-{project}.cloudfunctions.net/{functionName} สิ่งสำคัญคือต้องกำหนดค่า CORS อย่างถูกต้องหากปลายทางถูกเรียกจากเบราว์เซอร์หรือแอปพลิเคชันมือถือ Firebase SDK ไม่รวมส่วนหัว CORS โดยอัตโนมัติ — ต้องเพิ่มด้วยตนเองผ่านมิดเดิลแวร์

สำหรับไคลเอ็นต์มือถือ (Android, iOS) ไม่จำเป็นต้องใช้ CORS เนื่องจากไคลเอ็นต์ HTTP ดั้งเดิมไม่ได้ถูกจำกัดโดยนโยบาย Cross-Origin CORS เกี่ยวข้องเฉพาะกับคำขอเว็บเท่านั้น หากฟังก์ชัน HTTPS ของคุณถูกเรียกจากทั้งแอปและเว็บ ให้เพิ่มการจัดการ CORS แบบสากล: res.set('Access-Control-Allow-Origin', '*') สำหรับการพัฒนาหรือรายชื่อโดเมนที่อนุญาตสำหรับการผลิต

การกำหนดเวลาด้วย Pub/Sub และ Cloud Scheduler

สำหรับการดำเนินการเป็นระยะ (งาน cron) ให้ใช้การรวมกันของ Cloud Scheduler และ Pub/Sub Cloud Scheduler ส่งข้อความไปยังหัวข้อ Pub/Sub ตามกำหนดการ และทริกเกอร์ onPublish ของ Cloud Functions ประมวลผลข้อความนั้น Firebase CLI ไม่รองรับไวยากรณ์ cron โดยตรง — กำหนดการถูกกำหนดค่าผ่านคอนโซล Google Cloud หรือ Terraform ในรูปแบบ unix-cron: 0 3 * * * (ทุกวันเวลา 3:00 น.)

ตัวอย่างงาน: จดหมายข่าวรายวัน การทำความสะอาดข้อมูลที่ล้าสมัย การสร้างรายงาน การซิงโครไนซ์กับ API ภายนอก สิ่งสำคัญ: Cloud Scheduler เป็นบริการแบบชำระเงินของ Google Cloud (ประมาณ $2 ต่อเดือนต่องาน) การทำงานแต่ละครั้งนับเป็นการเรียกใช้ฟังก์ชันแยกต่างหากและจะถูกเรียกเก็บเงินในอัตรา Cloud Functions มาตรฐาน

วิธีเขียนและปรับใช้ฟังก์ชัน

การพัฒนา Cloud Functions เริ่มต้นด้วยการเริ่มต้นโปรเจกต์ผ่าน Firebase CLI: firebase init functions คำสั่งนี้สร้างไดเรกทอรี functions/ พร้อมเทมเพลต index.js (หรือ index.ts) ไฟล์ package.json และการกำหนดค่า TypeScript (หากเลือก) หลังจากเริ่มต้น เพียงเขียนฟังก์ชัน ส่งออกจากโมดูล และรัน firebase deploy --only functions เพื่อปรับใช้

แต่ละฟังก์ชันจะถูกลงทะเบียนโดยการเรียกใช้เมธอดทริกเกอร์ที่เหมาะสม ตัวอย่างฟังก์ชัน HTTPS: exports.helloWorld = functions.https.onRequest((req, res) => { res.send(“Hello!”); }) Firebase Functions ใช้โมเดลแบบอะซิงโครนัส: สำหรับทริกเกอร์ที่ใช้เหตุการณ์ (ไม่ใช่ HTTPS) ฟังก์ชันต้องส่งคืน Promise Firebase รอให้ Promise เสร็จสมบูรณ์ก่อนที่จะยุติคอนเทนเนอร์ หากไม่ส่งคืน Promise ฟังก์ชันอาจถูกยุติก่อนที่การดำเนินการแบบอะซิงโครนัสจะเสร็จสมบูรณ์

การพัฒนาในเครื่องทำผ่าน Firebase Emulator Suite ซึ่งรวมถึงอีมูเลเตอร์ Cloud Functions คำสั่ง firebase emulators:start เริ่มเซิร์ฟเวอร์ในเครื่องด้วยฟังก์ชันที่เข้าถึงได้ที่ http://localhost:5001 อีมูเลเตอร์รองรับการโหลดซ้ำทันทีเมื่อโค้ดเปลี่ยนแปลงและแยกจากสภาพแวดล้อมการผลิตอย่างสมบูรณ์ ทำให้สามารถทดสอบได้โดยไม่เสี่ยงต่อข้อมูลจริง

การจัดการการพึ่งพาและการกำหนดค่า

การพึ่งพา ของ Cloud Functions จัดการผ่าน package.json Firebase ติดตั้งเฉพาะการพึ่งพาสำหรับการผลิต (dependencies ไม่ใช่ devDependencies) ขนาดแพ็กเกจฟังก์ชันส่งผลต่อเวลาสตาร์ทเย็น: แนะนำให้ลดจำนวนการพึ่งพาให้เหลือน้อยที่สุด การพึ่งพา firebase-admin สำหรับ Firebase Admin SDK ติดตั้งไว้ล่วงหน้าแล้ว — ไม่จำเป็นต้องเพิ่มด้วยตนเอง

ข้อมูลที่เป็นความลับ (คีย์ API โทเค็น) ไม่ควรเก็บไว้ในโค้ดฟังก์ชัน ใช้ functions.config() สำหรับเก็บการกำหนดค่า: firebase functions:config:set stripe.key=“sk_...” ค่าจะถูกเข้ารหัสและใช้ได้ในรันไทม์ผ่าน functions.config().stripe.key สำหรับการกำหนดค่าที่เป็นอนุกรมขนาดใหญ่ ให้ใช้ Google Cloud Secret Manager

การจัดการข้อผิดพลาดและการบันทึก

การบันทึก ใน Cloud Functions ทำผ่าน console.log, console.warn และ console.error บันทึกทั้งหมดจะถูกรวบรวมโดยอัตโนมัติใน Google Cloud Logging และพร้อมใช้งานในคอนโซล Firebase (ส่วน Functions > Logs) สำหรับการบันทึกที่มีโครงสร้าง ให้ใช้ไลบรารี winston หรือ pino ซึ่งรองรับการจัดรูปแบบ JSON และระดับการบันทึก

การจัดการข้อผิดพลาด มีความสำคัญต่อความน่าเชื่อถือ: ข้อยกเว้นที่ไม่ได้รับการจัดการใน Promise จะยุติฟังก์ชันด้วยข้อผิดพลาด หลังจากนั้น Firebase จะลองใหม่โดยอัตโนมัติด้วยการหน่วงเวลาแบบเพิ่มทวีคูณ จำนวนครั้งที่ลองใหม่สามารถกำหนดค่าได้: ตั้งแต่ 0 ถึงไม่จำกัด สำหรับทริกเกอร์ที่ใช้เหตุการณ์ แนะนำให้เปิดใช้งานการลองใหม่เพื่อให้แน่ใจว่าทุกเหตุการณ์ได้รับการประมวลผลแม้ในระหว่างที่บริการภายนอกขัดข้องชั่วคราว

การสตาร์ทเย็นและการปรับขนาด

การสตาร์ทเย็น (cold start) คือความหน่วงในการเรียกใช้ฟังก์ชันครั้งแรกหลังจากช่วงที่ไม่มีการเคลื่อนไหว เมื่อคอนเทนเนอร์ที่มีโค้ดถูกโหลดและเริ่มต้นใหม่ ตามเอกสาร Firebase (2026) การสตาร์ทเย็นใช้เวลาตั้งแต่ 200 ms ถึง 2 วินาที ขึ้นอยู่กับขนาดแพ็กเกจ จำนวนการพึ่งพา และภูมิภาค สำหรับอินเทอร์เฟซผู้ใช้ ความหน่วงที่เกิน 1 วินาทีจะสังเกตเห็นได้ชัดเจนและอาจส่งผลต่อประสบการณ์ผู้ใช้

วิธีลดการสตาร์ทเย็น: ลดการพึ่งพาให้เหลือน้อยที่สุด ใช้ TypeScript ที่คอมไพล์เป็น CommonJS ลดขนาดแพ็กเกจฟังก์ชัน กำหนดจำนวนอินสแตนซ์ที่ใช้งานน้อยที่สุด Firebase Cloud Functions v2 (รุ่นที่ 2) อนุญาตให้ตั้งค่า minInstances — จำนวนคอนเทนเนอร์ที่อุ่นไว้ขั้นต่ำที่พร้อมให้บริการคำขอเสมอ การรักษาคอนเทนเนอร์ให้อุ่นไว้จะมีค่าใช้จ่ายสำหรับเวลาว่าง

การปรับขนาด ของ Cloud Functions เกิดขึ้นโดยอัตโนมัติ: เมื่อปริมาณคำขอเพิ่มขึ้น Firebase จะสร้างคอนเทนเนอร์ใหม่ โดยค่าเริ่มต้น จำนวนอินสแตนซ์พร้อมกันสูงสุดคือ 3000 (โควต้าโปรเจกต์ Google Cloud) แต่ละอินสแตนซ์จัดการหนึ่งคำขอในแต่ละครั้ง หากฟังก์ชันทำงานเร็ว (น้อยกว่า 100 ms) หนึ่งอินสแตนซ์สามารถจัดการได้ถึง 10 คำขอต่อวินาที ทำให้มีปริมาณงานสูงสุดถึง 30,000 คำขอต่อวินาทีต่อโปรเจกต์

การกำหนดค่า minInstances และ maxInstances

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

การกำหนดค่าทำได้ในโค้ด: functions.runWith({ minInstances: 1, maxInstances: 10 }) สิ่งสำคัญ: minInstances เพิ่มต้นทุนเนื่องจากคอนเทนเนอร์ทำงานอย่างต่อเนื่อง สำหรับโปรเจกต์ทดสอบ ควรปิดการใช้งาน minInstances สำหรับการผลิต แนะนำให้ใช้ minInstances สำหรับฟังก์ชัน HTTPS สาธารณะทั้งหมดและ 0 สำหรับทริกเกอร์ที่ใช้เหตุการณ์ซึ่งความหน่วง 1 วินาทีไม่สำคัญ

ภูมิภาคสำหรับการปรับใช้

ภูมิภาคสำหรับการปรับใช้ ส่งผลต่อความหน่วงไปยังผู้ใช้ปลายทางและต้นทุนของการรับส่งข้อมูลขาออก Firebase Cloud Functions พร้อมใช้งานในมากกว่า 30 ภูมิภาคของ Google Cloud สำหรับแอปพลิเคชันมือถือ ให้เลือกภูมิภาคที่ใกล้กับกลุ่มเป้าหมายของคุณมากที่สุด: us-central1 สำหรับอเมริกา europe-west1 สำหรับยุโรป asia-east2 สำหรับเอเชีย ไม่สามารถเปลี่ยนภูมิภาคหลังจากปรับใช้ได้โดยไม่ต้องปรับใช้ฟังก์ชันใหม่

การเปลี่ยนภูมิภาคทำได้ผ่านพารามิเตอร์ region ในโค้ด: functions.region('europe-west1') ฟังก์ชันทั้งหมดในไฟล์เดียวกันสามารถมีภูมิภาคที่แตกต่างกัน สำหรับโปรเจกต์ระดับโลก แนะนำให้ปรับใช้ฟังก์ชันในหลายภูมิภาคและใช้ Cloud Load Balancing เพื่อกระจายปริมาณการใช้งาน แม้ว่าสำหรับแอปพลิเคชันมือถือส่วนใหญ่ ภูมิภาคเดียวก็เพียงพอหากเลือกอย่างถูกต้อง

ตัวอย่างโค้ดสำหรับ Firebase Cloud Functions

มาดูตัวอย่างที่ใช้งานได้จริงของ Cloud Functions ใน TypeScript กัน โค้ดใช้ Firebase Functions SDK v2 (รุ่นที่ 2) ด้วยไวยากรณ์โมดูล ES ตัวอย่างรวมถึงการจัดการเหตุการณ์การสร้างผู้ใช้ การสร้างภาพขนาดย่อเมื่ออัปโหลดรูปภาพ และปลายทาง HTTPS อย่างง่ายสำหรับ REST API ฟังก์ชันทั้งหมดเป็นแบบอะซิงโครนัสและส่งคืน Promise สำหรับการยุติคอนเทนเนอร์ที่เหมาะสม

ก่อนรัน ตรวจสอบให้แน่ใจว่า Firebase CLI อัปเดตเป็นเวอร์ชัน 13+ แล้ว: npm install -g firebase-tools ฟังก์ชัน v2 จำเป็นต้องมีแผนราคา Blaze การเริ่มต้น: firebase init functions โดยเลือก TypeScript

การจัดการการลงทะเบียนผู้ใช้

ตัวอย่างแรก — การสร้างเอกสาร ใน Firestore เมื่อผู้ใช้ใหม่ลงทะเบียน ฟังก์ชันถูกเรียกโดยเหตุการณ์ auth.user().onCreate และเขียนโปรไฟล์พื้นฐานลงในคอลเล็กชัน users/{uid} ซึ่งช่วยให้แน่ใจว่าผู้ใช้ที่ลงทะเบียนแต่ละคนมีเอกสารที่มีฟิลด์ที่จำเป็น

import * as functions from "firebase-functions"
import * as admin from "firebase-admin"

admin.initializeApp()

export const createUserProfile = functions.auth
    .user()
    .onCreate(async (user) => {
        const profile = {
            email: user.email,
            displayName: user.displayName ?? "User",
            createdAt: admin.firestore.Timestamp.now(),
            role: "free",
            avatarUrl: null,
        }

        await admin.firestore()
            .collection("users")
            .doc(user.uid)
            .set(profile)

        console.log(`Profile created for ${user.uid}`)
    })

ฟังก์ชัน createUserProfile เป็นแบบอะซิงโครนัส — ส่งคืน Promise ที่ Firebase รอก่อนที่จะยุติ หากการเขียนไปยัง Firestore ล้มเหลว (เช่น เนื่องจากสิทธิ์ไม่เพียงพอ) ฟังก์ชันจะถูกลองใหม่โดยอัตโนมัติ (หากเปิดใช้งานการลองใหม่) ฟิลด์ role ที่มีค่า “free” ช่วยให้สามารถใช้ข้อจำกัดของแผนฟรีได้โดยตรงใน Security Rules ของ Firestore โดยการเปรียบเทียบ resource.data.role กับระดับการเข้าถึงที่ต้องการ

การสร้างภาพขนาดย่อเมื่ออัปโหลดรูปภาพ

ตัวอย่างที่สอง — ทริกเกอร์ Storage สำหรับสร้างภาพขนาดย่อโดยอัตโนมัติหลังจากอัปโหลดรูปภาพ ฟังก์ชันสร้างสำเนาที่ลดขนาดลง 200×200 พิกเซลและบันทึกในเส้นทางของไฟล์ต้นฉบับด้วยคำนำหน้า thumb_ การประมวลผลภาพใช้ไลบรารี sharp ซึ่งรองรับรูปแบบทั่วไปทั้งหมดและทำงานในสภาพแวดล้อม Node.js โดยไม่ต้องพึ่งพาระบบ

import * as path from "path"
import * as os from "os"
import * as sharp from "sharp"

export const generateThumbnail = functions.storage
    .object()
    .onFinalize(async (object) => {
        if (!object.contentType?.startsWith("image/")) return

        const filePath = object.name!
        const thumbPath = filePath.replace(
            /(\.\w+)$/, "_thumb$1"
        )

        const bucket = admin.storage().bucket()
        const tempDir = os.tmpdir()
        const tempFile = path.join(tempDir, path.basename(filePath))

        await bucket.file(filePath).download({ destination: tempFile })
        await sharp(tempFile)
            .resize(200, 200, { fit: "cover" })
            .toFile(tempFile.replace(/(\.\w+)$/, "_thumb$1"))

        await bucket.upload(tempFile.replace(
            /(\.\w+)$/, "_thumb$1"
        ), { destination: thumbPath })
    })

ฟังก์ชัน generateThumbnail ตรวจสอบ Content-Type ของออบเจกต์และละเว้นที่ไม่ใช่รูปภาพ ซึ่งช่วยประหยัดทรัพยากร หากต้องการใช้ sharp ต้องเพิ่มการพึ่งพาใน package.json ภาพขนาดย่อถูกสร้างขึ้นด้วยพารามิเตอร์ fit: “cover” ซึ่งครอบตัดภาพจากกึ่งกลางเป็นสี่เหลี่ยมจัตุรัส 200×200 พิกเซล หลังจากสร้างแล้ว ภาพขนาดย่อจะถูกอัปโหลดกลับไปยังบักเก็ตเดียวกันด้วยชื่อที่ปรับเปลี่ยน

ปลายทาง HTTPS สำหรับ API สาธารณะ

ตัวอย่างที่สาม — ฟังก์ชัน HTTPS ที่ใช้ปลายทาง REST API สำหรับตรวจสอบสถานะเซิร์ฟเวอร์ ฟังก์ชันรับคำขอ GET และส่งคืน JSON พร้อมข้อมูลเกี่ยวกับสถานะของบริการ Firebase ที่เชื่อมต่อกับโปรเจกต์ ปลายทางนี้มีประโยชน์สำหรับการตรวจสอบและระบบภายนอกที่ต้องการตรวจสอบความพร้อมของแบ็กเอนด์ก่อนส่งข้อมูล

import * as express from "express"

const app = express.Router()

app.get("/status", async (req, res) => {
    try {
        const db = admin.firestore()
        await db.collection("_health").doc("check").get()
        res.json({ status: "ok", timestamp: Date.now() })
    } catch (error) {
        res.status(503).json({ status: "error", message: error })
    }
})

export const api = functions.https.onRequest(app)

ฟังก์ชัน api ใช้ express Router สำหรับการกำหนดเส้นทาง ซึ่งสะดวกเมื่อสร้างปลายทางหลายแห่งในฟังก์ชันเดียว การตรวจสอบสุขภาพเขียนไปยัง Firestore ในคอลเล็กชัน _health ซึ่งช่วยให้ตรวจสอบความพร้อมของ Firestore พร้อมกันได้ สำหรับการผลิต แนะนำให้เพิ่มการตรวจสอบสิทธิ์คำขอผ่านคีย์ API หรือโทเค็น Firebase Auth เพื่อป้องกันการใช้งานปลายทางสาธารณะในทางที่ผิด

กรณีการใช้งานทั่วไปในแอปพลิเคชันมือถือ

Cloud Functions มักใช้สำหรับงานที่ไม่สามารถหรือไม่ควรทำบนไคลเอ็นต์: การส่งการแจ้งเตือนแบบพุช การสร้างตัวอย่างรูปภาพที่อัปโหลด การรวมเข้ากับระบบชำระเงินภายนอก การกลั่นกรองเนื้อหา การซิงโครไนซ์ข้อมูลระหว่าง Firebase และบริการของบุคคลที่สาม โมเดลไร้เซิร์ฟเวอร์ทำให้งานเหล่านี้คุ้มค่า: คุณจ่ายเฉพาะเวลาดำเนินการโค้ดจริงเท่านั้น

การรวมระบบชำระเงิน เป็นสถานการณ์ทั่วไปสำหรับแอปที่มีการซื้อในแอป Cloud Functions รับเว็บฮุคจากผู้ให้บริการชำระเงิน (Stripe, PayPal) ตรวจสอบลายเซ็นคำขอ อัปเดตสถานะการสมัครสมาชิกใน Firestore และส่งการยืนยันไปยังผู้ใช้ โค้ดทั้งหมดทำงานบนเซิร์ฟเวอร์โดยไม่มีความเสี่ยงในการปลอมแปลงข้อมูลบนไคลเอ็นต์ ตามเอกสาร Stripe (2026) การประมวลผลเว็บฮุคใช้เวลาน้อยกว่า 500 ms

การกลั่นกรองเนื้อหาอัจฉริยะ ใช้ทริกเกอร์ Storage ของ Cloud Function เพื่อตรวจสอบรูปภาพที่อัปโหลดโดยอัตโนมัติผ่าน Google Cloud Vision API ฟังก์ชันส่งรูปภาพไปยัง Vision API เพื่อตรวจจับเนื้อหาที่ไม่ปลอดภัย (ความรุนแรง เนื้อหาสำหรับผู้ใหญ่) และหากเกินเกณฑ์ จะลบไฟล์และแจ้งผู้ดูแลระบบ สถานการณ์นี้สำคัญสำหรับแอปพลิเคชัน UGC ที่มีแกลเลอรีผู้ใช้

การรวมข้อมูล — Cloud Functions เป็นตัวแทนของตัวนับ Firebase Realtime Database แทนที่จะอ่านและเขียนตัวนับบนไคลเอ็นต์ (ซึ่งทำให้เกิดสภาวะการแข่งขัน) ให้ใช้ทริกเกอร์ onWrite ของ Firestore สำหรับการอัปเดตแบบอะตอมมิกของฟิลด์ที่รวม ตัวอย่างเช่น ฟังก์ชันนับจำนวนไลค์ของโพสต์ทุกครั้งที่มีการเพิ่มหรือลบเอกสารในคอลเล็กชันย่อย /posts/{postId}/likes/{userId} และอัปเดตฟิลด์ likesCount ในเอกสารหลัก