Google Firestore เปิดตัว region ใหม่ asia-southeast3 (Bangkok) อย่างเป็นทางการแล้ว 🎉
บอกเลยว่างานนี้ถูกใจคนทำแอปในประเทศไทยสุดๆ เพราะ data อยู่ใกล้ผู้ใช้มากขึ้นกว่าเดิม

ลองไปไล่ดูรายละเอียดมา พบว่ามี ข้อดีหลักๆ อยู่ 2 เรื่องที่เห็นผลชัดมาก

อย่างแรกคือ ความเร็ว — สำหรับผู้ใช้งานในไทย latency ลดลงอย่างเห็นได้ชัด แอปตอบสนองไวขึ้นแบบรู้สึกได้ทันที

อย่างที่สองคือ เรื่องราคา — ค่าใช้จ่ายถูกลงกว่าการใช้ region asia-southeast1 (Singapore) พอสมควร โดยเฉพาะสำหรับระบบที่มี traffic เยอะหรือใช้งาน Firestore หนักๆ ลองดูราคาเปรียบเทียบที่ด้านล่างนี้ได้เลยครับ

asia-southeast1 (Singapore)
Document reads² $0.0369 per 100,000 documents
Document writes $0.1107 per 100,000 documents
Document deletes $0.0123 per 100,000 documents
Stored data $0.1846 GiB/month

asia-southeast3 (Bangkok)
Document reads² $0.0315 per 100,000 documents
Document writes $0.0945 per 100,000 documents
Document deletes $0.0105 per 100,000 documents
Stored data $0.1575 GiB/month

เจอข้อดีขนาดนี้แล้ว จะรออะไรอยู่ล่ะค้าบ 😄
ถึงเวลาย้าย Firestore มาใช้ region ใหม่ Bangkok (asia-southeast3) กันได้แล้ว

การย้ายครั้งนี้ต้องทำผ่าน Google Cloud Console โดยตรงนะครับ เพราะ Firestore ยังไม่สามารถเปลี่ยน region ของ database เดิมได้แบบคลิกเดียว จำเป็นต้องมีขั้นตอนวางแผนและย้ายข้อมูลอย่างถูกวิธี แต่ข่าวดีคือ ทำได้ไม่ยาก และสามารถจัดการให้ downtime ต่ำมาก หรือแทบไม่มีเลย

เริ่มกันเลย

1. เข้าไปที่ Google Cloud Console
2. ก่อนอื่น เราต้องเตรียม ที่เก็บไฟล์สำหรับ export ข้อมูล ก่อนนะครับ ให้เข้าไปที่ Google Cloud Storage แล้วสร้าง Bucket ใหม่ ขึ้นมา
   ในขั้นตอนการสร้าง Bucket ให้ตั้งค่า Location type เป็นแบบ Multi-region และเลือก region เป็น Asia
   เหตุผลที่ต้องเลือกแบบนี้ เพราะเราจะทำการย้ายข้อมูล ข้าม region (จาก Singapore ไป Bangkok) ซึ่ง Cloud Storage แบบ Multi-region จะรองรับการ export/import ข้อมูลได้ไม่มีปัญหา

เมื่อสร้าง Bucket เสร็จเรียบร้อยแล้ว เราก็พร้อมสำหรับขั้นตอนถัดไปในการย้าย Firestore ข้อมูลครับ 🚀

3. ต่อมาให้เข้าไปที่ product firestore ถ้าหาเมนูไม่เจอให้ search เอาได้เลยค้าบ

4. เข้ามาแล้วจะเจอ database firestore ตัว default ที่เรามีอยู่แล้ว จะสามารถดูได้เลยว่า database เดิมเรา อยู่ที่ region ไหน

5. สร้าง Firestore database ใหม่ โดยการคลิกปุ่ม Create Firestore database ทำการกำหนด database-id ตั้งชื่อตามใจเราเลย แล้วเลือก region เป็น asia-southeast3 (Bangkok)

6. สร้าง database เสร็จแล้ว ก็จะได้ database มา 2 database แล้วค้าบ ลองตรวจสอบ region ให้เรียบร้อยว่าถูกต้องแล้ว

7. ต่อมาให้เราคลิกเลือกที่ database ตัวหลักที่เราต้องการ export data ออกมา ในที่นี้คือ database (default)

8. เมื่อเข้ามาที่ database ตัวหลักแล้วให้เข้าไปที่เมนู Import/Export

9. คลิกที่ปุ่ม Export แล้วทำการเลือก Bucket ที่เราสร้างไว้ในขั้นตอนที่ 2 แล้วคลิกปุ่ม Select แล้วคลิก Export เพื่อเริ่มทำงานได้เลย

10. เมื่อ export เสร็จเรียบร้อยแล้ว ก็จะมีรายการขึ้นมาให้เห็นบนหน้า Import/Export ครับ โดยจะมีการบอกด้วยว่า export นี้มี Collection อะไรบ้าง ในที่นี้คือ All Collections

11. จากนั้นให้เรากลับไปที่ All database แล้วเข้าไปที่ database ตัวที่เราสร้างใหม่ ที่อยู่ region asia-southeast3 จะพบ database เปล่าๆ แบบนี้

12. ให้คลิกเข้าไปที่เมนู Import/Export แล้วคลิกที่ปุ่ม Import

13. กดปุ่ม Browse แล้วทำการเลือกไฟล์ที่เรา export ไว้จากขั้นตอนก่อนหน้า แล้วทำการกดปุ่ม Select แล้ว กดปุ่ม Import เพื่อเริ่ม Import database

14. เมื่อ import เสร็จแล้วก็จะขึ้นหน้าตาแบบนี้ครับ

15. ทดสอบเข้าที่เมนู Firestore Studio ก็จะพบข้อมูลทั้งหมดได้ถูก import เรียบร้อยแล้ววว \(^o^)/

เพียงเท่านี้ก็สามารถย้าย Firestore Database มาใช้งานใน Region ใหม่ (Bangkok) ได้เรียบร้อยแล้วครับ
ขั้นตอนไม่ได้ยุ่งยากอย่างที่หลายคนคิด แค่เตรียม Cloud Storage Bucket สำหรับรองรับไฟล์ จากนั้นทำการ export และ import ข้อมูล ก็จบกระบวนการย้ายได้เลย

ขอฝากข้อมูลเพิ่มเติมเรื่อง ค่าใช้จ่าย นิดหนึ่งนะครับ
ในการ import/export ข้อมูล Google จะคิดค่าใช้จ่ายตาม rates เดียวกับการอ่านและเขียนเอกสาร (document reads & writes) ดังนั้นก่อนย้าย แนะนำให้ประเมินปริมาณข้อมูลคร่าวๆ เพื่อคุมงบประมาณให้เหมาะสม

หวังว่าบทความนี้จะช่วยให้การย้าย Firestore มาใช้ Bangkok Region เป็นเรื่องที่ง่ายและตัดสินใจได้เร็วขึ้น ขอบคุณมากครับ 🙏

Firestore เปิด Region ใหม่ Bangkok แล้ว! ถึงเวลาย้ายระบบมาใกล้ผู้ใช้ไทย was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

เมื่อเดือนก่อนจู่ๆ ก็พบว่าค่าใช้จ่าย Google Cloud เพิ่มขึ้นจากเดือนก่อนค่อนข้างมาก ทั้งที่ feature ใหม่ก็ไม่ได้ปล่อย ระบบก็ไม่ได้ scale ผู้ใช้แบบก้าวกระโดด

พอเปิด Billing Report ดูแบบจริงจัง ก็เริ่มเห็นตัวเลขแปลกๆ โผล่ขึ้นมาในหมวด Cloud Storage

ไล่ breakdown ต่อไปเรื่อยๆ จนสุดท้ายเจอต้นตอว่า…

ค่าใช้จ่ายส่วนใหญ่เกิดจาก Traffic การเรียกไฟล์ Video
ที่ User upload ไว้บน Firebase Storage 😫

ทั้งที่ video เหล่านี้:

• ไม่ได้เปลี่ยนไฟล์
• ไม่ได้ถูกแก้ไข
• แต่ถูกเปิดดูซ้ำๆ จากหลายหน้า หลาย session

และนี่แหละครับ คือที่มาของบทความนี้ เพื่อมาเล่าสิ่งที่ผมเจอ + สิ่งที่แก้ เผื่อใครกำลังเจอสถานการณ์คล้ายๆ กันจะได้ไม่ต้องเสียค่าเรียนเหมือนเรา 😅

มาทำความเข้าใจก่อนว่า ค่าใช้จ่ายของ Cloud Storage มาจากไหน

หลายคน (รวมถึงผมในตอนแรก) มักจะเข้าใจว่า Cloud Storage = ค่าฝากไฟล์
แต่จริงๆ แล้ว ค่าใช้จ่ายหลักๆ ของ Cloud Storage มีอยู่ 3 ส่วน

1. Storage (ค่าฝากไฟล์)

อันนี้เข้าใจง่ายที่สุด

• เก็บไฟล์กี่ GB
• เก็บนานแค่ไหน

ส่วนนี้มัก ไม่ใช่ตัวปัญหา เพราะไฟล์ video ต่อให้หลาย GB ถ้า user ไม่เยอะ ก็ยังไม่แรงมาก

2. Operations (ค่าการอ่าน / เขียน)

เช่น:

• Upload
• Download
• List file

โดยปกติค่าใช้จ่ายส่วนนี้ก็ยังไม่สูงมาก ถ้าเทียบกับสิ่งถัดไป 👇

3. Network Data Transfer (ตัวร้ายเงียบ 😈)

นี่แหละครับ… ตัวที่ทำให้บิลพุ่งแบบไม่รู้ตัว

เพราะทุกครั้งที่ User เรียกไฟล์จากหน้าเว็บ จะเกิด:

Data transfer ออกจาก Cloud โดย มัน คิดเงินตามปริมาณข้อมูลที่ส่งออกไป

โดยสิ่งที่สำคัญคือมัน

⚠️ ไม่สนใจว่าไฟล์นั้นจะเคยโหลดไปแล้วหรือยัง
⚠️ ไม่สนใจว่าเป็นไฟล์เดิมหรือไฟล์ใหม่

เรียกได้ว่า โหลด = จ่าย, refresh ที ก็จ่ายที ไม่จบไม่สิ้น 😢

ลองนึกภาพง่ายๆ ถ้าเรามี:

• Video ขนาด 20 MB
• User เปิดดู 1 video
• เปิดซ้ำ 5 ครั้ง

เท่ากับ โหลด ไป = 20MB x 5 = 100MB นี่แค่ 1 user ถ้าเป็น 1,000 user จะเท่ากับ 100,000MB หรือ 100GB กันเลยทีเดียว
โดยค่าใช้จ่ายในส่วน data transfer จะประมาณ $0.08–$0.12 / GB ถ้าเอา 100 GB มาคำนวณ จะเสียค่าใช้จ่ายประมาณ $8 เลยทีเดียว

การใช้งานจริงจะมากกว่า 1,000 user ไปอีกเยอะ ทำให้ค่าใช้จ่ายบานตะไท 🤢

เริ่ม Tuning Firebase Storage

โดยโจทย์ของผมคือ “User ยังต้องสามารถเรียกดูไฟล์ Video ใน Storage ซ้ำๆ ได้” และ “ยังไม่อยากรื้อระบบ” เพราะจะกระทบกับหลาย service

ซึ่งพอเราดูแล้ว “ปัญหาเกิดจาก User เรียกดูไฟล์ Video เดิมๆ และ ถูกเปิดซ้ำจากหลายหน้า” ถ้าเราให้ User Cache ไฟล์ Video ไว้ที่ Client เอง จะแก้ปัญหาตรงนี้ไปได้เลย เราจึงเลือกทำในสิ่งที่เรียกว่า Cache-Control

Cache-Control

Cache-Control คือ HTTP Header ที่ใช้บอก browser, CDN และ proxy ว่า “ไฟล์นี้ cache ได้ไหม cache ได้นานแค่ไหน และต้องโหลดใหม่ตอนไหน” ซึ่งไม่ได้เป็นความรู้ใหม่เลย เป็นสิ่งที่เราเคยทำมานมนานแล้ว แต่เราอาจจะลืมสิ่งนี้ไป
และพอไปค้นมาแล้วพบว่า Firebase Storage สามารถกำหนด Cache Control ได้หลายวิธีเลย

วิธีที่ 1 : ปรับ Metadata บน Google Cloud Console

วิธีเป็นการแก้ไขแบบ Manual ทีละไฟล์ วิธีการคือ

1. เข้าไปที่ Cloud Storage
2. เข้าไปที่ Bucket ที่เก็บไฟล์ที่ต้องการแก้ไข
3. คลิกที่เมนู 3 dots ด้านหลังไฟล์ แล้วเลือก Edit metadata
4. แก้ไขตรงส่วน Cache-Control โดยโครงสร้างการกำหนดค่าจะเป็นประมาณนี้

Cache-Control: public,max-age=31536000,immutable

แบ่งเป็นส่วนๆ แบบนี้

1. public vs private

คือการกำหนดสิทธในการ cache ไฟล์นั้นๆ มี 2 ประเภท
public : ไฟล์นี้ใช้กับทุกคนเหมือนกัน
private: ไฟล์นี้เฉพาะบุคคล เช่น หลังจาก login

2. max-age — อายุของ cache

ตัวนี้จะเป็นการกำหนดว่า สามารถใช้ไฟล์จาก cache ได้ โดยไม่ต้องถาม server ใหม่นานขนาดไหน โดยหน่วยที่กำหนดเป็น วินาที เช่น max-age=31536000 ก็คือเป็นนาน 1 ปีเลย

3. immutable vs must-revalidate

คือการกำหนดว่า ถ้า max-age หมดอายุแล้ว จะต้องทำอย่างไรต่อ โดย
immutable : คือ การบอก browser ว่าไฟล์นี้ “ไม่มีทางเปลี่ยน” ประเภทนี้จะเหมาะกับไฟล์ที่ไม่เปลี่ยนแน่ๆ หรือ ถ้าเปลี่ยนก็จะเปลี่ยนชื่อไฟล์ไปเลย
must-revalidate : คือ การบอก browser ว่าให้กลับมาโหลดไฟล์ใหม่ที่ server

วิธีที่ 2 : ตั้งค่า Cache-Control ตอน Upload

วิธีนี้เป็นวิธีที่แนะนำที่สุด เพราะกำหนดตั้งแต่ตอน Upload ไฟล์เลย เราสามารถกำหนดได้เลยว่าไฟล์ประเภทไหนควรจะตั้ง Cache Control แบบไหน โดยใส่ metadata ตอน upload file ได้เลยครับ ตัวอย่าง

await bucket.upload(filePath, {
  destination: destinationPath,
  metadata: {
    contentType: 'video/mp4',
    cacheControl: 'public, max-age=86400'
  }
})

วิธีที่ 3: แก้ไข Cache-Control ด้วย gsutil

วิธีนี้จะเหมาะกับกรณีที่เรามีไฟล์เก่าๆ อยู่เยอะ และต้องการแก้ไขในทีเดียว โดยไม่กระทบไฟล์ และไม่ต้องอัปโหลดใหม่

โดยเจ้า gsutil คือ CLI สำหรับจัดการ Google Cloud Storage นั่นเองครับ โดยให้เราเปิด shell ใน Google Cloud Console แล้วใช้คำสั่งประมาณนี้ครับ

gsutil -m setmeta \
  -h "Cache-Control:public,max-age=86400" \
  gs://your-bucket/videos/**

อธิบาย:

• -m → ทำงานแบบ parallel (เร็วขึ้น)
• setmeta → แก้ metadata
• Cache-Control → header ที่ต้องการ
• gs://your-bucket/videos/** → ครอบคลุมไฟล์ทั้งหมดใน path videos ใน bucket นี้

ส่งท้าย

การใช้ Cloud ทำให้เราสร้างระบบได้เร็ว scale ได้ง่าย และไม่ต้องปวดหัวกับ infrastructure เหมือนสมัยก่อน แต่สิ่งหนึ่งที่ต้องระวังเสมอคือ ค่าใช้จ่าย เพราะ Cloud ส่วนใหญ่ คิดเงินตามการใช้งานจริง

หวังว่าบทความนี้จะช่วยให้ใครที่ใช้ Firebase Storage ลองกลับไปดูระบบของตัวเอง แล้วลดค่าใช้จ่ายที่ไม่จำเป็นลงได้บ้างนะครับ 🙂

ขอบคุณที่อ่านจนจบครับ 🙏

Tuning Firebase Storage ให้เร็วขึ้น ⚡ และค่าใช้จ่ายลดลง 💸 was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

Firebase Data Connect บริการที่ทำให้ Firebase เชื่อมต่อกับ PostgresSQL ได้แบบง่ายๆ

จากบทความที่แล้ว เราได้พูดถึง Firebase Data Connect บริการที่รองรับ Relational Database ตัวแรกของ Firebase โดยเบื้องหลังคือ PostgresSQL บน GCP Cloud บทความนี้เราจะมาเจาะลึกในความสามารถอีกอย่างที่ Firebase Data Connect คิดมาให้แล้ว สำหรับการทำงานกับแอปในยุค AI Era

เข้าใจ Vector embeddings

Vector คือ ชุดตัวเลขที่เรียงลำดับกัน ที่เราน่าจะรู้จักกันดีคือ พิกัดทางภูมิศาสตร์ ซึ่งจะเป็นเวกเตอร์ 2 มิติ ที่ประกอบด้วย lattitude, longitude เช่น 37.751 , -97.822 แต่เวกเตอร์ไม่จำกัดแค่ 2 หรือ 3 มิติ อาจมีหลายสิบ หลายร้อย หรือหลายพันมิติก็ได้

Embeddings คือ การแปลงข้อมูลให้เป็นเวกเตอร์ เพื่อให้คอมพิวเตอร์สามารถเข้าใจและประมวลผลได้ เช่น การแทนกาแฟด้วยเวกเตอร์ 3 มิติ โดยแต่ละมิติแทนปริมาณของกาแฟ นม และน้ำตาล ซึ่งอเมริกาโน่ อาจจะมีแค่กาแฟ ไม่มีน้ำตาลและนม 1.0,0.0,0.0 แต่คาราเมลมัคคิอาโต้ มีทั้ง กาแฟ นม น้ำตาล 1.0,0.8,0.5อย่างนี้ก็จะทำให้เราวิเคราะห์และเปรียบเทียบประเภทของกาแฟต่างๆ ได้ง่ายขึ้นนั่นเอง

หรืออย่างบอร์ดเกม จริงๆอาจจะมีได้หลายมิติ ไม่ว่าจะเป็น ความสนุก ความยาก ระยะเวลาการเล่น จำนวนผู้เล่น เพื่อทำให้เห็นภาพง่ายขึ้นเราจะดู ความสนุก และ ความยาก โดยเราจะนำแต่ละเกมมา plot เป็นกราฟ ซึ่งตำแหน่งของมันก็คือ vector ที่เราเรียกกันนั่นแหละ เหมือนที่เราเรียนเรื่องทฤษฏีกราฟตอนม.ปลายเลย

ทีนี้เราก็สามารถเอาค่านี้ มาคำนวณว่าเหมือนหรือต่างด้วยคำนวณระยะห่างระหว่างจุดสองจุดบนกราฟ ลองจินตนาการว่า user อยากอยากได้เกมครอบครัวคล้ายๆกับ uno ที่สนุก เล่นไม่ยากมาก ทีนี้เราก็จะเอาค่า vector คำนวณว่าอันไหนใกล้เคียง uno สุด เป็นต้น

Vector similarity search

การทำ Vector similarity search คือการนำ embeddings มาเทียบกันว่าอันไหนมีความใกล้เคียงกันมากที่สุด โดยเริ่มต้นเลยเราต้องนำข้อมูลของเรา ไม่ว่าจะอยู่ในรูปแบบ text, image, audio, file ไปแปลงเป็น vector embeddings ก่อน แล้วเก็บไว้ใน database ที่รองรับการเก็บข้อมูลในรูปแบบ vector

พอ user ส่ง query เข้ามา เราก็จะต้องเอา query ที่เป็น text แปลงเป็น vector embeddings เพื่อที่เราจะสามารถนำ vector embeddings นั้นไปเปรียบเทียบกับ vector embeddings ที่เก็บเอาไว้ใน database เพื่อหาข้อมูลที่ใกล้เคียงกัน แล้วโยนผลลัพธ์ กลับออกไปให้ user

อ่านมาถึงตรงนี้ ทุกคนอาจจะสงสัยว่า แล้วเราจะแปลงข้อมูลที่อยู่ใน Database ของเราให้เป็น vector embeddings ได้ยังไง? พอแปลงแล้วเราจะเอาข้อมูลไปเก็บไว้ที่ไหนได้บ้าง? บอกเลย Firebase Data Connect คิดมาให้แล้ว~

ทำงานกับข้อมูลแบบ vector ใน Firebase Data Connect

กลับไปที่แอปบอร์ดเกมของเรา สมมุติว่าเราจะเพิ่มฟีเจอร์สำหรับค้นหาแบบ vector similarity search กระบวนท่าจะถูกแบ่งเป็น 4 ขั้นตอน ดังนี้

1. เพิ่ม schema ที่ทำให้รองรับการเก็บข้อมูลแบบ Vector
2. เพิ่ม mutation ในการเขียนข้อมูลที่เป็น Vector
3. เขียน query ให้รองรับการค้นหาด้วย Vector

1. เพิ่ม schema ที่ทำให้รองรับการเก็บข้อมูลแบบ Vector

ข้อดีของ PostgresSQL คือ มันสามารถเก็บข้อมูล Vector ได้ โดยเราสามารถกำหนดชนิดของข้อมูลเป็น Vectorในไฟล์ schema ได้เลย

# ไฟล์ schema.gql
type Game @table {
  title: String!
  description: String!
  descriptionEmbedding: Vector
}

2. เพิ่ม mutation ในการเขียนข้อมูลที่เป็น Vector

หลังจากกำหนด schema ก็ได้เวลาเขียนมูลลงใน database

2.1 มี embedding model ที่ใช้อยู่แล้ว

กรณีที่เราอาจจะมี embedding model ที่ใช้อยู่แล้ว เช่น เราอาจจะใช้ OpenAIs text embedding models หรือ model ที่บริษัททำเอง เราสามารถแปลงข้อมูลให้เป็น vector embeddings ให้เรียบร้อย แล้วเขียนไฟล์ mutation เพื่อโยน embeddings ไปเก็บไว้ใน database เฉยๆก็ได้ ตามโค้ดตัวอย่างด้านล่าง

mutation CreateNewGame(
  $title: String!, 
  $description: String!, 
  $descriptionEmbedding: Vector!
) {
  game_insert(data: {
    title: $title,
    description: $description,
    descriptionEmbedding: $descriptionEmbedding
  })
}

2.2 ใช้ Vertex AI vector embeddings จาก Firebase Data Connect

ถ้าไม่อยากจะไปเรียก API เพื่อทำ embedding เอง Firebase ก็มี wrapper function ที่ช่วยให้เราทำ embedding ได้แบบง่ายๆ โดยเราสามารถใช้คำสั่ง _embed และกำหนด embedding model ที่ต้องการ เพื่อให้มันสร้าง embedding ให้แบบอัตโนมัติ ซึ่งตัว model ที่รองรับก็จะเป็น embedding models จาก VertexAI ทั้งหมด

mutation CreateNewGame(
  $title: String!, 
  $description: String!, 
  $descriptionEmbedding: Vector!
) {
  game_insert(data: {
    title: $title,
    description: $description,
    descriptionEmbedding_embed: {
      model: "textembedding-gecko@003"
      text: $description
    }
  })
}

ในตัวอย่างเราทำการ embed ตัว description ที่เป็น text ให้เป็น embeddings ด้วย textembedding-gecko@003

3. เขียน query ให้รองรับการค้นหาด้วย Vector

หลังจากทำการเก็บข้อมูล vector แล้ว เรามาเขียน query เพื่อทำการค้นหาแบบ vector similarity search กัน

query SearchSimilarContent($query: String!, $limit: Int = 3)
@auth(level: PUBLIC) {
  games_descriptionEmbedding_similarity(
    compare_embed: {
      model: "textembedding-gecko-multilingual@001"
      text: $query
    }
    method: L2
    within: 2
    limit: $limit
  ) {
    ...DisplayGame
  }
}

Firebase Data Connect จะสร้างฟังก์ชั่น similarity สำหรับทุกๆ field ที่เป็น vector โดยเราสามารถใช้ฟังก์ชั่นนี้ในการทำ similarity search ได้เลย เช่น games_descriptionEmbedding_similarity

ในส่วนของการแปลง query ที่ user พิมพ์เข้ามาให้เป็น embeddings เราสามารถเรียก compare_embed เพื่อให้ Firebase Data Connect แปลง query string เป็น embeddings ให้เราได้เลย โดยเราสามารถเลือก model จาก VertexAI ได้เช่นกัน ในที่นี้เราใช้ textembedding-gecko-multilingual@001 เพื่อให้การค้นหาของเรารองรับหลากหลายภาษา (multilingual) ได้

เราสามารถทำการทดสอบ endpoints ด้วยการใช้ VSCode Extensions (ดูวิธีในบทความที่แล้ว) โดยจะเห็นว่าเราระบุ query เป็นภาษาไทยยาวเป็นกิโล แต่ก็ยังคงได้ผลลัพธ์จาก database ที่เราเก็บไว้เป็นภาษาอังกฤษ ออกมาค่อนข้างตรงทีเดียว ✨

ถือได้ว่า ทำมาครบมาก และสามารถนำไปปรับใช้ได้กับหลากหลาย use cases เลย

ต่อกับ Firebase Genkit เพื่อทำ Similarity search ด้วย keyword จากรูปภาพ

ใน demo ของเรา เราเพิ่มอีกฟีเจอร์เพื่อให้ user สามารถส่งรูปเข้ามา แล้วแอปจะไปค้นหาเกมที่เหมือนกันให้ ด้วยการใช้ Firebase Genkit เป็นตัวช่วยในการดึง keyword จากรูปออกมา ก่อนนำ keyword ที่ได้ไปค้นจาก database เพื่อหาเกมที่คล้ายกัน

รู้จัก Firebase Genkit

Firebase Genkit

Firebase Genkit เป็นเครื่องมือที่ช่วยให้เราสร้างแอป AI ได้ง่ายขึ้น จุดเด่นของมันคือ การทำงานได้กับ model ที่หลากหลาย ไม่จำกัดแค่ของ Google พร้อมกับเราสามารถกำหนดโครงสร้างข้อมูลได้ เพื่อให้คำตอบที่ได้จาก Generative AI มี structure มากขึ้น

ทำ Similarity search ด้วย keyword จากรูปภาพ

เหมือนที่บอกไว้ในตอนต้นว่า เราจะส่งรูปไปให้ Gen AI ดึง keyword ออกมาให้ (ผ่าน Firebase Genkit) ก่อนนำ keyword ที่ได้ไปค้นจาก database ของเราเพื่อหาเกมที่คล้ายกัน

0. ติดตั้ง Firebase Genkit

ก่อนอื่นเลย เราจะต้องติดตั้ง Firebase Genkit ก่อน ตาม Document นี้

Get started | Genkit | Firebase

แล้วใช้คำสั่ง เพื่อเพิ่ม Genkit ที่รันบน Cloud Functions for Firebase ลงในโปรเจคของเรา

firebase init genkit

หลังจากที่เราติดตั้งเรียบร้อย เราจะได้โฟลเดอร์ functions มา แบบนี้

โดยจะมี source code ตัวอย่าง ในการใช้งานเบื้องต้นทั้งการ configGenkit รวมไปถึงตัวอย่าง flow ที่เราสามารถดูตัวอย่างการเขียนและลองทดสอบการทำงานเบื้องต้นได้

Firebase Genkit ยังมี Developer Tools สำหรับการทดสอบ Flow, Model ต่างๆบน local ได้ด้วย โดยเราสามารถติดตั้งตาม Document นี้

Firebase Genkit Developer Tools

แล้วใช้คำสั่ง genkit start เพื่อเริ่มใช้งาน Developer UI อย่าลืมโหลด API key ที่จำเป็นก่อนรันด้วยน้า export GOOGLE_GENAI_API_KEY=<your API key> ถ้าเลือกใช้ GoogleAI สามารถกดรับ API key ได้ที่ https://aistudio.google.com/apikey

1. ทำ Flow ในการดึง keyword ออกมาจากรูป

ติดตั้งเครื่องมือที่จำเป็นเสร็จแล้ว เรามาเริ่มเขียน flow สำหรับ ดึง keyword จากรูปกัน การสร้าง flow ด้วย Firebase Genkit

export const getKeywordFromPictureFlow = onFlow(
  {
    // Configuration ต่างๆของ Flow นั้น
  },
  async (input) => {
    // step การทำงานของ Flow เช่น
    // 1. เช็คว่ามีข้อมูล
    // 2. ส่งข้อมูลให้ GenAI ดึง keyword ออกมา
    // 3. ส่งผลลัพธ์กลับออกไปเป็น response
  }
);

ส่วนประกอบของ Flow จะมีอยู่ 2 ส่วนด้วยกัน คือ

• Configuration ต่างๆของ flow นั้น ที่ประกอบด้วย ชื่อ flow, schema ของ input/output, auth policy (Firebase Genkit ทำงานร่วมกับ Firebase Authentication ได้เป็นอย่างดี สามารถเช็คสิทธิ์การเข้าถึงแต่ละ flow ได้)

export const getKeywordFromPictureFlow = onFlow(
  {
    name: "getKeywordFromPictureFlow",
    inputSchema: z.string(), // กำหนดให้รับ input มาเป็น string
    outputSchema: z.object({ // กำหนดว่า output ที่ได้จะอยู่ในรูปแบบของ {keywords: ["A", "B", "C"]}
      keywords: z.array(z.string()),
    }),
    // ให้ User ที่ login แล้วเท่านั้นใช้งานได้ เพื่อจำกัดการใช้งาน GenAI ที่อาจมีค่าใช้จ่าย 💸💸 (หรือเงื่อนไขอื่นๆตามต้องการ) 
    authPolicy: firebaseAuth((user) => {}), 
    httpsOptions: {
      cors: true,
    },
  },
...

• Step การทำงานของ flow เหมือนการเขียน functions ทั่วไป เพื่อระบุว่าใน flow นี้มีการทำงานอะไรบ้าง

...
  async (input) => {
    // ส่งข้อมูล Input ให้ GenAI ดึง keyword ออกมา
    const llmResponse = await generate({
      // ระบุ model ที่ต้องการใช้งาน จะเป็น claude3Sonnet, llama31, gpt4o, ollama ก็ได้
      model: gemini15Flash, // เราเลือกใช้ gemini15Flash เพราะเป็น multimodal ที่ใช้งานกับรูปได้
      output: { 
        format: "json", // บอกว่าอยากได้ structure data ในรูปแบบของ json
        schema: z.object({ // กำหนด structure ของ output ที่ต้องการ
          keywords: z.array(z.string()),
        }),
      },
      // กำหนด prompt
      prompt: [
        // โยน input เข้าไปเป็น media
        { media: { url: input } }, 
        // prompt ที่บอกให้ GenAI ดึง keyword ออกมาจากรูปให้
        // พยายามลดคำซ้ำซ้อน คำสร้อย เพื่อให้ได้ keyword ที่ตรงประเด็น
        // พร้อมกับ brief มันอีกรอบว่าให้ส่งกลับมาเป็น array
        {
          text: `
            From the picture suggest 3 keywords or theme, avoid the word 'game', 'board' or other decorative words. 
            Return the keywords as an array list. e.g. ['strategy', 'cooperative', 'worker placement']
          `,
        },
      ],
      config: {
        temperature: 1,
      },
    });
    return llmResponse.output() as { keywords: string[] };
  }
);

การใช้คำสั่ง onFlow เป็นการระบุว่า Flow นี้จะถูก Deploy flow ด้วย Cloud Functions for Firebase เหมือนเป็น functions อันนึงใน Cloud functions

ลองทดสอบ flow ใน Developer tools ก่อนนำไปใช้งานกับ UI โดยเราส่ง link ของรูปเกม MouseTrap เกมโปรดของเด็กที่บ้าน เข้าไปเป็น input และได้ output ออกมาในรูปแบบ object ตามที่กำหนดไว้เลย

2. เรียกใช้ใน client

เพื่อให้การทดสอบบน local ราบรื่น เราเพิ่ม functions เข้าไปใน config ของเราก่อน พร้อมกับเชื่อมต่อไปที่ Function emulators

/* ไฟล์ lib/firebase.ts */

export const firebaseApp = initializeApp({
  // your config from Firebase console
})

const functions = getFunctions(firebaseApp)

if (import.meta.env.DEV) {
  connectFunctionsEmulator(functions, 'localhost', 5003)
  // ... บริการอื่นๆที่ใช้
}
export { functions }

จากนั้นทำการเรียกใช้ function ด้วย httpsCallable เหมือนการเรียกใช้ callable functions ทั่วๆไปจาก Cloud Functions for Firebase เลย

export const extractKeywordsFromImage = async (
  input: string,
): Promise<{ keywords: string[] }> => {
  try {
    const getKeywords = httpsCallable(functions, 'getKeywordFromPictureFlow')
    const keywords = await getKeywords(input)
    return keywords.data as { keywords: string[] }
  } catch (error) {
    throw error
  }
}

นำไปประกอบร่างกับ UI logic

const searchByImage = async (imageData?: string) => {
    if (!imageData) return
    isPending.value = true
    try {

      // Get keywords จากรูปภาพด้วย Genkit
      const keywordsFromImage = (await extractKeywordsFromImage(imageData)) as {
        keywords: string[]
      }

      // นำ keyword มาต่อกันเป็น string
      const imgQuery = keywordsFromImage.keywords.join(' ')

      // ส่งไป query กับ Firebase Data Connect
      const response = await searchSimilarContent({
        query: imgQuery,
        limit: 10,
      })

      // นำค่าที่ได้ไปใช้งานใน UI
      games.value = response.data
        .games_descriptionEmbedding_similarity as Game[]
    } catch (err) {
      console.error('searchByImage', error)
      if (err instanceof Error) error.value = err
    } finally {
      isPending.value = false
    }
  }

เพียงเท่านี้ก็ได้ฟีเจอร์ค้นหาแบบ Similarity search ด้วย keyword จากรูปภาพมาใช้งานแล้ว 🎉

ส่งท้าย

เนื้อหาในบทความนี้มาจากสิ่งที่เราพูดไปในงาน Google DevFest Bangkok 2024 หัวข้อ Build better AI-driven Cloud SQL apps with Firebase Data Connect สิ่งที่ยกตัวอย่างมาทั้งหมดเป็นเพียงแค่ 1 ในหลาย use cases ที่เราสามารถนำ Firebase Data Connect และ Firebase Genkit บริการใหม่ทั้ง 2 ตัวจาก Firebase ไปเป็นตัวช่วยในการเพิ่มฟีเจอร์ AI ให้แอปพลิเคชันของเรา แบบสะดวกและง่ายที่สุด ใครลองใช้แล้ว อย่าลืมมาแบ่งปันให้กันฟังที่ Firebase Developer Group Thailand บ้างนะคะ

อ่านมาถึงตรงนี้ ฝากกด Clap กด Share หรือกดติดตาม Firebase Thailand เพื่อไม่ให้พลาดบทความต่อๆไปด้วยนะคะ สำหรับวันนี้ ขอบคุณและสวัสดีค่ะ 🙏

ทำ Vector similarity search กับ Firebase Data Connect และ Firebase Genkit was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

หลายคนคงคุ้นเคยกับ Firebase ในฐานะบริการ Backend as a Service ที่โดดเด่นด้วย NoSQL database อย่าง Realtime database ที่เปิดตัวมาตั้งแต่ปี 2012 และต่อยอดด้วย Cloud Firestore ในปี 2017 แต่ทั้งสองบริการยังมีข้อจำกัดในการจัดการ Query ที่ซับซ้อน เรามักจะได้ยินเสียงเรียกร้องจาก Firebase community อยู่เสมอว่า เมื่อไหร่จะมี SQL database สักที จะได้แก้ปัญหาเรื่องข้อมูลซ้ำซ้อนและทำ complex query ได้

ในที่สุดเมื่องาน Google I/O ที่ผ่านมา Firebase ก็เปิดตัว Firebase Data Connect ถือว่าเป็นบริการตัวแรกที่รองรับ Relational database ของ Firebase เลย 🎉

การทำงานของ Firebase Data Connect

จะบอกว่า Firebase Data Connect เป็น database ก็ไม่ถูกซะทีเดียว เพราะจริงๆแล้วเบื้องหลังของ Firebase Data Connect ก็คือ PostgresSQL ที่รันอยู่บน GCP Cloud โดยเจ้า Firebase Data Connect เป็นเหมือนตัวเชื่อมระหว่าง SQL Database กับ Client ให้เรา ด้วย GraphQL

ทีม Firebase สร้าง Firebase Data Connect ภายใต้คอนเซปที่ว่า “You write the query, we do the rest” นักพัฒนาอย่างเรากำหนดเพียง 2 อย่าง ส่วนที่เหลือ Firebase จะเป็นคนจัดการให้

สิ่งที่เรากำหนด (ในรูปแบบของ GraphQL)

• Data model (schema) ซึ่งเป็นการกำหนด database schema ว่าต้องมีตารางอะไรบ้าง แต่ละตารางต้องมีข้อมูลอะไร ชนิดไหนบ้าง
• Connector (queries & mutations) ซึ่งก็คือ การ Create, Read, Update, Delete ข้อมูลใน database นั่นเอง

สิ่งที่ Firebase จะสร้างให้แบบอัตโนมัติ

• PostgresSQL schema คำสั่งสร้างโครงสร้างฐานข้อมูลใน PostgesSQL และ migration
• Typesafe SDK เพื่อใช้ใน client application ของเรา โดยรองรับทั้ง iOS, Android, Web และ Flutter
• API Endpoint เพื่อให้ client สามารถเชื่อมต่อ ทำ CRUD กับ Database ได้ พร้อมกับมี Authorization ที่จะคอยเช็คสิทธิ์ user ในทุกๆ endpoint อีกด้วย เช่น เราอาจจะอยากให้ user ทุกคนเห็นรายการสินค้า แต่เฉพาะ admin เท่านั้นที่เพิ่มรายการสินค้าได้ เป็นต้น

เริ่มต้นใช้งาน Firebase Data Connect

กระบวนท่าจะมีอยู่ 6 ขั้นตอนด้วยกัน ดังนี้

0. ติดตั้ง
1. กำหนด Data model (schema)
2. กำหนด Connector (queries, mutations)
3. ทดสอบใน local
4. เรียกใช้ใน client
5. Deploy

0. ติดตั้ง

เราสามารถเริ่มสร้าง Data Connect ได้ทั้งใน Firebase Console หรือ ใช้ command line ผ่าน Firebase cli ด้วยคำสั่ง

firebase init dataconnect

ในการติดตั้ง เราต้องกำหนด ID ของ CloudSQL instance, ID ของ database, region ที่ต้องการ

อย่างที่ระบุไว้ต้นบทความว่า เบื้องหลังของ Firebase Data Connect เป็น CloudSQL ดังนั้นการสร้างตรงนี้คือการสร้าง CloudSQL instance และ PostgresSQL Databaseโดยโปรเจคของเราจะต้องเป็น Blaze Plan (Pay as you go) เท่านั้น ใครจะใช้อย่าลืมไปเปิด billing กันก่อนด้วยนะคะ

ในช่วง public preview นี้ ถ้าใครสร้าง database instance ใหม่ ผ่าน Firebase Data Connect ก็จะได้ใช้งาน CloudSQL instance แบบฟรีๆไป 3 เดือนเต็ม (ซึ่งจะเป็นตัว db-f1- micro 1 vCPU, 600 MB RAM and 10 GB storage) หลังจากนั้นคิดค่าใช้บริการตามจริง ขึ้นอยู่กับขนาด instance และจำนวนการใช้งาน ดูรายละเอียดราคาแบบเจาะลึกที่ Data Connect Pricing

หลังจาก setup เสร็จเราจะได้โฟลเดอร์ data connect ที่มีส่วนประกอบ 3 ส่วน

1. โฟลเดอร์ connector ซึ่งจะเป็นส่วนที่เราเรียกข้อมูลมาใช้ (Query) หรือแก้ไขข้อมูล (Mutation)
2. โฟลเดอร์ schema เป็นส่วนที่เรากำหนด Data model ของข้อมูลใน Database
3. ไฟล์ dataconnect.yaml เป็น config เมื่อกี๊ที่เราใส่เข้าไปตอน set up

1. กำหนด Data model (schema)

สมมุติว่าเราต้องการทำแอปร้านบอร์ดเกม สิ่งที่เราต้องทำคือกำหนดรูปแบบฐานข้อมูล หน้าตาประมาณนี้ด้วย GraphQL ที่ไฟล์ schema.gqlในโฟลเดอร์ schema

# schema.gql

# Users
type User @table {
  id: String! @col(name: "auth_uid")
  username: String! @col(name: "username", dataType: "varchar(50)")
}

# Games
type Game @table {
  # The below parameter values are generated by default with @table, and can be edited manually.
  # implies directive `@col(name: "game_id")`, generating a column name
  id: UUID! @default(expr: "uuidV4()")
  title: String!
  description: String!
  imageUrl: String!
  genre: String
  emoji: String
  minAge: Int
  minPlayers: Int
  maxPlayers: Int
  playTime: Int
  descriptionEmbedding: Vector @col(size: 768) # Enables vector search
}

# Reservations
type Reservation
  @table(name: "reservations", key: ["game", "user", "timeSlot"]) {
  id: UUID! @default(expr: "uuidV4()")
  user: User!
  game: Game!
  timeSlot: Timestamp!
  createAt: Date! @default(expr: "request.time")
}

• ตาราง user เก็บข้อมูลของผู้ใช้งานนั้นๆเอาไว้
• ตาราง game เก็บข้อมูลและรายละเอียดต่างๆของเกม
• ตาราง reservation เป็นตารางที่ join ข้อมูล Game และ User เอาไว้ด้วยกัน พร้อมกับเวลาที่จอง โดยเราสามารถกำหนด foreign key หลายๆอันได้อย่างที่ระบุใน code snippet ด้านบน

2. กำหนด Connector (queries, mutations)

เป็นการทำ CRUD (Create, Read, Update, Delete) ไม่ว่าจะเป็นการดึงข้อมูลออกมา หรือแก้ไขข้อมูล จาก database ยกตัวอย่าง ในแอปร้านบอร์ดเกมของเรา เราอาจจะอยากให้มี connector ตามนี้

• User ทุกคนสามารถ ค้นหารายการของบอร์ดเกมด้วย keyword อายุ และ จำนวนผู้เล่น

คำสั่ง @auth(level: PUBLIC) เป็นการระบุว่า ให้ทุกคนเข้าถึง query นี้ได้โดยไม่ต้องมีการ login ก่อน

# queries.gql

query SearchGames($keyword: String!, $minAge: Int, $player: Int)
@auth(level: PUBLIC) {
  games(
    where: {
      _and: [
        { minAge: { ge: $minAge } }
        { minPlayers: { le: $player } }
        { maxPlayers: { ge: $player } }
        {
          _or: [
            { title: { contains: $keyword } }
            { description: { contains: $keyword } }
            { genre: { contains: $keyword } }
          ]
        }
      ]
    }
  ) {
    ...DisplayGame
  }
}

• User สามารถดูการจองของตัวเองเท่านั้น (My reservations)

คำสั่ง @auth(level: USER) เป็นการระบุว่าต้อง login ก่อนเท่านั้นถึงจะเข้าถึง query นี้ได้ ใช้คำสั่ง eq_expr: "auth.uid" ใน where เพื่อใช้ค่า uid จาก auth token ที่ส่งเข้ามา แทนที่จะต้องรับค่า uid เป็น parameters เพื่อความปลอดภัยไปอีกขั้น

# queries.gql

query ListMyReservations @auth(level: USER) {
  reservations(where: { user: { id: { eq_expr: "auth.uid" } } }) {
    id
    game {
      ...DisplayGame
    }
    timeSlot
  }
}

• Admin เท่านั้น ที่สามารถเพิ่มเกมใหม่ได้

เราสามารถเขียน expression เพื่อตรวจสอบ token ที่อยู่ใน Auth ได้ด้วย เช่น กรณีนี้ เราอาจจะเก็บค่า isAdmin ไว้ใน token แล้วก็ตรวจสอบว่าค่าต้องเป็น auth.token.isAdmin == true ก่อนจึงจะอนุญาตให้ผู้ใช้มีสิทธิ์ insert ข้อมูลเกมลงใน database

# mutations.gql

mutation CreateGame(
  $title: String!
  $description: String!
  ...
) @auth(expr: "auth.token.isAdmin == true") {
  game_insert(
    data: {
      title: $title
      description: $description
      ...
    }
  )
}

จากตัวอย่างด้านบน ทุกคนน่าจะเห็นรูปแบบการเขียน connector แบบคร่าวๆแล้ว โดยสรุปได้ 3 อย่างด้วยกัน

1. รับค่า parameters ที่ต้องการ เช่น minAge ในการ ค้นหาเกม ที่เหมาะกับอายุของผู้เล่น
2. กำหนดสิทธิ์ในการเข้าถึงข้อมูล อย่างที่เห็นในตัวอย่างด้านบน เราสามารถกำหนดการเข้าถึงของแต่ละ endpoint ได้ สามารถเลือกเป็น @auth(level: ...) หรือเขียนเงื่อนไขโดยการใช้ @auth(expr: ...)ถ้าไม่มีการกำหนด @auth(...) จะ default เป็น NO_ACCESS คือไม่ให้ใครเข้าถึงเลย นอกจากสิทธิ์ Admin SDK เท่านั้น ดูรายละเอียดเพิ่มเติมเกี่ยวกับ Auth ได้ที่ Secure Data Connect with authorization and attestation
3. เขียนคำสั่ง SQL ไม่ว่าจะเป็น query หรือ mutation ตามรูปแบบ GraphQL ดู Ref คำสั่งได้ที่ Firebase Data Connect API Reference

นอกจากนี้ ถ้าเรามีคำสั่งที่ค่อนข้างซับซ้อน เขียน GraphQL แล้วอาจจะงง Firebase Data Connect ยังรองรับการเขียน Raw SQL Query ด้วย โดยเราสามารถสร้าง view ตาม query ที่เราต้องการได้

3.ทดสอบใน local

Firebase Data Connect รองรับการทำงานกับ Emulators ด้วย ทำให้เราสามารถทำทุกอย่างบน local ให้มั่นใจก่อนการ deploy ไป production ได้

3.1 Extensions

สำหรับใครที่ใช้ VSCode หรือ IDX สามารถติดตั้ง extentions เพื่อเพิ่มความสะดวกสบายในการทำงานกับ Data Connect ทั้ง auto complete ของ GraphQL, UI สำหรับการเชื่อมต่อกับ local emulators, UI สำหรับทดสอบ การเชื่อมต่อกับ endpoint ต่างๆ

หลังจากที่เราใช้คำสั่ง

firebase emulators:start

เราจะเห็นว่ามีคำสั่ง Run (local) โผล่ขึ้นมา ซึ่งเราสามารถใช้ tab DATA CONNECT EXECUTION ในการทดสอบการเชื่อมต่อกับ endpoint ที่เราสร้างไว้ได้ โดยกำหนด Parameter variables และ Authentication แล้วกด Run (local) เพื่อทำการทดสอบ endpoint ใน local หรือกด Run (Production) เพื่อเรียก endpoint ใน production เลยนั่นเอง

เรายังสามารถแก้ไข Authentication ในการทดสอบสิทธิ์เข้าถึงของแต่ละ endpoint ด้วย อย่างเช่น SearchGame นี้เราลองกำหนดเล่นๆว่า @auth(level: USER_EMAIL_VERIFIED) หมายความว่าต้องเป็น user ที่มีการยืนยันอีเมลล์แล้วเท่านั้นจึงจะใช้ endpoint ได้ ในช่วงของการทดสอบ เราไปตั้งค่า Authentication โดยการกำหนด Run As ให้เป็น Authenticated แต่เปลี่ยนค่า email_verified จาก true เป็น false พอกด Run (local) เพื่อทดสอบ endpoint นี้อีกครั้ง เราจะได้ error กลับมาเป็นสถานะ 401 Unauthorized ทันที เพราะไม่เข้าเงื่อนไขที่กำหนดเอาไว้นั่นเอง

3.2 Seed data

เวลาที่เราทำงานใน local ข้อมูลใน database จะถูก reset ใหม่ทุกรอบเวลาเรารัน emulators แต่ละครั้ง เพื่อความสะดวกสบายในการทำงานบน local เราสามารถเขียน mutation เพื่อเพิ่มข้อมูลลงใน database ได้ด้วย

โดยหลังจากที่เรา run emulators เสร็จแต่ละครั้งเราก็สามารถมา Run (local) คำสั่งนี้ต่อได้เพื่อทำการ seed ข้อมูลเข้า database

3.3 Exploring the data

ความคุ้นชินของเราอย่างนึงในการทำงานกับ SQL คือการได้ดูข้อมูลในรูปแบบตาราง ซึ่งตอนนี้ Firebase Data Connect ยังไม่มีให้ ทุกอย่างที่พ่นออกมา จากการทดสอบแต่ละ endpoint ยังเป็นแค่ข้อมูลในรูปแบบ json เท่านั้น

อย่างที่บอกไปในตอนแรกว่าเบื้องหลังของมันคือ PostgresSQL และ Firebase ใช้ PGLite ในการรัน database บน local ซึ่งก็ทำให้การดูข้อมูลแบบตารางเป็นเรื่องที่ทำได้เหมือนกัน โดยเราสามารถใช้ SQL Viewer อย่าง DBeaver, DataGrip หรือเจ้าอื่นๆที่สะดวก แล้วสร้างการเชื่อมต่อไปยัง jdbc:postgressql://127.0.0.1:5432/[databaseName]?sslmode=disable

หลังจากนั้น เราก็สามารถ explore ข้อมูลแต่ละตาราง ดู database schema ได้เหมือน SQL อื่นๆเลย

4. สร้าง SDK

หลังจากที่เรากำหนดรูปแบบข้อมูลและ connector ที่ต้องการแล้ว ก็ถึงเวลาเอามาต่อกับ client หน้าบ้าน ซึ่งแทนที่เราจะไป connect กับ database ตรงๆ เราจะเชื่อมต่อกับ typesafe SDK ที่ Firebase สร้างให้ แบบเราเกริ่นเอาไว้ตอนแรก

ถ้าสังเกตตอนที่เรา firebase init dataconnect ในขั้นตอน 0.ติดตั้ง ในโฟลเดอร์ connectorมันจะมีไฟล์ connector.yaml ซึ่งไฟล์นี้แหละที่เราสามารถมากำหนด destination ของ SDK ที่เราต้องการ พร้อมกับตั้งชื่อ package เพื่อให้ Firebase ทำการสร้าง typesafe SDK ที่เราสามารถนำไปเรียกใช้ใน client app ไม่ว่าจะเป็น iOS, Android, Web, Flutter ได้เลย

เข้ามาตอนแรกทุกอย่างจะถูก comment เอาไว้ ให้ทำการเอา comment ออกและเขียน config ที่ต้องการลงไปเลย อย่างในนี้ เราระบุว่า ให้ outputDir อยู่ใน folder app ซึ่งก็คือ vue app ที่เราสร้างเอาไว้

4. เรียกใช้ใน client

ในบทความนี้ เราทำแอปตัวอย่างเป็น vue web application ที่แสดงรายการของเกมทั้งหมด พร้อมกับฟังก์ชันในการค้นหาเกมด้วย keyword, อายุ และ จำนวนผู้เล่น

4.1 เชื่อมต่อกับ Data Connect Emulators

/* ไฟล์ lib/firebase.ts */

export const firebaseApp = initializeApp({
  // your config from Firebase console
})

const auth = getAuth(firebaseApp)
const dataconnect = getDataConnect(firebaseApp, connectorConfig)
if (import.meta.env.DEV) {
  connectDataConnectEmulator(dataconnect, '127.0.0.1', 9398, false)
  connectAuthEmulator(auth, 'http://localhost:9098')
}
export { auth, dataconnect }

4.2 ใช้ functions และ types ใน SDK บน client

import { searchGames } from '@dicely/dataconnect'

const response = await searchGames({
  keyword: qParams.keyword,
  minAge: qParams.minAge ? Number(qParams.minAge) : undefined,
  player: qParams.player ? Number(qParams.player) : undefined,
})

/* ใช้ค่า response.data ใน UI 
 games.value = response.data.games as Game[]
*/

ซึ่งพอเราลองรันดู ก็จะเห็นว่ามันมีการเรียก api endpoint ที่ Firebase สร้าง พร้อมกับมีการเช็คสิทธิ์ Authentication ให้ด้วย แบบที่เราไม่ต้องทำอะไรเลย นอกจากเรียก function เท่านี้เองจริงๆ 🫰

5. Deploy

ถ้าเราเทสบน local แล้วแฮปปี้ เราสามารถรันคำสั่ง firebase deploy เพื่อทำการปล่อยของทั้งหมด ขึ้น production ได้ หรือจะเลือกเฉพาะ product ก็ได้เช่นเดียวกัน

firebase deploy --only dataconnect

ถ้าหาก database ของเรามีการเปลี่ยนแปลงที่อาจกระทบของบน production firebase ก็จะทำการแจ้งเตือนเราก่อน หรือเราสามารถใช้คำสั่ง เพื่อเรียกดูการเปลี่ยนแปลงของ database ก่อนทำการ deploy ก็ได้

firebase dataconnect:sql:diff

หลังจากที่ deploy เรียบร้อยแล้ว ก็สามารถเข้าไปทดสอบข้อมูลของเราผ่าน Firebase Console หรือดู Cloud SQL ที่ Google Cloud Console ได้เช่นกัน

The workflow

ไม่ว่าจะเป็นการ dev เพื่อเอาขึ้น production หรือ บน local โฟล์วการทำงานของนักพัฒนาอย่างเราเหมือนกันเลยคือ

1. เขียน GraphQL เพื่อกำหนด Data model และ Connector
2. สร้าง SDK ไปใช้กับ client
3. เชื่อมต่อกับ database ผ่าน client SDK

สำหรับคนที่อ่านมาถึงตรงนี้ แล้วอยากจะไปลองเล่น ตามไปที่ Codelab ตัวนี้ได้เลยค่า จับมือทำตั้งแต่เริ่มจนจบเลย

Build with Firebase Data Connect

เนื้อหาในบทความนี้มาจากสิ่งที่เราพูดไปในงาน Google DevFest Bangkok 2024 หัวข้อ Build better AI-driven Cloud SQL apps with Firebase Data Connect เพื่อให้อร่อย ย่อยง่ายขึ้น เราขออนุญาตตัดจบไว้แค่นี้ก่อน และเดี๋ยวมีภาค 2 ที่เน้นการสร้าง Database สำหรับ AI ตามมาแบบไม่นานเกินรอค่า ฝากติดตามกันด้วยน้า

Firebase Data Connect บริการที่ทำให้ Firebase เชื่อมต่อกับ PostgresSQL ได้แบบง่ายๆ was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

TLDR — Too long, Don’t Read;

แนวทางการส่ง Offline Event เข้าตัว Measurement Protocol ทำได้ดังนี้

1. ฝั่ง Frontend ต้องเก็บ Client ID และ User ID มาให้ได้
2. ฝั่ง Backend ใช้ Client ID และ User ID ที่ได้มาจาก Frontend ประกอบกัน แล้วส่งข้อมูลเข้าตัว Measurement Protocol เอง

Google Analytics for Firebase ของดี ที่ใช้ง่าย แต่ดันมาไม่ครบ

เปิดหัวมาแบบนี้ แฟน ๆ Firebase อย่าพึ่งด่าผมนะ เพราะเรื่องมันมีอยู่ว่า ตั้งแต่สมัยที่ตัว Google Analytics for Firebase ออกมาใหม่ ๆ ตอนนั้นก็จะ Support อยู่แค่ Android กับ iOS จนผ่านมาพักใหญ่ ๆ ถึงจะ Support ฝั่ง Web แต่ว่าทั้งหมดนี้มันทำงานได้กับเฉพาะฝั่ง Frontend อย่างเดียว ไม่ครอบคลุมมาถึงฝั่ง Backend ด้วย

อ้าววว แล้วถ้าฝั่ง Backend ก็ต้องการส่งข้อมูลเข้า Analytics ด้วยล่ะ จะเอายังไง อันนี้ไม่ต้องห่วง เพราะว่า Google เองก็มีตัว Measurement Protocol ให้ใช้อยู่แล้ว เป็น REST API ธรรมดา ๆ เลย เพียงแค่ว่า ตัว Measurement Protocol มันจะไม่ได้รวมอยู่ใน SDK นะ ต้องเขียนเอง

แล้วทำไมฝั่ง Backend ต้องส่งข้อมูลเข้าฝั่ง Analyitcs ด้วยล่ะ ? ก็เพื่อเติมเต็มข้อมูลต่าง ๆ ที่ไม่สามารถทำได้จากฝั่ง Frontend ไง ยกตัวอย่าง เช่น ในแง่ของ ECommerce ปกติ Metric ส่วนใหญ่ สามารถวัดได้จาก Frontend อยู่แล้ว แต่จะมี Event บางอย่างที่ไม่สามารถวัดได้จาก Frontend ตรง ๆ นั่นก็คือ Metric ที่เกียวกับการจัดส่งบางตัว เนื่องจาก ข้อมูลที่เกียวกับการจัดส่ง มันจะไม่เกิดบน Frontend ของระบบเรา แต่ฝั่ง Backend เรามีข้อมูลพวกนี้อยู่แล้ว ฉะนั้น ถ้าเราอยากทำ Conversion ที่ครอบคลุมมาถึงเรื่องการจัดส่ง เราจะต้องให้ Backend เรา ส่ง Metric พวกนี้เข้ามาใน Analyitcs ด้วย

มาถึงตรงนี้ อาจจะมีคนหัวใส อยากจะเก็บ Stat บางอย่างบน Google Analytics เลยได้มั้ย คำตอบคือ ได้นะ ถ้า Stat พวกนั้นมันสามารถผูกกับข้อมูลที่มาจาก Frontend ได้ แต่ถ้าผูกไม่ได้ ก็ยังส่งเข้าไปได้ แต่ตัว Google Analytics จะไม่แสดงข้อมูลนั้น ข้อความนี้อาจจะงง ๆ หน่อย สรุป ๆ ง่าย ๆ ก็คือ เราไม่สามารถลักไก่ใช้งาน Google Analytics ในแบบผิด ๆ

ทำอย่างไร ?

เตรียมความพร้อม

1. Firebase Account and Firebase Project
2. Google Analytics Permissions

เริ่มกันที่ฝั่ง Frontend

ในตัวอย่างนี้จะเน้นมาทาง Web นะครับ

เริ่มจากให้เอา Analytics SDK ใส่ในเว็บให้เรียบร้อย (วิธีทำ)

จากนั้น จะมี 2 ส่วนสำคัญ ที่เราต้องทำ คือ

1. Set User ID ให้ตัว Analytics SDK
2. เอาค่า Google Analytics Client ID ออกมาจากตัว Analytics SDK
   อันนี้สำคัญที่สุด เพื่อให้ตัว Measurement Protocol ผูกข้อมูลได้อย่างถูกต้อง

1. Set User ID ให้ตัว Analytics SDK

ขั้นตอนนี้ถึงจะไม่จำเป็นต้องทำ แต่แนะนำให้ทำเป็นอย่างยิ่ง และหากเป็น User ID ที่ Backend ใช้งานด้วยก็จะดีที่สุด

import {
  getAnalytics,
  setUserId,
} from 'firebase/analytics'

export function analyticsSetUserId(userId: string) {
  const analytics = getAnalytics()
  setUserId(analytics, userId)
}

// https://firebase.google.com/docs/analytics/userid#web

รายละเอียดเต็ม ๆ แนะนำให้อ่านจากต้นทางนะครับ

2. เอาค่า Google Analytics Client ID ออกมาจากตัว Analytics SDK

อันนี้สำคัญที่สุด เพื่อให้ตัว Measurement Protocol ผูกข้อมูลได้อย่างถูกต้อง

import {
  getAnalytics,
  getGoogleAnalyticsClientId as getGoogleAnalyticsClientIdFirebase
} from 'firebase/analytics'

export function getGoogleAnalyticsClientId() {
  const analytics = getAnalytics()
  return getGoogleAnalyticsClientIdFirebase(analytics)
}

// https://firebase.google.com/docs/reference/js/analytics.md#getgoogleanalyticsclientid_b0a3b5a

อันนี้ ใน Doc ปกติจะไม่มีเขียนไว้ แต่มีในนี้

สำคัญมาก อย่าลืมเอาค่าที่ได้ ส่งไปเก็บที่ Backend ด้วยนะ

เอาละ ในฝั่ง Frontend เราเรียบร้อยแล้ว ง่ายนิดเดียว (ที่เหลือยากละ 😂)

มาต่อกันที่ฝั่ง Backend

ในตัวอย่างนี้จะเน้นเป็น Node.js แบบ TypeScript นะครับ

จะมี 3 ส่วนสำคัญ ที่เราต้องทำ คือ

1. ทำให้ Backend เราส่งข้อมูลเข้า Measurement Protocol ได้
2. เตรียมค่า API Secret และ Measurement ID
3. เตรียมค่า User ID และ Google Analytics Client ID ที่ได้มาจาก Frontend

1. ทำให้ Backend เราส่งข้อมูลเข้า Measurement Protocol ได้

จะใช้ Axios หรือ Lib ตัวอื่น อันนี้เอาตามสะดวกเลยครับ ยังไงก็ได้ กับดูให้แน่ใจว่า Backend เราส่งข้อมูลไปข้างนอกได้จริง ๆ ไม่ติดอะไร

2. เตรียมค่า API Secret และ Measurement ID

ค่า API Secret จะต้องไปเอามาจากตัว Google Analytics UI วิธีการคือ

ไปที่หน้า Google Analytics UI Admin >>> Admin > Data collection and modification > Data Streams > Web stream details > Measurement Protocol API secrets > Create.

ค่า Measurement ID เอามาจาก Firebase Admin UI หรือ Google Analytics UI ก็ได้

Firebase Admin UI >>> Project settings > Your apps > Web apps > [measurementId]

Google Analytics UI >>> Admin > Data collection and modification > Data Streams > Web stream details

3. เตรียมค่า User ID และ Google Analytics Client ID ที่ได้มาจาก Frontend

มาถึงจุดนี้ ก็ได้เวลาที่เราจะเอา User ID และ Google Analytics Client ID ที่เราเก็บมาจาก Frontend ออกมาใช้แล้ว

type GoogleAnalyticsEvent = {
  name: string;
  params: any;
}

type GoogleAnalyticsPayload = {
  client_id: string;
  user_id?: string;
  timestamp_micros?: number;
  user_properties?: any;
  events: GoogleAnalyticsEvent[];
}

async function sendEventToGA(
  googleAnalyticsClientId: string,
  googleAnalyticsUserId: string,
  events: any[]
) {
  try {
    const data: GoogleAnalyticsPayload = {
      client_id: googleAnalyticsClientId,
      user_id: googleAnalyticsUserId,
      events,
    }
    const response = await sendEventToGoogleAnalytics(data)
    consola.log('payment.controller sendPaymentEventToGA ok response.status', response.status)
    consola.log('payment.controller sendPaymentEventToGA ok response.data', stringify(response.data))
    return response
  } catch (error) {
    consola.log('payment.controller sendPaymentEventToGA fail', error.message)
  }
}

export async function sendEventToGoogleAnalytics (data: GoogleAnalyticsPayload) {
  const endpoint = 'https://www.google-analytics.com/mp/collect'
  const debugEndpoint = 'https://www.google-analytics.com/debug/mp/collect'
  const config: AxiosRequestConfig = {
    headers: {
      'Content-Type': 'application/json',
    },
    params: {
      measurement_id: GOOGLE_ANALYTIC_MEASUREMENT_ID,
      api_secret: GOOGLE_ANALYTIC_API_SECRET,
    },
  }

  consola.log('google-analytic.repo sendEventToGoogleAnalytics ok config', stringify(config))
  consola.log('google-analytic.repo sendEventToGoogleAnalytics ok data', stringify(data))
  return axios.post(endpoint, data, config)
}

ใน Code ตัวอย่างนี้ จะมี 2 Function หลัก คือ

1. sendEventToGA() เป้าหมายคือ ทำหน้าที่เตรียมประกอบข้อมูล ก่อนส่งข้อมูล
2. sendEventToGoogleAnalytics() เป้าหมายคือส่งข้อมูล

อันที่จริงจะเขียนรวมกันก็ได้นะครับ แต่ผมชอบแยกอย่างน้อย ออกเป็น 2 Layer แบบนี้ โดยแยกตัวประกอบข้อมูล กับตัวส่งข้อมูลออกจากกัน

ใน Code ตัวสมบูรณ์ จะมีตัว Data Builder แยกออกมาอีก ก่อนจะมาประกอบร่าง และส่งข้อมูลตามลำดับ

ดูผล

วิธีดูผลที่สะดวกที่สุด คือดูผ่าน Realtime Event ครับ ถ้าเราใช้ User ID และ Google Analytics Client ID อย่างถูกต้อง เราจะเป็น Offline Event ที่เราส่งขึ้นเอง ไปรวมอยู่ใน User คนเดียวกันได้อย่างถูกต้อง

ตรงนี้ต้องขออภัยที่ไม่สามารถ เอารูปตัวอย่างออกมาได้ เนื่องเป็นมันเป็นงานที่ทำจริง

มาถึงตรงนี้ อาจจะมีคนคาใจว่า จะใช้ User ID ทำไม ในเมื่อ ใช้แค่ Google Analytics Client ID ก็เพียงพอแล้ว คำตอบคือ เวลาที่เราเอาข้อมูลออกมาใช้ต่อ (ไม่ว่าจะเป็น Power BI หรือ Looker Studio) เราจะได้มี Property ตัวนี้ เอาไว้เป็นตัวเชื่อมกับข้อมูลของเราเองครับ

References

• Get started with Google Analytics | Google Analytics for Firebase
• Measurement Protocol Reference | Google Analytics | Google for Developers
• API Reference | Firebase Admin SDK
• API Reference | Firebase JavaScript API reference

Google Analytics for Firebase กับ Offline Event ด้วย Measurement Protocol was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

ในการพัฒนาแอปพลิเคชันส่วนใหญ่ ณ วันนี้ก็ต้องมี server ที่คอยทำงานอยู่เบื้องหลัง ด้วยข้อดีหลายๆอย่าง เช่น เพื่อ centralize ข้อมูลและ logic การทำงานไว้ที่จุดๆเดียว, เพื่อรองรับการใช้งานจากหลายๆแพลทฟอร์ม, เพื่อความปลอดภัยที่มากขึ้น หรือจะเพื่อให้ client ไม่ต้องทำงานหนัก

แต่การจะตั้ง server เองก็ไม่ใช่เรื่องง่าย เพราะมันมีเรื่องที่ต้องให้คำนึงอยู่หลายเรื่องเหมือนกัน ไม่ว่าจะเป็นการ scale ที่ควรจะต้องขึ้นลงได้ตาม transaction ที่เกิดขึ้น, เรื่องของความปลอดภัย, เรื่องการเตรียม API หรือ SDK ที่จะรองรับการใช้งานแบบ seamless จากหลายๆแพลทฟอร์ม, หรือค่าใช้จ่ายทั้ง ฮาร์ดแวร์, ซอฟต์แวร์ และผู้เชี่ยวชาญที่จะเข้ามาดูแลตรงส่วนนี้

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

Cloud Functions for Firebase เป็นบริการแบบ Functions-as-a-Service ที่จะให้นักพัฒนาเขียนและ run โค้ดบน Google infrastructure เพื่อตอบสนอง event ต่างๆที่เกิดขึ้นจากบริการใน Firebase และ HTTP Requests

Event Triggers

เป็นการสร้างฟังก์ชันเพื่อเฝ้าดูความเปลี่ยนแปลง(subscribe)ที่เกิดขึ้นกับบริการต่างๆ Firebase ซึ่งเมื่อมีความเปลี่ยนแปลงเกิดขึ้น ตัวบริการที่เราเฝ้าดูจะส่งสัญญาณพร้อมกับข้อมูลมา(publish)ให้ฟังก์ชันทำงานต่อแบบอัตโนมัติ ซึ่ง ณ วันนี้ก็มีบริการมากมายที่สามารถทำงานร่วมกับ Cloud Functions ได้

เพื่อให้เห็นภาพ เรามาดูตัวอย่างการ trigger จากบริการใน Firebase ด้านล่างนี้กัน

จากภาพเราสามารถสร้างฟังก์ชันขึ้นมา(2) เพื่อเฝ้าดูการเปลี่ยนแปลงของฐานข้อมูลอย่าง Firestore หรือ Realtime Database ได้ เช่น เมื่อข้อมูลผู้ใช้ใหม่ถูก write เข้ามาเก็บลงฐานข้อมูล ตัวฐานข้อมูลจะส่งสัญญาณพร้อมกับข้อมูลผู้ใช้ มาให้ที่ฟังก์ชันของเรา เราก็สามารถเขียนโปรแกรมในฟังก์ชันของเราให้ส่งข้อความไปทักทายเครื่อง client ได้เป็นต้น

HTTP Requests

เป็นการสร้างฟังก์ชันที่เป็น API หรือ Webhook เพื่อรอรับการ request ผ่าน HTTP ให้ฟังก์ชันที่เขียนไว้ทำงานต่อ และเพื่อให้เห็นภาพ เรามาดูตัวอย่างการ trigger จาก HTTP Requests ด้านล่างนี้กัน

จากภาพเราสามารถสร้าง Webhook API(Functions) ขึ้นมาเพื่อรอรับ webhook events จาก GitHub เช่น เมื่อมีสมาชิกในทีม push โค้ดขึ้นมาใน repo ตัว GitHub ก็จะส่ง request พร้อมข้อมูลมาที่ Webhook API ของเรา ซึ่งเราก็สามารถเขียนโปรแกรมเพื่อส่งต่อข้อมูลเหล่านั้นไปให้เพื่อนร่วมทีมคนอื่นๆในห้อง Slack ได้เป็นต้น

Tip: เรายังสามารถสร้างฟังก์ชันที่ให้แอปเรียกหาตรง หรือที่เรียกว่า Callable Functions โดยไม่ต้องระบุ Endpoint URL ลงไปในโค้ดได้ด้วยนะ ใครสนใจก็อ่านบทความด้านล่างนี้ได้เลย

รู้จัก Callable Function ใน Cloud Functions for Firebase ตั้งแต่ Zero จนเป็น Hero

Schedule Functions

นอกเหนือจาก trigger ทั้ง 2 แบบที่กล่าวไปข้างต้น Cloud Functions for Firebase ยังได้ร่วมมือกับทีม Cloud Scheduler ออก Schedule functions ที่ให้เราสร้าง Cron Job แบบง่ายๆด้วยโค้ด 2–3 บรรทัด ใครสนใจอ่านเรื่องนี้จากบทความได้เลย

สร้าง Cron Job ด้วย Cloud Functions for Firebase ง่ายนิดเดียว

1. รู้จักกับ Cloud Functions for Firebase 2nd Gen

ในงาน Google I/O ปีที่ผ่านมาทีม Firebase ก็ได้เปิดตัว Cloud Functions 2nd Gen ซึ่งได้ยกเครื่องเบื้องหลังใหม่ โดยเปลี่ยนจาก GAE(Google App Engine) ที่ใช้ตั้งแต่ปี 2017 มาเป็น Cloud Build, Cloud Run และ Eventarc

โดยการเปลี่ยนบริการที่อยู่เบื้องหลังใหม่นี้เอง ก็มาพร้อมกับจุดเด่นที่มาปิด pain point จาก 1st Gen และฟีเจอร์ใหม่ๆที่เพิ่มเข้ามา จะมีอะไรบ้างไปดูกันเลย!

1.1 Concurrency

ใน 1st Gen นั้นกฎของเรื่อง concurrency คือ 1 request/instance ซึ่งสมมติว่ามี 16 requests วิ่งมาหาฟังก์ชันที่เราสร้างไว้พร้อมๆกัน ตัว 1st Gen จะทำการสร้าง instance ขึ้นมา 16 ตัว คำถามคือแล้วมันมีข้อเสียตรงไหน? คำตอบคือ ตรงที่ทุกครั้งในการสร้าง instance มันจะต้องใช้เวลาในการ build ตัว instance ขึ้นมาจากทั้ง Linux, npm, Native libs และ Node.js ซึ่งทำให้การ response จะมี latency แฝงอยู่ หรือที่เราจะเรียกปัญหานี้ว่า Cold Start

แต่ใน 2nd Gen ปัญหานี้ได้หมดไปแล้ว เนื่องจาก 1 instance รองรับได้หลาย request โดยค่าเริ่มต้นจะอยู่ที่ 80 request/instance แต่เราก็สามารถปรับแต่งเองได้ตั้งแต่ 1–1,000 request/instance เลยทีเดียว ดังนั้นถ้าจำนวน concurrency ไม่เกินจากที่กำหนด ก็จะไม่มีการสร้าง instance ใหม่นั่นเอง

1.2 Cost Saving

เรื่องถัดมาคือเรื่องเงินๆทองๆ ซึ่งถือเป็นเรื่องใหญ่ของพวกเรา ^^ โดยผมจะขอเปรียบเทียบการคิดค่าบริการผ่านตัวอย่างต่อไปนี้ สมมติว่าฟังก์ชันที่สร้างจาก 1st Gen และ 2nd Gen มี 3 requests ที่จะต้องใช้เวลาในการประมวลผล 150ms วิ่งเข้าหาเหมือนๆกัน และแต่ละ request จะมีระยะห่างจากกัน 60ms ตามรูปด้านล่าง

• ฟังก์ชันจาก 1st Gen จะทำการสร้าง instance ออกมา 3 ตัว โดยเวลาขั้นต่ำที่ Google จะคำนวนค่าใช้จ่ายจะอยู่ที่ 100ms ทำให้ 150ms ถูกปัดขึ้นเป็น 200ms ดังนั้น compute time จากทั้ง 3 requests จึงมีผลรวม 600ms
• ฟังก์ชันจาก 2nd Gen จะทำการสร้าง instance ออกมาแค่ตัวเดียว โดยกว่าที่ request ตัวสุดท้ายจะทำงานเวลาก็จะผ่านไปแล้ว 120ms เมื่อมารวมกับระยะเวลาในการประมวลผลของ request ตัวสุดท้าย ก็จะเป็น 120 + 150 = 270ms และ Google จะคำนวนค่า compute time ขั้นต่ำที่ 100ms ผมรวมจึงเป็น 300ms ซึ่งประหยัดกว่า 1st Gen ถึง 2 เท่าในตัวอย่างนี้

1.3 New Instance Size

ด้วยการที่ 1 instance สามารถรองรับได้หลาย request แน่นอนว่าทรัพยากรก็จะถูกใช้เพิ่มขึ้นด้วยเช่นกัน ดังนั้นใน 2nd Gen ก็ให้เราสามารถปรับแต่ง memory และ CPU ของ instance ได้เพิ่มมากขึ้นด้วย โดย

• Memory สามารถปรับแต่งได้ตั้งแต่ 128MB ไปจนถึง 32GB เลย
• CPU สามารถปรับแต่งได้ตั้งแต่ 1 CPU ไปจนถึง 8 CPU

หมายเหตุ: การปรับ memory กับ CPU ที่สูงจะมีผลทำให้ค่าบริการสูงขึ้นตามไปด้วย

1.4 Request Timeout

ค่า Request Timeout จะเป็นค่าที่เราสามารถระบุเวลาสูงสุดที่จะให้ฟังก์ชันทำงาน โดยหากการทำงานของฟังก์ชันเกินเวลาไป ก็จะตีเป็น error timeout กลับไป โดยค่าเริ่มต้นของ request timeout ในแต่ละฟังก์ชันคือ 60s

• 1st Gen สามารถปรับแต่งค่า request timeout ได้ตั้งแต่ 1s ถึง 9mins ทั้งฟังก์ชันแบบ Event triggers และ HTTP Requests
• 2nd Gen สามารถปรับแต่งค่า request timeout กับฟังก์ชันแบบ HTTP Requests ได้ตั้งแต่ 1s ถึง 60mins โดยที่แบบ Event triggers จะเหมือน 1st Gen

1.5 New Language Support

ในตอนเปิดตัวในปี 2017 ตัว Cloud Functions นั้นรองรับเฉพาะ Node.js ซึ่งในปีถัดมาก็มีการรองรับ TypeScript เพิ่มเข้ามา จนกระทั่งใน 2nd Gen ที่เพิ่งเปิดตัวนี้เองที่ Cloud Functions เปิดตัวภาษาที่รองรับภาษาใหม่ นั่นก็คือ Python ภาษาที่มีคนทั่วโลกกว่า 17 ล้านเขียนกัน คราวนี้ใครอยากใช้พวก lib หรือ framework เกี่ยวกับ ML เช่น PyTorch ก็จัดไปได้เลย

1.6 Firebase Alert Events

Cloud Functions 2nd Gen มีการ integrate ร่วมกับบริการอีก 3 ตัวใน Firebase สำหรับการแจ้งเตือนทีมนักพัฒนา

• Crashlytics สามารถเขียนฟังก์ชันไปเฝ้าดู crash ประเภทต่างๆที่เกิดขึ้นในแอป
• Performance Monitoring สามารถเขียนฟังก์ชันไปเฝ้าดูประสิทธิ์ภาพของแอปหากเกิน threshold ที่กำหนด
• App Distribution สามารถเขียนฟังก์ชันไปเฝ้าดู feedback ที่ tester ส่งมา หรือดูว่ามี iOS device ใหม่ register เข้ามา

1.7 Custom Event

หนึ่งในบริการของ Firebase ที่อำนวยความสะดวกให้นักพัฒนามากที่สุดตัวหนึ่ง ก็คือ Firebase Extensions ที่เป็น pre-package solution ให้นักพัฒนาสามารถ plug & play ได้ง่าย ซึ่งใน 2nd Gen ก็มีฟีเจอร์ให้เราสามารถไปคอยเฝ้าดูการทำงานของ extension บางตัวได้ เช่น Resize images หรือ Stripe เป็นต้น เพื่อที่จะให้ฟังก์ชันของเราทำงานเมื่อเกิดเหตุการณ์ต่างๆใน extension เช่น เมื่อ resize รูปเสร็จให้ฟังก์ชันเราส่งรูปที่ resize ไปให้เพื่อนเป็นต้น

1.8 Blocking Functions

ด้วยความร่วมมือของ Cloud Functions 2nd Gen, Firebase Authentication และ Google Cloud Identity ตอนนี้เรามี Blocking functions ที่ให้เราสามารถสร้างฟังก์ชันไปคั่นในกระบวนการ sign-up และ sign-in ของ Firebase Auth ได้ โดยตัวอย่างคือก่อนที่ผู้ใช้จะ sign-up สำเร็จเราจะตรวจสอบอีเมลของเขาก่อน ถ้าไม่ใช่ domain ที่เราต้องการก็สามารถปฏิเสธการ sign-up ครั้งนี้ได้

import { beforeUserCreated } from "firebase-functions/v2/identity";

export const blockauth = beforeUserCreated((event) => {
  const user = event.data;
  // Ensure only google.com emails can log into the changelog app
  if (!user?.email?.includes('@google.com')) {
    throw new HttpsError(
      "permission-denied",
      "Only @google.com are allowed to register.");
  }
});

1.9 Task Queue Functions

ใครที่มี job ที่ต้องใช้เวลา run นานๆเจอเคส timeout บ้าง memory limit บ้าง หรือใครที่ยิง API ไปแล้วติด Rate limit ต้องชอบสิ่งนี้ เพราะ Cloud Functions 2nd Gen จับมือกับ Google Cloud Tasks ออกฟีเจอร์ Task Queue Functions ที่ให้นักพัฒนาสามารถเขียนโปรแกรมเพื่อ enqueue งาน โดยสามารถกำหนด rate limit ได้กำหนดการ retry ได้อีกด้วย

1.10 New Environment Configuration

นอกจากไฟล์ .env และ Cloud Secret Manager ที่นักพัฒนาน่าจะเคยใช้กันแล้วใน 1st Gen ใน 2nd จะมีตัว Parameterized Config เพิ่มเข้ามาอีกตัว

โดย Parameterized Config จะให้เราระบุ key และประเภทของ value ลงในโค้ด แต่จะไม่มีการระบุ value ลงไป โดย value จะถูกระบุครั้งแรกที่มีการ deploy ฟังก์ชันผ่าน command line เท่านั้น ซึ่งก็จะปลอดภัยมากขึ้น แถม param แต่ละตัวที่เรากำหนด เราสามารถระบุค่า default ให้ได้ แต่ทำการ validate ตัว value ที่นักพัฒนากรอกมาตอน deploy ได้อีกด้วย

const { onRequest } = require("firebase-functions/v2/https");
const { defineString, defineInt, defineSecret } = require("firebase-functions/params");

const welcomeMessage = defineString("WELCOME_MESSAGE");
const concurrencyConfig = defineInt("CONCURRENCY", { default: 80 });
const apiKey = defineSecret("API_KEY");

exports.f2 = onRequest({secrets: [apiKey], concurrency: concurrencyConfig}, (req, res) => {
  const sampleApiKey = apiKey.value();
  res.send(`${welcomeMessage.value()}! I am a function.`);
});

11. Built-in CORS

ใน 1st Gen การจะกำหนดเรื่อง CORS ว่าให้ domain ไหนเรียก API เราได้บ้างนี่จะต้องไปดึง dependency จาก third-party เข้ามา แล้วเขียนโค้ดโดยเอา cors มาคลุมโค้ดเราอีกท ซึ่งมันแอบขัดใจเล็กๆ แต่ใน 2nd Gen นี่สบายเลย เพราะเขา built-in ตัว CORS มาให้แล้ว ซึ่งวิธีเรียกใช้ก็ง่ายๆแบบด้านล่างนี้ครับ

const { onRequest } = require("firebase-functions/v2/https");

// Allow all origins
exports.f1 = onRequest({ cors: true }, (req, res) => {
  res.send("Hello from Firebase!");
});

const origins = [
  'http://localhost:5000',
  'https://localhost:4000'
];

// Allow specific origins
exports.f2 = onRequest({ cors: origins }, (req, res) => {
  res.send("Hello from Firebase!");
});

12. Gloal Runtime Options

สำหรับคนที่มีประสบการณ์ในการสร้างฟังก์ชันใน 1st Gen มาแล้ว น่าจะรู้จักกับ Runtime Options ที่ให้เรากำหนด option ต่างๆให้กับฟังก์ชันเรา เช่น region ที่ต้องการ deploy ไปลง, memory หรือ timeoutSeconds เป็นต้น ซึ่งใน 1st Gen หากเรามีหลายๆฟังก์ชัน และเราต้องการให้ runtime options เหมือนๆกัน เราก็ต้องไปกำหนดทุกฟังก์ชันเอง เช่น

const functions = require("firebase-functions/v1");

exports.f1 = functions.runWith({ memory: "1GB" }).https.onRequest((req, res) => {
    res.send("Hello from Firebase!");
});

exports.f2 = functions.runWith({ memory: "1GB" }).https.onRequest((req, res) => {
    res.send("Hello from Firebase!");
});

ซึ่งมันก็ดูเป็นงานที่ซ้ำซ้อนใช่ไหม แต่ใน 2nd Gen ปัญหานี้จะหมดไปด้วย Global Runtime Options ที่ให้เราสามารถกำหนด option ต่างๆไว้ที่ส่วนกลาง และทุกฟังก์ชันก็จะได้รับอนิสงส์ไปด้วยอัตโนมัติ คือดีย์!

const { onRequest } = require("firebase-functions/v2/https");
const { setGlobalOptions } = require("firebase-functions/v2");

setGlobalOptions({
  region: "asia-southeast1",
  memory: "1GB",
  concurrency: 40
});

exports.f1 = onRequest((req, res) => {
  res.send("Hello from Firebase!");
})

exports.f2 = onRequest((req, res) => {
  res.send("Hello from Firebase!");
})

หมายเหตุ: กรณีที่ต้องการให้ฟังก์ชันใดมีการกำหนดค่า Runtime Options ที่แตกต่างก็ยังสามารถไปกำหนดค่าตรงๆแบบในข้อ 11.1 ได้ด้วย

2. วิธีติดตั้ง Cloud Functions for Firebase

2.1 สร้างโปรเจคใน Firebase

ใครที่มีโปรเจคกับ Firebase อยู่แล้วให้ข้ามขั้นตอนนี้ไปได้เลย ส่วนใครที่ยังไม่เคยมีหรือต้องการสร้างใหม่ให้ไปที่ Firebase Console จากนั้นกด Add project ระบุรายละเอียดต่างๆแล้วกด Create project

เมื่อกดเข้าไปในโปรเจคที่เราสร้าง สิ่งที่แรกที่ต้องทำคือ…ให้ไปเปลี่ยนแพลนจาก Spark เป็นเป็น Blaze(Pay as you go) ก่อน เนื่องจาก Cloud Functions for Firebase มีเงื่อนไขว่า หากต้องการ deploy ฟังก์ชันขึ้น production จำเป็นจะต้องใช้แพลนนี้

การเปลี่ยนมาใช้ Blaze plan นักพัฒนาจะได้โค้วต้าในการเรียกใช้งานฟังก์ชัน ฟรี 2,000,000 requests/เดือน

2.2 ติดตั้ง Node.js และ npm

ใครที่มีพร้อมทั้ง Node.js และ npm ในเครื่องแล้วให้ข้ามขั้นตอนนี้ไปได้เลย หรือตรวจสอบให้แน่ใจอีกครั้งผ่าน command line

node --version // ปัจจุบัน Cloud Functions รองรับเวอร์ชัน 18, 20, และ 22
npm --version

ส่วนใครที่ยังไม่ได้ลง หรือไม่พบเลขเวอร์ชัน ให้ไปที่ https://nodejs.org ดาวน์โหลดและติดตั้ง Node.js ตามแต่ละ OS ที่เราใช้งานให้เรียบร้อย (การติดตั้ง Node.js จะได้ npm มาด้วย)

2.3 ติดตั้ง Firebase CLI

การ deploy ฟังก์ชันใน Cloud Functions for Firebase จะต้องทำผ่าน Firebase CLI ดังนั้นให้เราติดตั้งตัว CLI ใน command line ด้วยคำสั่ง

npm install -g firebase-tools

วิธีตรวจสอบว่าเราติดตั้ง Firebase CLI เรียบร้อยแล้ว ให้ใช้คำสั่งด้านล่างนี้ ซึ่งถ้าเห็นตัวเลขเวอร์ชันก็คือ ผ่าน!

firebase --version

2.4 Initial โปรเจค

เราจะมายืนยันตัวตน เพื่อเข้าถึงโปรเจคใน Firebase ของเรากัน โดยให้ run คำสั่งด้านล่างนี้ใน command line แล้วจะมี browser เด้งมาให้เรา login ก็ให้เรา login ด้วย account ที่ใช้สร้างโปรเจคใน Firebase ไปก่อนหน้านี้

firebase login

ถัดไปให้สร้างโฟลเดอร์ขึ้นมา(ในตัวอย่างนี้ชื่อ bot) แล้วให้เข้าไปในนั้น

mkdir bot
cd bot

แล้วให้ init ตัว Cloud Functions for Firebase ด้วยคำสั่ง

firebase init functions

จะเจอหน้าตาแบบด้านล่างนี้ ก็ให้เลือก Use an existing project แล้วเลือกโปรเจคที่เราสร้างไว้

จากนั้นจะมีคำถามมาอีก 3 คำถามคือ

• จะใช้ภาษาอะไรในการพัฒนา โดยมี 3 ภาษาให้เลือก ได้แก่ JavaScript, TypeScript หรือ Python (ตัวอย่างในบทความจะใช้ JavaScript)
• จะใช้ ESLint เพื่อตรวจสอบ bug และ code style ไหม (optional)
• จะติดตั้ง dependencies ทันทีเลยไหม (จัดไปอย่าให้เสีย)

เพียงเท่านี้ก็ถือว่าเสร็จสิ้นขั้นตอนการ initial ละ โดยโครงสร้างของโปรเจคที่เราได้จะมีหน้าตาแบบนี้

/bot
+- .firebaserc    # Hidden file that helps you quickly switch between projects with `firebase use`
|
+- firebase.json  # Describes properties for your project
|
+- functions/     # Directory containing all your functions code
   |
   +- .eslintrc.json  # Optional file containing rules for JavaScript linting.
   |
   +- package.json  # npm package file describing your Cloud Functions code
   |
   +- index.js      # Main source file for your Cloud Functions code
   |
   +- node_modules/ # Directory where your dependencies (declared in package.json) are installed

3. ลองสร้างฟังก์ชัน HTTP Requests กับ Event Triggers ให้ทำงานร่วมกัน

3.1 สร้างฟังก์ชันสำหรับ Write และ Update ค่าใน Firestore

เริ่มจากไปเปิดไฟล์ /functions/index.js แล้วให้ import ตัว dependency ของ Cloud Functions 2nd Gen, Firestore และ Firebase Admin เข้ามา

const {onRequest} = require("firebase-functions/v2/https");
const {onDocumentCreated} = require("firebase-functions/v2/firestore");

const {initializeApp} = require("firebase-admin/app");
const {getFirestore} = require("firebase-admin/firestore");
initializeApp();

ถัดไปให้สร้างฟังก์ชัน addmessage() ที่เป็นแบบ HTTP Requests โดยโค้ดภายในจะมีการรับ query param ชื่อ text แล้วเอาไป write ลง Firestore ที่ messages/original จากนั้นก็ให้พ่น JSON ซึ่งเป็น id ของ document ออกมา

exports.addmessage = onRequest(async (req, res) => {
  const original = req.query.text;
  const writeResult = await getFirestore().collection("messages").add({original: original});
  res.json({result: `Message with ID: ${writeResult.id} added.`});
});

ถัดไปให้สร้างฟังก์ชัน makeuppercase() ที่เป็นแบบ Firebase trigger โดยการทำงานของฟังก์ชันนี้คือจะเฝ้าดู document ที่ถูกสร้างใหม่ขึ้นมา ซึ่งเมื่อมี doument ถูกสร้างใหม่จะส่งข้อมูลของ document นั้นมาที่ฟังก์ชันนี้ แล้วเราก็จะเอา value ที่อยู่ใน original ออกมา เข้าฟังก์ชัน toUpperCase() เพื่อทำให้ตัวหนังสือกลายเป็นพิมพ์ใหญ่ทั้งหมด จากนั้นก็ write กลับไปที่ Firestore

exports.makeuppercase = onDocumentCreated("/messages/{documentId}", (event) => {
  const original = event.data.data().original;
  const uppercase = original.toUpperCase();
  return event.data.ref.set({uppercase}, {merge: true});
});

3.2 Deploy และทดลองเรียกฟังก์ชัน

วิธีการ deploy ให้เราเปิด command line แล้วเข้าไปยังโฟลเดอร์ /functions ในโปรเจค จากนั้นให้ใช้คำสั่ง

firebase deploy --only functions

ซึ่งเมื่อ deploy เสร็จแล้ว ให้เราเข้าไปที่ Firebase console แล้วเลือกโปรเจคที่เราสร้าง จากนั้นให้คลิกเลือกเมนู Build > Functions เราก็จะเห็นฟังก์ชันที่เรา deploy ไปตรงนั้น

จากรูปเราจะ copy ตัว Endpoint URL จากฟังก์ชันที่เป็น HTTP Requests ออกมาเพื่อแล้วนำไปเปิดบน browser เพื่อทดสอบกัน

ซึ่งเมื่อเราเข้าไปดูใน Firestore ก็จะพบข้อมูลทั้งแบบ oginial และ uppercase

หมายเหตุ

• กรณีที่นำ Endpoint URL ที่ได้จากฟังก์ชันแบบ HTTP Requests ไปเปิด แล้วเจอว่าติด permission ให้ทำตามลิงค์นี้ เพื่อเปิดสิทธิ์ให้ทุกคนสามารถเปิด
• การจะใช้งาน Firestore ครั้งแรก จะต้องเข้าไปเลือก location ของ Firestore ใน Firebase console ก่อน โดยคลิกเมนู Build > Firestore Database

สรุป

จากตัวอย่างในข้อ 3 น่าจะทำให้ผู้อ่านทุกท่านเห็นภาพในการสร้างฟังก์ชันทั้งแบบ HTTP Requests และ Event Triggers รวมถึงการทำงานร่วมกันได้ชัดเจนมากขึ้น

หวังว่าบทความนี้จะทำให้ผู้อ่านทุกท่านได้รู้จัก Cloud Functions for Firebase และเกิดไอเดียในนำมันไปพัฒนาบริการฝั่งหลังบ้านเพื่อเชื่อมกับ Client ในแพลทฟอร์มต่างๆนะครับ

สุดท้ายนี้ เพื่อไม่ให้พลาดข่าวสารเกี่ยวกับ Firebase ก็ฝากติดตามเพจ Firebase Thailand ไว้ หรือถ้าใครอยากแชร์ความรู้ สอบถามเกี่ยวกับ Firebase ก็ไปโพสถามกันได้ที่ Firebase Developer Group Thailand ได้นะครับ แล้วพบกันใหม่ในบทความถัดไป สวัสดีครับ

รู้จัก Cloud Functions for Firebase 2nd Gen ตั้งแต่ Zero จนเป็น Hero was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

พูดถึงการรับส่งข้อมูลระหว่าง client และ server ในยุคนี้ เชื่อว่าหลายๆคนก็เลือกใช้บริการที่เป็น BaaS(Backend-as-a-Service) เพราะมันช่วยประหยัดเรื่องของ resource แถมลดเวลาในการพัฒนาได้เยอะ และผมเชื่อว่า Cloud Functions for Firebase ก็เป็นหนึ่งตัวเลือกที่นักพัฒนาไทยนิยมใช้กัน

โดยวิธีที่นักพัฒนาส่วนมากใช้ในการพัฒนาเพื่อรับส่งข้อมูลระหว่าง client และ server ด้วย Cloud Functions ที่ผมได้เจอมา ก็จะเป็นการสร้าง API แบบที่เรียกว่า HTTP Function ซึ่งรองรับ GET, POST, PUT, DELETE และ OPTIONS แต่…คุณรู้หรือไม่ว่า มันมีวิธีที่ง่ายกว่าในการพัฒนา ที่รู้จักกันในชื่อว่า Callable Function

Callable Function

คือฟังก์ชันที่ให้ client อย่าง Web, Android, iOS, Unity และ C++ สามารถเรียกใช้งานได้ตรงๆ โดยการ deploy ฟังก์ชันแบบ Callable Function คุณจะไม่ได้ Endpoint ของ API ออกมา แต่คุณสามารถเชื่อมต่อ client กับ server ได้ง่ายกว่าเดิมผ่าน SDK โดยความพิเศษใน Callable Function มีดังนี้

• Firebase Auth token, FCM token และ App Check token จะแนบมากับ request ให้อัตโนมัติ(ถ้ามีการ implement บริการเหล่านี้ไว้ที่ฝั่ง client)
• ถ้ามี Firebase Auth token หรือ App Check token แนบมากับ request มันจะถูก validate ให้อัตโนมัติที่ฝั่ง server ซึ่งแปลว่า ถ้า token ถูก revoke หรือ expire มา ตัว request นั้นจะถูก reject กลับไป

เอาหละครับ บทความนี้ผมจะพาทุกคนไปเรียนรู้เรื่องราวของ Callable Function ตามหัวข้อดังต่อไปนี้

1. การพัฒนาฟังก์ชันแบบ Callable Function
2. การเชื่อมต่อ Client เพื่อรับส่งข้อมูล
3. Tip สำหรับคนอยาก Run ใน Local ด้วย Firebase Emulator Suite

1. การพัฒนาฟังก์ชันแบบ Callable Function

1.1 เตรียมความพร้อม

ขั้นตอนนี้นักพัฒนาจะต้องมีโปรเจค Firebase, ต้องติดตั้ง Firebase CLI และ Cloud Functions ให้เรียบร้อยก่อน โดยใครที่ยังไม่เคยพัฒนาฟังก์ชันใน Cloud Functions มาก่อน ผมแนะนำให้อ่านและทำตามข้อ 2 ของบทความด้านล่างนี้

รู้จัก Cloud Functions for Firebase 2nd Gen ตั้งแต่ Zero จนเป็น Hero

แต่สำหรับใครที่มีประสบการณ์การพัฒนาฟังก์ชันใน Cloud Functions มาแล้วให้ข้ามไปข้อถัดไปได้เลย

1.2 เริ่มต้นเขียนฟังก์ชัน

โครงสร้างของ Callable Function จะมีรูปแบบที่ขึ้นต้นด้วย https.onCall และจะมี params คืนมา 1 ตัวคือ request โดยโค้ดที่จะเขียนลงไปใน index.js ก็จะเป็นประมาณนี้

const {onCall, HttpsError} = require("firebase-functions/v2/https");

exports.myCallable = onCall(async (request) => {
  // ...
})

โดยคุณสามารใช้ request.data เพื่อดึงค่าต่างๆที่ส่งมาจากฝั่ง client ได้

const msg = request.data.msg

และคุณยังสามารถดึงข้อมูลจาก Firebase Auth ออกมาได้ด้วย(ข้อมูลจะแนบมาอัตโนมัติ กรณีที่มีการใช้งานที่ฝั่ง client)

// Firebase Auth
const uid = request.auth.uid
const name = request.auth.token.name || null
const picture = request.auth.token.picture || null
const email = request.auth.token.email || null

1.3 การตอบกลับข้อมูล

การ return ข้อมูลกลับไปที่ client เราสามารถส่งข้อมูลกลับไปเป็นรูปแบบของ text หรือจะเป็นแบบ JSON ก็ได้ง่ายๆแบบนี้เลย

return {
  result: request.data.msg + ", Feb 14th, 2022"
};

1.4 การจัดการ Error

เราสามารถ throw error ไปพร้อมกับข้อความ กรณีที่ต้องการ return promise reject ได้ด้วย HttpsError(FunctionsErrorCode, ErrorMessage) เพื่อให้ฝั่ง client สามารถเข้าใจ error และนำไปแสดงผลได้ เช่น

if (!request.auth) {
  throw new HttpsError(
    'failed-precondition',
    'The function must be called while authenticated.'
  )
}

1.5 เลือก Location เพื่อเพิ่มความเร็ว

เมื่อคุณ deploy ฟังก์ชัน โค้ดของคุณจะถูกส่งไปทำงานที่เมกา(us-central1) เป็นค่าเริ่มต้น ซึ่งแน่นอนว่าการรับส่งข้อมูลจากไทยไปเมกาจะมี network latency เกิดขึ้น

ดังนั้นเพื่อลด latency ที่อาจเกิดขึ้น นักพัฒนาสามารถเลือก location ที่จะทำการ deploy โดยคำนึงถึงระยะทาง และบริการอื่นๆที่เกี่ยวข้องในฟังก์ชันนั้น เพื่อให้ได้ประสิทธิภาพดีที่สุด ซึ่งวิธีการหลังจากเลือก location ได้แล้วก็เพียงเพิ่ม region ไปในตอนประกาศฟังก์ชันแบบนี้

exports.myCallable = onCall({region: "asia-southeast1"}, async (request) => {
  // ...
})

1.6 Deploy

เมื่อเขียนโค้ดได้ตามต้องการแล้ว ก็ให้เปิด Terminal แล้วเข้าไปที่โฟลเดอร์ /functions ของโปรเจคจากนั้นก็เรียกคำสั่ง deploy ได้เลย

firebase deploy

2. การเชื่อมต่อ Client เพื่อรับส่งข้อมูล

การเชื่อมต่อเพื่อรับส่งข้อมูลระหว่าง client กับ Callable Function เราจะใช้ Firebase client SDK เข้ามาเป็นตัวกลางในการเชื่อมต่อ โดย minimum SDK ที่รองรับมีดังนี้

• Firebase SDK for Apple platforms 8.11.0
• Firebase SDK for Android 20.0.1
• Firebase JavaScript SDK 8.10.1
• Firebase Modular Web SDK v. 9.0

สำหรับตัวอย่างในบทความนี้ ผมจะทำการเชื่อมต่อด้วย Firebase Modular Web SDK นะครับ

สำหรับ JavaScript SDK v8, Android, iOS, Unity และ C++ ดูวิธีการเชื่อมต่อที่นี่

2.1 ลงทะเบียน Web app

ให้เข้าไปที่ Firebase console เลือกโปรเจคที่เราสร้างไว้ โดยเมื่อเข้าสู่หน้า Overview ให้คลิก Add appตามรูปด้านล่าง

ต่อไปให้คลิกเลือก Web

ตั้งชื่อ Web app ของเราให้ง่ายต่อการจดจำ แล้วกดปุ่ม Register app

ขั้นตอนถัดไป ให้เลือกวิธีการพัฒนาที่ถนัด โดยจะมีแบบ npm และ <script> (ตัวอย่างจะเลือกแบบ <script>) จากนั้นให้ copy ชุด JavaScript เอาไว้ แล้วกด Continue to console ได้เลย

2.2 เชื่อมต่อ Callable Function กับ SDK

จากโค้ดที่เรา copy มาจากขั้นตอนที่ 2.1 ให้เราเพิ่มโค้ดตามขั้นตอนทั้ง 4 นี้ในไฟล์ HTML ที่ต้องการ

สำคัญมาก: กรณี Callable Function ที่สร้างในข้อ 1 มีการระบุ location คุณจำเป็นต้องกำหนด location ให้ฝั่ง client ด้วยโดยการแก้ไขโค้ดด้านบนในบรรทัดที่ 24 เป็นดังนี้

const functions = getFunctions(app, "asia-southeast1");

สำหรับ JavaScript SDK v8, Android, iOS, Unity, C++ ดูวิธีกำหนด location ที่นี่

2.3 Deploy และ Demo

ถ้าโค้ดพร้อมแล้ว ก็ deploy โลด ปล.ถ้าใครยังไม่มีโฮสฟรีไว้ใช้ ผมนี่แนะนำ Firebase Hosting เลยครับ :)

รู้จัก Firebase Hosting ตั้งแต่ Zero จนเป็น Hero

เสร็จแล้วมาลองเอา URL ที่ได้ไปเปิดใน browser ดูผลลัพธ์กัน

3. Tip สำหรับคนอยาก Run ใน Local ด้วย Firebase Emulator Suite

เชื่อว่านักพัฒนาหลายคนที่ใช้ Firebase ต่างก็ใช้ Firebase Emulator Suite เพื่อทดสอบโปรเจคของตัวเองใน local เพราะมันรวดเร็ว แก้ปุ๊บเห็นผลปั๊บไม่ต้อง deploy ไม่กระทบข้อมูลใน Production

สำหรับ Callable Function ก็สามารถพัฒนาใน local ได้เช่นกัน เพียงแต่การ run ฝั่ง client ที่เชื่อมต่อ เราจะต้องมีการเขียนโค้ดเพิ่มเข้าไปนิสนึง โดยโค้ดจะอ้างอิงจากข้อ 2.2 บรรทัดที่ 13 ให้คุณเพิ่ม connectFunctionsEmulatorเข้าไป

import { getFunctions, httpsCallable, connectFunctionsEmulator } from "https://www.gstatic.com/firebasejs/9.6.6/firebase-functions.js";

และเพิ่มคำสั่งด้านล่างนี้ ต่อจากบรรทัดที่ 24

const functions = getFunctions(app);
if (location.hostname === "localhost") { 
  connectFunctionsEmulator(functions, "localhost", 5001);
}

สำหรับ JavaScript SDK v8, Android และ iOS ดูวิธีกำหนด config ที่นี่

สรุป

เป็นอย่างไรบ้างครับสำหรับ Callable Function นอกจากจะพัฒนาง่ายแล้ว ส่วนตัวผมยังชอบที่เราไม่ต้องระบุ Endpoint ของ API ลงไปในโค้ดของฝั่ง client เลย(ดูเท่ และปลอดภัยขึ้นไปอีกนิสนึง)

ก่อนจากกันไป หากคุณชอบบทความนี้ก็ฝากกด Clap เป็นกำลังใจให้ผม หากมันเป็นประโยชน์ก็ฝากกด Share ให้เพื่อนของคุณ และหากคุณไม่อยากพลาดบทความถัดๆไปของซีรี่ย์ Zero to Hero ก็ฝากกด Follow: Firebase Thailand ไว้ด้วยนะครับ สำหรับวันนี้ต้องขอตัวลาไปก่อน แล้วพบกันใหม่บทความหน้าครับ

รู้จัก Callable Function ใน Cloud Functions for Firebase ตั้งแต่ Zero จนเป็น Hero was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

นักพัฒนาที่ใช้งาน GitHub อยู่น่าจะรู้จัก GitHub Actions บริการที่เข้ามาช่วยจัดการ Development workflow ใน Repo ของเรา ให้มีระบบ CI/CD แบบอัตโนมัติได้

ด้วยเสียงตอบรับที่ดีของบริการดังกล่าว ทีม Firebase จึงไม่รอช้าที่จะออกฟีเจอร์ใหม่ซึ่งเป็นการ Integrate กันระหว่าง Firebase Hosting และ GitHub Actions เพื่อมาช่วยให้การ deploy เว็บของเรามีความ automate โดยที่นักพัฒนาไม่จำเป็นต้องมีความรู้ในการติดตั้ง GitHub Actions มาก่อน เพราะ Firebase CLI เค้าจะจัดให้

การ Deploy จาก GitHub Actions ไปยัง Firebase Hosting

การ deploy จาก GitHub Actions ที่จะแสดงในบทความนี้ จะเป็นแบบ default ที่ได้หลังจากการติดตั้ง ซึ่งจะมีด้วยกัน 2 รูปแบบ

Preview Channel

เกิดจากการเปิดหรือแก้ไข Pull Request(PR) โดยระบบจะ deploy ไปยัง Preview channel ของ Firebase Hosting ซึ่งผลลัพธ์เราจะได้ temporary URL ซึ่งแต่ละ PR จะได้ URL ที่แตกต่างกัน

หมายเหตุ: การแก้ไขโค้ดใน PR เดิม โค้ดจะถูก deploy ไปยัง Preview URL เดิม

Live Channel

เกิดจากการ Merge PR หรือ Push โค้ดเข้าไปที่ main repo โดยระบบจะ deploy ไปยัง Live channel ของ Firebase Hosting หรือเรียกง่ายๆว่าขึ้น Production นั่นเอง

มาถึงตรงนี้ เชื่อว่าทุกคนน่าจะคันไม้คันมือกันแล้ว อย่าได้ช้าที เราไปลงมือทำแบบ Step by Step กับ 7 ขั้นตอนกันเลย!

1. เตรียม GitHub Repository

ให้เราเตรียม GitHub repo โดยจะมาจากการสร้างใหม่ หรือจะใช้ repo ที่มีอยู่แล้วก็ได้ ซึ่งจะเป็น repo แบบส่วนตัว หรือ organization ก็ได้ จากนั้นก็ให้ clone มาไว้ที่เครื่องของเรา

หมายเหตุ: สิทธิ์ของ repo ที่จะนำมาใช้จะต้องเป็นสิทธิ์ admin เท่านั้น

ถัดไปเราจะสร้าง branch ใหม่ใน local โดยผมจะตั้งชื่อว่า new-feature และเราจะลุยกันต่อใน branch นี้ครับ

2. สร้าง Firebase Project

ให้เข้าไปที่ Firebase console และ sign in ด้วย Google account จากนั้นกด Add project

ตั้งชื่อโปรเจคให้เรียบร้อย แล้วกดปุ่ม Continue จากนั้นให้ข้ามขั้นตอนการตั้งค่า Google Analytics ไปก่อน เนื่องจากเราไม่ได้ใช้ในโปรเจคนี้

3. เปิดใช้งาน Firebase Hosting API

เนื่องจากการ GitHub Actions จะทำการ deploy โค้ดของเราผ่านทาง REST API ไปยัง Firebase Hosting ดังนั้นต้องให้แน่ใจว่าบริการนี้ถูกเปิดใช้งานแล้ว โดยให้เราไปที่หน้ารวม Library ใน Google Cloud console จากนั้นให้เลือกโปรเจคเดียวกับที่เราสร้างไว้ใน Firebase console แล้วค้นห้าคำว่า Firebase Hosting API ก็จะเจอหน้าจอ

ให้กดปุ่ม Enable เพื่อเปิดใช้บริการ โดยหากปุ่มนี้แสดงคำว่า Manage นั่นแปลว่าเราได้เปิดใช้งานไว้แล้ว

4. ติดตั้ง Node.js และ Firebase CLI

4.1 ติดตั้ง Node.js

เนื่องจาก Firebase CLI จำเป็นต้องมี Node.js และ npm(มาพร้อมกับการติดตั้ง Node.js) ดังนั้นให้เข้าไปที่เว็บไซต์ nodejs.org แล้วดาวน์โหลด Node.js เวอร์ชันที่เป็น LTS หรือ Current มาติดตั้งให้เรียบร้อย

เมื่อติดตั้งเสร็จแล้ว ให้เปิด Terminal มาทดสอบด้วยคำสั่งด้านล่างนี้ ซึ่งถ้าสำเร็จจะเห็นตัวเลขเวอร์ชันของทั้งคู่

node --version 
npm --version

4.2 ติดตั้ง Firebase CLI

ต่อกันที่ Terminal ให้เรา run คำสั่ง

npm install -g firebase-tools

หมายเหตุ: หากพบปัญหาในการติดตั้งในขั้นตอนนี้ คุณจำเป็นตัองตั้งค่า npm permission ในเครื่องซะก่อน

จากนั้นให้ตรวจสอบความเรียบร้อยด้วยคำสั่งด้านล่างนี้ ซึ่งถ้าผ่านจะต้องเห็นเลขเวอร์ชัน

firebase --version

5. Initial ตัว Firebase Hosting และ GitHub Actions

เริ่มต้นให้ run คำส่ังด้านล่างนี้ ใน Terminal โดย browser จะเปิดขึ้นมาแล้วให้คุณ sign in ด้วย account เดียวกับที่สร้างโปรเจคใน Firebase โดยหากสำเร็จจะเห็นอีเมลตัวเองปรากฎอยู่ใน Terminal

firebase login

ถัดไปให้ shell ผ่าน Terminal เข้าไปยัง root ของโฟลเดอร์ที่เรา clone มาจาก GitHub แล้ว run คำสั่ง

firebase init hosting

หมายเหตุ: หากเคยติดตั้ง Firebase Hosting มาก่อนหน้านี้ ให้ใช้คำสั่ง firebase init hosting:github

เลือก Use an existing project แล้ว Enter เบาๆ จากนั้นจะเจอชื่อโปรเจคที่เราได้สร้างไว้ ก็กดเลือกแล้ว Enter ต่อเลย แล้วจะเจอชุดคำถามตามนี้

• ตั้งชื่อโฟลเดอร์ที่เก็บไฟล์เว็บของเราว่า public ไหม: ถ้าเอาก็กด Enter ได้เลย
• จะตั้งค่า single-page เว็บไหม: ตอบ N ตามคำแนะนำ
• ติดตั้งการ deploy ด้วย GitHub ไหม: ตรงนี้ตอบ y นาจา

หลังตอบ y ตัว browser จะเปิดขึ้นมา ก็ให้เรา sign in ด้วย GitHub account ให้เรียบร้อย เสร็จแล้วก็กลับมาที่ Terminal จะพบว่าให้เราระบุ repo ที่ต้องการเชื่อมต่อกับ GitHub Actions ในรูปแบบ user/repository

หลังจากกด Enter ชื่อ repo เราไป ตัว Firebase CLI ก็จะไปสร้าง service account สำหรับการอนุญาตให้ GitHub Actions ทำการ deploy ไฟล์ขึ้นไป Firebase Hosting ได้ โดยสามารถเข้าไปดูที่เมนู Settings->secrets ใน GitHub repo ของเรา

กลับมาที่ Terminal จะ 2 คำถามสุดท้ายละ

• จะให้ run script อะไรเพิ่มเติมก่อนการ deploy ไหม เช่น script สำหรับ build หรือ test: ถ้าไม่มีก็ให้ตอบ N ไป
• ถ้า Merge PR จะให้ deploy ขึ้น Live channel เลยไหม: ตอบ Y
• ฺBranch ที่จะเอามาเชื่อมกับ Live channel ชื่ออะไร: ถ้าใช้ main ก็แค่ Enter ไป

เสร็จแล้วก็แอบไปส่องไฟล์ในโฟลเดอร์ดูหน่อย จะสั่งเกตเห็นโฟลเดอร์ที่เป็น hidden ชื่อ .github เข้าไปเลยจะเจอโฟลเดอร์ workflows แล้วก็เข้าไปอีก จะเจอไฟล์ 2 ไฟล์ที่มีนามสกุล yml นั่นหละครับคือ script สำหรับการรัน GitHub Actions ซึ่งเราไม่ต้องเขียนเองเลย สบ๊าย!

6. ทดลองเปิด PR

หลังจากเราได้ Initial โปรเจคเราเรียบร้อย ใน branch ที่ชื่อ new-feature ก็ให้เรา commit โค้ดทั้งหมด และ publish ตัว branch นี้ขึ้น GitHub ไปเลย

จากนั้นก็เข้าไปที่ Repo ของเราใน GitHub เราก็จะเห็น notice ว่า branch ใหม่เรามาแว้ว เอ้า รอรัยอะ กดปุ่มเขียวๆที่ชื่อ Compare & pull request โลด

จากนั้นก็ใส่ comment ตามสะดวกแล้วกด Creat pull request ต่อเลย ที่เหลือก็รอเวลาเพียงชั่วเคี้ยวหมากแหลก หากสำเร็จคุณก็จะเห็นลิงก์ของ Preview channel ปรากฎล้าาาว

สุดท้ายก็เอา Preview URL มาลองเปิดหน่อยซิ…Ta Da!

หมายเหตุ: Preview URL จะสามารถใช้งานได้ 7 วัน(default) หากต้องการเพิ่มหรือลดเวลา สามารถตั้งค่า expires ได้ที่ไฟล์ firebase-hosting-pull-request.yml ในโฟลเดอร์ .github/ (ต่ำสุด 1h สูงสุด 30d)

7. ทดลอง Merge PR เข้า Main Repository

ขั้นตอนสุดท้าย เมื่อเราโอเคกับ PR ที่เปิดเข้ามาแล้ว ก็ได้เวลา Merge มันเข้าไปที่ main ซึ่งเป็น branch หลักของเรา…ในหน้า PR ด้านล่างจะมีปุ่ม Merge pull request อยู่ กดมันเบาๆ

จากนั้นไปติดตามสถานะการ build และ deploy มันใน tab ที่ชื่อ Actions

ในหน้านี้จะสังเกตเห็นสถานะของงาน ตั้งแต่ตอนเปิด PR และตอน Merge โดยจะแบ่งสถานะออกเป็น 3 สี

• 🟡 กำลังทำงาน
• 🔴 เกิดข้อผิดพลาด
• 🟢 เสร็จสมบูรณ์

ซึ่งเราสามารถกดเข้าไปดูรายละเอียดภายในแต่ละงานได้ เผื่อในกรณีที่เกิดข้อผิดพลาดจะได้ทราบสาเหตุว่าเกิดจากอะไร

เอาหละครับ และนี่คือ URL ของ Live channel ของเราในบทความนี้ เย้!

สรุป

ชอบกันไหมครับกับฟีเจอร์ใหม่ที่มาแนะนำกันในบทความนี้ ส่วนตัวผมชอบตอนที่เปิด PR แล้วได้ Preview URL มานี่เหมาะมากกับการนำไปทดสอบ หรือส่งไปให้ลูกค้า UAT เพราะเราไม่ต้องไปนั่งหา domain ใหม่ รู้ที่มาที่ไปของ URL ว่ามาจาก PR ไหน แถมควบคุมเวลาการ expire ได้ด้วย

สำหรับ GitHub Actions จะมีการคำนวนการใช้งานจากระยะเวลาที่มันทำงาน โดยแพ็คเกจ Free ก็ให้เราใช้ ฟรี เลยสำหรับ Public repo ส่วนถ้าเป็น private repo จะให้ใช้ฟรีได้ 2,000 นาที/เดือน ซึ่งหากใครสนใจใช้เกินกว่านี้ก็ลองดูรายละเอียดของ Price plan นะครับ

รู้จัก Firebase Hosting ตั้งแต่ Zero จนเป็น Hero

ก่อนจากกันไป ขอฝากชาว Firebasers ให้กดติดตาม Firebase Thailand กันด้วยนะครับ เพื่อที่ทุกท่านจะได้ไม่พลาดบทความตอนใหม่ๆ แล้วพบกันใหม่บทความหน้าราตรีสวัสดิ์พี่น้องนักพัฒนาชาวไทย

Deploy เว็บของคุณแบบไร้รอยต่อด้วย Firebase Hosting และ GitHub Actions was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

จึงทำให้ในปัจจุบันได้มีการนำ Continuous Integration หรือ CI มาใช้ควบคู่ไปกับการเขียนเทสให้กับโค้ดในซอฟต์แวร์นั้น ๆ ด้วย เพื่อทำให้ซอฟต์แวร์สามารถทำงานได้ถูกต้องอยู่เสมอ ไม่ว่าโค้ดเหล่านั้นจะอยู่มานานเท่าไร หรือมีการเปลี่ยนคนเขียนโค้ดนั้นไปแค่ไหน

การเขียนเทสบน Android

นิยมแบ่งออกเป็น 2 ส่วนใหญ่ ๆ ด้วยกัน คือส่วนที่เป็น Unit Test สำหรับทดสอบ Logic ที่อยู่ในโค้ด และส่วนที่เป็น UI Test เพื่อทดสอบ​การแสดงผลภายในแอป

โดย Unit Test จะใช้ JVM ในการทำงาน จึงสามารถรันบนเครื่องที่ใช้เขียนโค้ดได้เลย แต่สำหรับ UI Test จะต้องใช้อุปกรณ์แอนดรอยด์ (Physical Device หรือ Emulator ก็ได้) เพื่อทำการทดสอบ

สำหรับ UI Test ที่ต้องใช้อุปกรณ์แอนดรอยด์เพื่อทดสอบ ก็จะมีเรื่องของ Fragmentation เข้ามาเกี่ยวข้องด้วย ทำให้การใช้อุปกรณ์แอนดรอยด์เพียงเครื่องเดียวอาจจะไม่เพียงพอต่อการทดสอบ จึงต้องมีการใช้อุปกรณ์แอนดรอยด์มากกว่าหนึ่งเครื่องที่มีสเปคที่แตกต่างกัน เพื่อให้ครอบคลุมกับเครื่องของผู้ใช้ให้หลากหลาย

แต่การหาอุปกรณ์เหล่านั้นมาทดสอบก็อาจจะไม่ใช่เรื่องง่ายสำหรับทุกคนเสมอไป จึงทำให้ทาง Firebase มีบริการที่ชื่อว่า Firebase Test Lab เพิ่มเข้ามา โดยทำหน้าที่เป็น Device Farm เพื่อให้นักพัฒนาส่งแอปขึ้นไปทดสอบได้

ข้อดีคือนักพัฒนาไม่ต้องเสียเวลาไปสร้าง Device Farm เพราะ Firebase Test Lab ได้เตรียมไว้ให้หมดแล้ว ไม่ว่าจะเป็นการทำ Device Matrix, การบันทึกหน้าจอระหว่างรันเทส, การแสดง Log หรือ Stack Trace, และอื่น ๆ อีกมากมาย

และ Firebase Test Lab จะมีค่าบริการในการใช้งานด้วย ซึ่งจะคิดตามระยะเวลาที่ใช้ในการทดสอบแอป โดยแยกราคาระหว่าง Physical Device กับ Virtual Device (Emulator)

การทำ Continuous Integration สำหรับ Android

ในปัจจุบันสามารถทำได้หลายวิธี ไม่ว่าจะสร้างขึ้นมาบนระบบของตัวเองอย่างการใช้ Jenkins หรือการใช้ 3rd Party Service อย่าง Travis CI หรือ Circle CI รวมไปถึง Git Repository แต่จะเจ้าที่รองรับ CI/CD ในตัว ซึ่งแต่ละแบบก็จะมีข้อดี ข้อเสีย และความเหมาะสมที่แตกต่างกันออกไป

โดยบทความนี้เลือกที่จะใช้ GitHub Actions ด้วยเหตุผลที่ว่า GitHub เป็น Git Repository ที่นักพัฒนาทั่วโลกนิยมใช้งานมากที่สุด จึงเหมาะกับนักพัฒนาทุก ๆ คน ไม่ว่าจะเป็นโปรเจคของบริษัท, โปรเจคที่เป็น Open Source, หรือโปรเจคส่วนตัวก็ตาม

โปรเจคตัวอย่างที่จะใช้ในบทความนี้

ถ้าโปรเจคของคุณมีการเขียนเทสไว้แล้ว ก็สามารถใช้โปรเจคนั้นทำไปพร้อม ๆ กับบทความนี้ได้เลย แต่ถ้ายังไม่มีก็สามารถใช้โปรเจคตัวอย่างของผมได้เช่นกัน เป็นโปรเจคที่เขียนขึ้นมาแบบง่าย ๆ เพื่อให้มีทั้ง Unit Test และ UI Test

akexorcist/EvenOdd

สามารถ Fork และ Clone เพื่อเอาไปทำตามได้เลย โดยให้ใช้ Branch ที่ชื่อ main ซึ่งเป็น Branch ที่ยังไม่ได้เพิ่ม .yml ของ GitHub Actions เข้าไปในโปรเจค

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

• เลขคู่ : แสดงคำว่า “is even” และคำว่า “even” จะเป็นสี Indigo 400 (#5C6BC0)
• เลขคี่ : แสดงคำว่า “is odd” และคำว่า “odd” จะเป็นสี Pink 400 (#EC407A)

โดย Unit Test จะอยู่ใน MainViewModelTest.kt และ UI Test จะอยู่ใน MainActivityUiTest.kt

สร้าง Workflow ให้กับ GitHub Actions

ในการสร้าง Workflow ให้กับ GitHub Actions จะกำหนดผ่าน YAML โดยเพิ่มไฟล์ .yml ไว้ใน <your_project>/.github/workflow/ ซึ่งผู้อ่านสามารถตั้งชื่อไฟล์ได้ตามใจชอบ

ในขั้นตอนนี้จะเพิ่มไฟล์ผ่าน Editor ของ GitHub Actions หรือใน Android Studio ก็ได้

โดยผมจะขอตั้งชื่อไฟล์ว่า android.yml

และเพื่อให้ผู้อ่านเข้าใจ Script ในแต่ละส่วนมากขึ้น ผมจะค่อย ๆ เพิ่มและอธิบาย Script ในแต่ละส่วนให้นะ

เริ่มจาก Script พื้นฐานที่จำเป็นสำหรับ Workflow

ซึ่งจะมีลักษณะแบบนี้

• name : ชื่อของ Workflow ที่สามารถกำหนดได้ตามใจชอบ
• on : กำหนด Trigger Event ที่จะใช้ Workflow ทำงาน โดยในตัวอย่างนี้ผมกำหนดให้ทำงานตอนที่มีการ Push หรือ Pull Request ใน Branch ที่ชื่อว่า main นั่นเอง
• jobs : การทำงานต่าง ๆ ที่จะให้ทำใน Workflow ตัวนี้ โดยผมจะแบ่งเป็น 3 Job ด้วยกันคือ test, apk, และ firebase

Job แต่ละตัวทำหน้าที่อะไรกันบ้าง?

• test : รัน Unit Test
• apk : Build APK สำหรับ UI Test
• firebase : ส่ง APK ที่ได้จาก apk ขึ้นไปรัน UI Test บน Firebase Test Lab

ดังนั้นเราจะให้ firebase ทำงานหลังจาก apk ส่วน test แยกออกมาจาก Job อื่น

โดยทุก Job จะกำหนดให้รันอยู่บน Ubuntu เวอร์ชันล่าสุด (Latest) และใช้ JDK เวอร์ชัน 1.8 ซึ่งจะต้องกำหนดไว้ใน Job แต่ละตัวอีกที

กำหนด Script ให้กับ Job สำหรับ Unit Test

ใน Job สำหรับ Unit Test จะมี Script ดังนี้

• Checkout
• ติดตั้ง JDK 1.8
• กำหนดให้ gradlew เป็น Executable File
• ใช้คำสั่ง ./gradlew test เพื่อรัน Unit Test

กำหนด Script ให้กับ Job สำหรับ Build APK เพื่อใช้ใน UI Test

การสร้างไฟล์ APK สำหรับ UI Test นั้น จะต้องสร้างไฟล์ APK ขึ้นมา 2 ไฟล์ด้วยกัน

• APK ของแอป
• APK สำหรับ Instrumented Test (UI Test)

โดยอุปกรณ์แอนดรอยด์จะต้องติดตั้ง APK ทั้ง 2 ไฟล์นี้ถึงจะรัน UI Test ได้

และใน Job สำหรับ Build APK เพื่อใช้ใน UI Test จะมี Script ดังนี้

• Checkout
• ติดตั้ง JDK 1.8
• กำหนดให้ gradlew เป็น Executable File
• ใช้คำสั่ง ./gradlew assembleDebug เพื่อ Build Debug APK
• Upload Debug APK ไปเก็บไว้ใน Artifact เพื่อส่งต่อให้ Job ถัดไป โดยกำหนดชื่อเป็น app-debug
• ใช้คำสั่ง ./gradlew assembleDebugAndroidTest เพื่อ Build Debug Instrumented APK
• Upload Debug Instrumented APK ไปเก็บไว้ใน Artifact เพื่อส่งต่อให้ Job ถัดไป โดยกำหนดชื่อเป็น app-debug-androidTest

กำหนด Script ให้กับ Job สำหรับรัน UI Test บน Firebase Test Labs

การเรียกใช้งาน Firebase Test Lab บน GitHub Actions จะเรียกผ่าน Google Cloud ซึ่งจะต้องใช้ข้อมูลจาก Firebase อยู่ 2 อย่างด้วยกัน

• Project ID ของ Firebase Project ที่ต้องการใช้งาน Firebase Test Lab
• Service Key ที่เป็น Private Key จาก Firebase Project ที่ Encode ด้วย Base64

โดยค่าทั้ง 2 ตัวนี้จะไม่กำหนดไว้ใน Script โดยตรง เพราะเป็นข้อมูลสำคัญในการเข้าใช้งาน Firebase Project นั้น ๆ แต่จะเรียกผ่าน Repository Secrets ที่กำหนดไว้ใน Repository Settings บน GitHub แทน ซึ่งจะพูดถึงเรื่องนี้ทีหลัง

และใน Job สำหรับรัน UI Test บน Firebase Test Lab จะมี Script ดังนี้

• Checkout
• Download Debug APK ที่อยู่ใน Artifact ที่ใช้ชื่อว่า app-debug
• Download Debug Instrumented APK ที่อยู่ใน Artifact ที่ใช้ชื่อว่า app-debug-androidTest
• เข้าใช้งาน Google Cloud เวอร์ชัน 270.0.0 ด้วย Service Key ที่กำหนดไว้ใน Repository Secrets นั้น ๆ
• กำหนด Project ID ของ Firebase ที่จะเรียกใช้งาน Firebase Test Lab
• สั่งให้ Firebase Test Lab เริ่มทำงาน โดยใช้ไฟล์ APK ที่ Download มาจาก Artifact ในขั้นตอนก่อนหน้านี้

จะเห็นว่าคำสั่งรัน UI Test บน Firebase Test Lab จะต้องกำหนด --type เป็น Instrumentation ด้วย และ Path ของไฟล์ APK ทั้ง 2 ไฟล์จะถูกกำหนดไว้ใน --app และ --test โดยอุปกรณ์แอนดรอยด์ที่ใช้รัน UI Test จะเป็น Pixel 2 ที่เป็น API Level 30

อย่าเพิ่ง Push ขึ้น Repository นะ

ยังมีขั้นตอนอื่น ๆ ที่ต้องทำให้เรียบร้อยก่อน ดังนั้นอย่าเพิ่ง Push Script ชุดนี้ขึ้น Repository ไม่เช่นนั้น Workflow จะเริ่มทำงานทันที (แล้วก็ Failed)

การกำหนดอุปกรณ์แอนดรอยด์เพื่อใช้ทดสอบบน Firebase Test Lab

บน Firebase Test Lab จะสามารถกำหนดอุปกรณ์แอนดรอยด์ที่ต้องการใช้ทดสอบได้อยู่ 2 แบบด้วยกันคือ

• กำหนดข้อมูลของเครื่องโดยตรง
• กำหนดด้วย Device Matrix

จาก Script ก่อนหน้าจะเห็นว่าผมได้ระบุเครื่องที่ต้องการทดสอบเป็น Pixel 2 เลย ซึ่งวิธีนี้จะต้องกำหนด Model ID ของเครื่องที่ต้องการลงไปใน --device โดย Pixel 2 จะมี Model ID เป็น Pixel2

อุปกรณ์แอนดรอยด์บน Firebase Test Lab สามารถเปลี่ยนแปลงได้เสมอ

ถ้าอยากจะรู้ว่ามีอุปกรณ์แอนดรอยด์รุ่นไหนให้ใช้งานได้บ้าง จะต้องใช้คำสั่ง gcloud firebase test android models list จากเครื่องของเราเอง เพื่อแสดงรายชื่ออุปกรณ์แอนดรอยด์ทั้งหมดใน Firebase Test Lab

หรือจะดูรายชื่ออุปกรณ์แอนดรอยด์จาก Gist ของผมก็ได้นะ

ในกรณีที่อยากจะทดสอบบนอุปกรณ์แอนดรอยด์มากกว่า 1 เครื่องก็ให้กำหนด --device เพิ่มเข้าไปเท่าที่ต้องการได้เลย

gcloud firebase test android run
  --type instrumentation
  --app app-debug/app-debug.apk
  --test app-debug-androidTest/app-debug-androidTest.apk
  --device model=flame,version=30,locale=en,orientation=portrait
  --device model=x1q,version=29,locale=en,orientation=portrait
  --device model=mata,version=25,locale=en,orientation=portrait

ส่วนการกำหนดอุปกรณ์แอนดรอยด์ด้วย Device Matrix จะมีขั้นตอนที่ยุ่งยากกว่านิดหน่อย เพราะจะต้องสร้างไฟล์ YAML เอาไว้อีกชุดแทน สามารถเข้าไปดูรายละเอียดเพิ่มเติมได้ที่

gcloud topic arg-files | Cloud SDK Documentation | Google Cloud

เตรียม Project ID กับ Service Key ของ Firebase Project ไว้ใน Repository Secrets

อย่างที่บอกไปก่อนหน้านี้ว่า Project ID กับ Service Key ไม่ควรใส่ไว้ในโปรเจคโดยตรง แต่จะเก็บข้อมูลเหล่านี้ไว้ใน Repository Secrets ที่อยู่ใน Repository Settings บน GitHub

โดยข้อมูลทั้งสองนี้ สามารถเข้าไปดูได้ใน Project Settings ใน Firebase Project ของเราได้เลย

Project ID

จะอยู่ใน Genetal > Your project > Project ID

Service Key

จะอยู่ใน Service accounts > Firebase Admin SDK แล้วกดปุ่ม Generate new private key

เมื่อกดปุ่มดังกล่าวจะมี Popup แสดงขึ้นมาเพื่อยืนยันอีกครั้ง ให้กดปุ่ม Generate key แล้วหน้าเว็ปจะให้ดาวน์โหลดไฟล์ Private Key ในรูปของ JSON

โดยจะต้องนำข้อมูล JSON ดังกล่าวไป Encode แบบ Base64 ก่อน

ewogICJ0eXBlIjogInNlcnZpY2VfYWNjb3VudCIsCiAgInByb2plY3RfaWQiOiAiYWtleG9yY2lzdC1leHBlcmltZW50IiwKICAicHJpdmF0ZV9rZXlfaWQiOiAiZjJlMjRkYjlhNGNkODIzZmU3YjE1YjUy...

อย่างของผมจะใช้ Online Tools เพื่อความสะดวก

Base64 encode/decode online

ใส่ข้อมูลไว้ใน Repository Secrets

เปิด Repository บน GitHub ขึ้นมา แล้วเข้าไปที่ Settings > Secrets แล้วกดปุ่ม New repository secret เพื่อกำหนดข้อมูลของ Project ID และ Service Key ลงไป โดยที่

• Project ID : ให้กำหนดชื่อว่า FIREBASE_PROJECT_ID
• Service Key : ให้กำหนดชื่อว่า FIREBASE_SERVICES_KEY

โดยจะเป็นชื่อที่กำหนดไว้ใน Script ของ Workflow ในตอนแรกนั่นเอง

เพิ่ม Editor Role ให้กับ Firebase Admin SDK Service Agent

เนื่องจากในตอนนี้ Service Key ที่กำหนดไว้ใน Repository Secrets จะเป็นของ Firebase Admin SDK Service Agent ที่ยังไม่มี Permission ในการเรียกใช้งาน Firebase Test Lab โดยตรง

ดังนั้นจะต้องเพิ่ม Role ที่ชื่อว่า “Editor” ให้กับ Firebase Admin SDK Service Agent ใน Google Cloud เสียก่อน

โดยเข้าไปที่ Google Cloud Console — IAM แล้วเลือก Firebase Project ที่จะใช้ Firebase Test Lab

Google Cloud Platform

จากนั้นให้กดปุ่ม Edit (สัญลักษณ์ดินสอ) ที่อยู่ขวามือสุดของ Member ที่ชื่อว่า “firebase-adminsdk” เพื่อแก้ไข Permission

จะมีหน้าต่าง Edit permissions แสดงขึ้นมาที่ฝั่งขวามือ ให้กดปุ่ม “ADD ANOTHER ROLE” เพื่อเพิ่ม Role ที่ชื่อว่า “Editor - Edit access to all resources” (สามารถพิมพ์ที่แถบค้นหาได้เลย) จากนั้นให้กดปุ่ม “Save” ให้เรียบร้อย

เปิดใช้งาน Cloud Tool Results API บน Google Cloud

นอกจากการเพิ่ม Role ให้กับ Firebase Admin SDK Service Agent แล้ว จะต้องเปิดใช้บริการ API ที่ชื่อว่า Cloud Tool Results API ด้วย

โดยเข้าไปที่ Google Cloud Console — Cloud Tool Results API

Google Cloud Platform

แล้วกดปุ่ม “Enable” เพื่อเปิดใช้งาน Cloud Tool Results API ให้กับ Firebase Project ของเรา

ในที่สุด GitHub Action ก็พร้อมทำงานแล้ว

ตอนนี้ผู้อ่านสามารถ Push Script ของ Workflow ขึ้น Repository ได้แล้ว และเมื่อ Push ขึ้นไปเรียบร้อย ให้ลองเข้าไปที่ “Actions” ของ Repository บน GitHub ก็จะเห็นว่า Workflow จะเริ่มทำงานโดยอัตโนมัติตามที่ได้กำหนดไว้ใน Script

เมื่อ Workflow ทำงานจนถึง Job ที่รัน UI Test บน Firebase Test Lab แล้ว ให้ลองเปิด Firebase Console ดู ก็จะเห็นว่ามี Test matrix แสดงขึ้นมา ซึ่งเป็น UI Test ที่มาจาก Workflow ใน GitHub Actions นั่นเอง

และหลังจากนี้เมื่อมี Push หรือ Pull Request ใด ๆ เข้าไปใน Branch นี้ก็จะทำให้ Workflow เริ่มทำงานโดยอัตโนมัติเพื่อรัน Unit Test และ UI Test ของโปรเจคเราเพื่อทดสอบว่าโค้ดทั้งหมดยังสามารถทำงานได้ถูกต้องหรือไม่

เรื่องที่ควรรู้เกี่ยวกับ Repository Secrets

ในการกำหนดค่า Project ID และ Service Key ของ Firebase Project ไว้ใน Repository Secrets เพื่อเรียกใช้งาน Firebase Test Lab จะใช้งานได้เฉพาะ Workflow Runner ท่ีมาจาก Repository นั้น ๆ เท่านั้น

นั่นหมายความว่าในกรณีที่มีคนอื่น Fork Repository ไป แล้วเปิด Pull Request กลับเข้ามา ก็จะไม่สามารถใช้งาน Firebase Test Lab ของเราได้ เพราะเป็น Workflow Runner ที่มาจาก Forked Repository จึงไม่สามารถเข้าถึง Project ID และ Service Key ที่อยู่ใน Original Repository ได้

ยินดีด้วยครับ ตอนนี้โปรเจคของคุณมี Continuous Integration ที่สร้างด้วย GitHub Actions และ Firebase Test Lab เรียบร้อยแล้ว 🔥🔥

โดยสามารถสรุปขั้นตอนทั้งหมดได้ดังนี้

• เตรียม Script สำหรับ Workflow ของ GitHub Actions ไว้ในแอนดรอยด์
• เตรียม Project ID และ Service Key ของ Firebase Project ไว้ใน Repository Secrets
• เพิ่ม Editor Role ของ Firebase Admin SDK Service Agent ใน IAM บน Google Cloud Console
• เปิดใช้งาน Cloud Tool Resuls API ใน Library บน Google Cloud Console
• Push Script ของ Workflow ที่เตรียมไว้ในตอนแรกขึ้น Repository บน GitHub
• รอดูผลลัพบน GitHub Actions และ Firebase Test Lab

และเมื่อโปรเจคของคุณมี Continuous Integration แล้ว ก็อย่าลืมหมั่นเขียนเทสทุกครั้งเวลาที่มีการเขียนโค้ดเพิ่มเข้าไป อย่าให้สิ่งที่ทำทั้งหมดในบทความนี้ต้องไร้ค่า เพียงเพราะว่าไม่อยากเสียเวลาเขียนเทสให้กับโค้ดของเราเลยนะ

แหล่งข้อมูลอ้างอิง

• GitHub Actions: Firebase Test Lab [Medium]
• Firebase Test Labs
• GitHub Actions

มาสร้าง CI บน Android โดยใช้ GitHub Actions เพื่อทำ UI Test ด้วย Firebase Test Lab แบบเท่ ๆ กัน was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.

To deploy application static assets to Firebase Hosting, It is not too hard if you are familiar with Firebase CLI. By the way, if you are in development environment, using Firebase CLI directly from your PC still is the most easiest way. But if you are runing in production environment, using Firebase CLI directly from your PC is too risky.

I believe that everyone love automation. So, let’s move to automation. If you are using Github, then Github Actions will be you 1st chioce. In this blog post, I will only focusing on how to deploy to Firebase Hosting with Github actions. If you want to know how to set up Firebase Hosting, you will found it here.

Setup Workflow

Start with breakdown the workflow into steps.

1. Authenticate to Firebase (need token)
2. Deploy assests to Firebase Hosting (with firebase deploy)

Acquire Firebase token

Now, We need the Firebase token for authentication. This token can be aquired through the firebase login:ci command. Keep it secure in Github repo setting -> Secrets.

Create Github Actions

Go to Acions tab on your Github repo. Create workflows by yourself. Then you can use my workflow. But please make sure you understand it.

At line 18. I’ve decided to use w9jds/firebase-action. Instead of using this action, We will need to install Firebase CLI by ourselves and use full Firebase command firebase deploy --token [YOUR_TOKEN] --only hosting --non-interactive.

Now, try to trigger the workflow. You will see the magic is happening.

Conclusions

Even you work solo or team, development or production, Github Actions is very helpful.

Let’s make is automation.

References

• Firebase CLI reference | Firebase Documentation
• Get started with Firebase Hosting
• GitHub Action for Firebase - GitHub Marketplace

Deploy to Firebase Hosting with Github Actions was originally published in Firebase Thailand on Medium, where people are continuing the conversation by highlighting and responding to this story.