Webhooks ในเวิร์กโฟลว์วิดีโอ: ทำให้ไปป์ไลน์ของคุณอัตโนมัติ

แนะนำ Webhooks

Webhooks ช่วยให้ระบบหนึ่งแจ้งอีกระบบเมื่อมีบางอย่างเกิดขึ้น โดยส่งคำขอ HTTP ไปยัง URL ที่คุณควบคุม แทนที่แอปพลิเคชันของคุณจะคอย poll API เพื่อถามว่า "วิดีโอเสร็จหรือยัง" อยู่ตลอด ผู้ให้บริการจะ push ข้อความมาทันทีที่เหตุการณ์เกิดขึ้น ในเวิร์กโฟลว์วิดีโอ นี่คือกระดูกสันหลังของการทำงานอัตโนมัติ: การ transcode เสร็จ เหตุการณ์วงจรชีวิตของสตรีม การพร้อมใช้งานของไฟล์บันทึก และการ finalize การอัปโหลด ล้วนสั่งให้ขั้นตอนถัดไปในไปป์ไลน์ทำงานได้โดยไม่ต้องมีคนคอยเฝ้าแดชบอร์ด

กลไกนั้นเรียบง่ายและสอดคล้องกันในทุกผู้ให้บริการ เซิร์ฟเวอร์ที่รับคำขอจะตรวจสอบคำขอ (ในอุดมคติคือตรวจ cryptographic signature) ตอบกลับอย่างรวดเร็วด้วยสถานะ 2xx และคิวงานหนักไว้ประมวลผลเบื้องหลัง ส่วนที่เหลือ ทั้งชื่อเหตุการณ์ รูปร่างของ payload พฤติกรรมการ retry ล้วนต่างกันไปตามผู้ให้บริการ ซึ่งเป็นเหตุผลว่าทำไมการเข้าใจ รูปแบบ จึงสำคัญกว่าการท่องจำฟิลด์ของผู้ให้บริการรายใดรายหนึ่ง

URL ของ Webhook ถูกตั้งค่าที่ไหน

การตั้งค่าเป็นแบบ เฉพาะผู้ให้บริการ (provider-specific) เสมอ คุณลงทะเบียน endpoint HTTPS สาธารณะของคุณในแดชบอร์ดหรือ API ของผู้ให้บริการ รายนั้นๆ ไม่ว่าจะเป็นบริการ encoding แพลตฟอร์มสด ผู้ให้บริการชำระเงิน และอื่นๆ ขั้นตอนทั่วไปคือ วาง callback URL ของคุณ เลือกประเภทเหตุการณ์ที่คุณต้องการรับ และเก็บ signing secret ที่พวกเขาออกให้อย่างปลอดภัย ไม่มี "หน้าจอ webhooks" สากลที่ครอบคลุมทุกผู้ให้บริการ คุณต้องทำตามเอกสารของผลิตภัณฑ์เฉพาะที่คุณกำลังผสานรวมด้วยจริง เพราะตำแหน่งและคำศัพท์ที่ใช้ต่างกันทุกครั้ง

DCAST และผลิตภัณฑ์ฝั่งนักพัฒนา

ประสบการณ์ครีเอเตอร์สาธารณะที่ dcast.tv ไม่มี หน้าตั้งค่า "Webhooks" ทั่วไปที่คุณเพิ่ม URL อะไรก็ได้สำหรับเหตุการณ์อย่าง "transcoding finished" หรือ "stream started" ไม่ว่าฉบับร่าง SEO เก่าๆ บางฉบับจะอ้างอย่างไรก็ตาม อย่า ทำตามคำแนะนำที่บอกให้ผู้ใช้ล็อกอินเข้าแดชบอร์ด dcast.tv แล้วคลิก "manual dashboard webhook action" นั่นไม่ใช่วิธีที่ผลิตภัณฑ์สำหรับผู้บริโภคทำงาน และการคัดลอกขั้นตอนเหล่านั้นจะนำไปสู่ความสับสนเท่านั้น การผสานแบบ Partner และ API คือเอกสารและเครื่องมือที่มุ่งเป้าไปยังนักพัฒนาหรือพื้นผิว Pro/partner ซึ่งเป็นที่ที่ callback เหตุการณ์ที่ลงลายเซ็น และรายการใน roadmap ที่เกี่ยวข้องควรอยู่ อธิบายไว้ใน เอกสาร Partner API และเอกสารสำหรับนักพัฒนาอย่างเป็นทางการ แทนที่จะเป็นขั้นตอนแดชบอร์ดผู้บริโภคที่ไม่มีอยู่จริง กฎที่ใช้ได้จริง: ให้ถือว่าเนื้อหาบล็อกใดๆ ที่สัญญา UI dcast.tv เฉพาะเจาะจงนั้นล้าสมัย เว้นแต่มันตรงกับเอกสารผลิตภัณฑ์ปัจจุบัน เมื่อสงสัย ให้เชื่อเอกสารทางการเหนือ tutorial รวมถึงบทความนี้ด้วย

เหตุการณ์ webhook ที่พบบ่อยในเวิร์กโฟลว์วิดีโอ

สตริงที่แน่นอนต่างกันไปตามผู้ให้บริการ แต่หมวดหมู่ของเหตุการณ์นั้นสอดคล้องกันอย่างน่าทึ่งทั่วทั้งอุตสาหกรรม:

• Transcoding หรือ encoding finished — สินทรัพย์พร้อมสำหรับการเล่นหรือขั้นตอนไปป์ไลน์ถัดไป (thumbnail, การใส่คำบรรยาย, การเผยแพร่)
• Stream started / ended — วงจรชีวิตของสตรีมสด มีประโยชน์สำหรับ analytics การแจ้งเตือน และการสั่งเริ่มบันทึก
• Recording ready — เวอร์ชันรีเพลย์หรือ VOD ของสตรีมสดพร้อมใช้งานแล้ว
• Upload completed — การ ingest เสร็จสิ้นและไฟล์ดิบถูกจัดเก็บอย่างปลอดภัย

ไปป์ไลน์ที่ออกแบบดีจะเชื่อมโยงเหตุการณ์เหล่านี้: `upload completed` เริ่มการ transcode, `transcoding finished` สั่งสร้าง thumbnail และทำเครื่องหมายว่าสินทรัพย์เผยแพร่ได้ และ `recording ready` แจ้งผู้ติดตามว่ามีรีเพลย์แล้ว แต่ละเหตุการณ์ทำหน้าที่หนึ่งอย่างและส่งต่อไปยังเหตุการณ์ถัดไป

ทำความเข้าใจ Payload ของ Webhook

Payload มักเป็น JSON เกือบเสมอ อ่าน schema จริงของผู้ให้บริการของคุณเสมอ เพราะชื่อฟิลด์และการซ้อนกันต่างกัน ตัวอย่างด้านล่างเป็นเพียง ตัวอย่างทั่วไป เพื่อประกอบภาพเท่านั้น:

```json

{

"event": "transcoding_finished",

"video_id": "12345",

"status": "success",

"filename": "example_video.mp4",

"timestamp": "2023-10-05T12:00:00Z"

}

```

นิสัยสองอย่างจะช่วยคุณให้พ้นจากความปวดหัวจริงๆ อย่างแรก อย่าคิดเอาเองว่าฟิลด์มีอยู่ ให้ตรวจสอบก่อนใช้เชิงป้องกันเสมอ เพราะผู้ให้บริการเพิ่มและเปลี่ยนชื่อฟิลด์ตามเวลา อย่างที่สอง ให้ถือว่า payload เป็น การแจ้งเตือน ไม่ใช่แหล่งความจริง สำหรับสิ่งใดก็ตามที่สำคัญ ให้ใช้ ID ใน payload ไปดึงเรคคอร์ดที่เป็นทางการจาก API ของผู้ให้บริการ แทนที่จะเชื่อเนื้อหาของ webhook แบบตาบอด เพราะ payload อาจถูกปลอมแปลง (spoof) หรือส่งซ้ำ (replay) ได้

จัดการ Webhooks ด้วย Node.js

ตั้งค่า listener แบบง่าย

```javascript

const express = require('express');

const bodyParser = require('body-parser');

const app = express();

const port = 3000;

app.use(bodyParser.json());

app.post('/webhook', (req, res) => {

const payload = req.body;

console.log('Received webhook event: ' + payload.event);

res.status(200).send('Webhook received');

});

app.listen(port, () => {

console.log('Webhook server listening on port ' + port);

});

```

ตัวอย่าง: แยกสาขาตามประเภทเหตุการณ์

```javascript

app.post('/webhook', (req, res) => {

const payload = req.body;

if (payload.event === 'transcoding_finished') {

console.log('Transcoding finished for video ' + payload.video_id);

}

res.status(200).send('Webhook received');

});

```

ตรวจสอบลายเซ็น (Signatures)

ขั้นตอนความปลอดภัยที่สำคัญที่สุดเพียงหนึ่งเดียวคือการตรวจสอบว่าคำขอมาจากผู้ให้บริการของคุณจริงและไม่ได้ถูกปลอมแปลง ผู้ให้บริการส่วนใหญ่ลงลายเซ็นแต่ละคำขอด้วย HMAC ของ raw request body โดยใช้ secret ที่ใช้ร่วมกัน แล้วส่งผลลัพธ์มาใน header หน้าที่ของคุณคือคำนวณลายเซ็นนั้นใหม่และเปรียบเทียบแบบ constant time:

```javascript

const crypto = require('crypto');

function verifySignature(rawBody, signatureHeader, secret) {

const expected = crypto

.createHmac('sha256', secret)

.update(rawBody)

.digest('hex');

// constant-time compare avoids leaking timing information

return crypto.timingSafeEqual(

Buffer.from(expected),

Buffer.from(signatureHeader)

);

}

```

โปรดทราบว่าการตรวจสอบลายเซ็นมักต้องใช้ raw request body ตรงตามที่ได้รับพอดี หาก JSON parser ของคุณ re-serialize body ไปแล้ว ไบต์อาจต่างกันและลายเซ็นจะไม่มีวันตรงกัน ดังนั้นจงจับ raw body ก่อนการ parse เมื่อผู้ให้บริการกำหนด

การจัดการข้อผิดพลาดและการ retry

ทำ idempotency ด้วยการเก็บ ID ของทุกเหตุการณ์ที่คุณประมวลผลแล้วและข้ามรายการซ้ำ เพราะผู้ให้บริการ จะ ส่งเหตุการณ์เดียวกันมากกว่าหนึ่งครั้งระหว่างสัญญาณเครือข่ายสะดุด ให้คืนสถานะ 2xx หลังจาก คุณรับเหตุการณ์อย่างปลอดภัยแล้วเท่านั้น ซึ่งโดยทั่วไปคือหลังจากเขียนลงคิวที่คงทน ไม่ใช่หลังจากทำงานจริงเสร็จ จากนั้นประมวลผลงานที่ใช้เวลานานแบบอะซิงโครนัสเพื่อไม่ให้ผู้ส่ง timeout หากคุณทำงานหนักแบบ inline และใช้เวลาตอบนานเกินไป ผู้ให้บริการจะถือว่าล้มเหลว retry และคุณจะลงเอยด้วยการประมวลผลเหตุการณ์เดิมซ้ำๆ

แนวปฏิบัติที่ดี

1. ความปลอดภัย: ใช้ HTTPS เสมอ ตรวจสอบลายเซ็นในทุกคำขอ และปฏิเสธสิ่งใดก็ตามที่ตรวจสอบไม่ผ่านด้วย 401 หรือ 403

2. Idempotency: สมมติว่ามีการส่งซ้ำและตัดซ้ำด้วย event ID เพื่อให้การส่งซ้ำไม่มีวันคิดเงินซ้ำ เผยแพร่ซ้ำ หรือแจ้งเตือนซ้ำ

3. การตอบรับที่รวดเร็ว: ตอบกลับอย่างรวดเร็วด้วย 2xx แล้วทำงานจริงในคิวเบื้องหลัง

4. การมอนิเตอร์: บันทึกทุกการส่งและทุกความล้มเหลว แจ้งเตือนเมื่อการตอบที่ไม่ใช่ 2xx พุ่งสูง และเก็บ dead-letter queue สำหรับเหตุการณ์ที่คุณประมวลผลไม่ได้

ทดสอบ Webhooks บนเครื่องท้องถิ่น

เพราะ webhook ต้องมี URL ที่เข้าถึงได้จากสาธารณะ การทดสอบบนแล็ปท็อปจึงต้องใช้ tunnel เครื่องมืออย่าง ngrok เปิดเผยเซิร์ฟเวอร์ท้องถิ่นของคุณบนที่อยู่ HTTPS สาธารณะชั่วคราว เพื่อให้ผู้ให้บริการเข้าถึง `http://localhost:3000` ระหว่างการพัฒนาได้ ผู้ให้บริการหลายรายยังมีปุ่ม "send test event" และ log การส่งที่แสดงแต่ละความพยายามและรหัสการตอบที่คุณคืนกลับไป ใช้ทั้งสองเพื่อยืนยันว่า endpoint ของคุณตรวจสอบลายเซ็น คืน 2xx อย่างรวดเร็ว และจัดการ payload ได้ถูกต้อง ก่อนที่คุณจะพึ่งพามันในโปรดักชัน

คำถามที่พบบ่อย

Webhooks คืออะไรและทำงานอย่างไรในเวิร์กโฟลว์วิดีโอ?

Webhooks คือ HTTP callback ที่ผู้ให้บริการส่งไปยัง URL ที่คุณควบคุมเมื่อมีเหตุการณ์เฉพาะเกิดขึ้น ในเวิร์กโฟลว์วิดีโอ มันแจ้งแอปพลิเคชันของคุณแบบเรียลไทม์เกี่ยวกับสิ่งต่างๆ เช่น การ transcode เสร็จ การเริ่มและสิ้นสุดสตรีม การ finalize การอัปโหลด และการพร้อมใช้งานของไฟล์บันทึก ทำให้คุณสั่งขั้นตอนอัตโนมัติถัดไปได้โดยไม่ต้อง poll

จะตั้งค่า webhooks สำหรับผู้ให้บริการวิดีโออย่างไร?

กระบวนการเป็นแบบเฉพาะผู้ให้บริการเสมอ คุณลงทะเบียน endpoint HTTPS สาธารณะในแดชบอร์ดหรือ API ของผู้ให้บริการรายนั้น เลือกประเภทเหตุการณ์ที่คุณสนใจ และเก็บ signing secret ที่พวกเขาออกให้ ไม่มีขั้นตอนสากล ดังนั้นให้ทำตามเอกสารของผลิตภัณฑ์ที่คุณกำลังผสานรวมด้วยพอดี สำหรับ dcast.tv โดยเฉพาะ ให้พึ่งพาเอกสาร Partner API และเอกสารสำหรับนักพัฒนาอย่างเป็นทางการ แทนที่จะสมมติว่ามีหน้าจอ webhook ในแดชบอร์ดผู้บริโภค

เหตุการณ์ทั่วไปที่สั่ง webhook ในเวิร์กโฟลว์วิดีโอมีอะไรบ้าง?

เหตุการณ์ที่พบบ่อยได้แก่ "transcoding finished", "stream started", "stream ended", "recording ready" และ "upload completed" สตริงที่แน่นอนต่างกันไปตามผู้ให้บริการ แต่หมวดหมู่เหล่านี้ครอบคลุมความต้องการด้านการทำงานอัตโนมัติส่วนใหญ่

จะรักษาความปลอดภัยและตรวจสอบ payload ของ webhook อย่างไร?

ให้บริการ endpoint ของคุณผ่าน HTTPS และตรวจสอบ cryptographic signature ที่ผู้ให้บริการส่งมากับแต่ละคำขอ โดยใช้ secret ที่ใช้ร่วมกันและการเปรียบเทียบแบบ constant time ให้ถือว่า payload เป็นการแจ้งเตือน ไม่ใช่แหล่งความจริง: ใช้ ID ที่มันบรรจุอยู่ไปดึงเรคคอร์ดที่เป็นทางการจาก API ของผู้ให้บริการก่อนดำเนินการใดที่มีผลตามมา

จะจัดการการส่ง webhook ที่ซ้ำหรือล้มเหลวอย่างไร?

ทำให้ handler ของคุณเป็น idempotent ด้วยการบันทึกทุก event ID ที่ประมวลผลแล้วและข้ามรายการซ้ำ เพราะผู้ให้บริการ retry เมื่อได้การตอบที่ไม่ใช่ 2xx หรือ timeout ตอบรับอย่างรวดเร็วด้วย 2xx หลังคิวเหตุการณ์อย่างปลอดภัย ประมวลผลงานหนักแบบอะซิงโครนัส และเก็บ dead-letter queue พร้อมการมอนิเตอร์ เพื่อให้การส่งที่ล้มเหลวมองเห็นได้และกู้คืนได้

บทสรุป

Webhooks เป็นวิธีมาตรฐานที่เชื่อถือได้ในการทำให้ไปป์ไลน์วิดีโออัตโนมัติ แต่เฉพาะเมื่อแพลตฟอร์มที่คุณใช้ เปิดเผยมันจริง และเฉพาะเมื่อคุณจัดการมันอย่างปลอดภัยและ idempotent ตรวจสอบพฤติกรรมกับเอกสารผลิตภัณฑ์ ปัจจุบัน ตรวจสอบลายเซ็นในทุกคำขอ และอย่าพึ่งพาขั้นตอนแดชบอร์ดตัวอย่างที่ไม่มีอยู่จริงในผลิตภัณฑ์นั้นๆ สร้างรูปแบบให้ถูกต้องหนึ่งครั้ง แล้ววินัยเดียวกันจะติดตัวไปกับผู้ให้บริการทุกรายที่คุณผสานรวมด้วย

ขั้นตอนถัดไปและแหล่งข้อมูล

• ใช้เอกสารทางการของผู้ให้บริการ encoding หรือ streaming ของคุณสำหรับรายละเอียดประเภทเหตุการณ์ รูปแบบ payload และการตรวจสอบลายเซ็น
• สำหรับ DCAST ให้พึ่งพาเอกสาร Partner API / นักพัฒนา ที่เผยแพร่ เพื่อทำความเข้าใจขอบเขตการผสานรวม หลีกเลี่ยงการสมมติว่ามี UI webhook ในแดชบอร์ดผู้บริโภคบน dcast.tv