วิธีใช้ Trigger.dev API

สรุปโดยย่อ / คำตอบด่วน

Trigger.dev API ช่วยให้คุณเรียกใช้ ตรวจสอบ เล่นซ้ำ และยกเลิกการทำงานของงานเบื้องหลังได้โดยไม่ต้องสร้างเลเยอร์การจัดคิวและการจัดการงานของคุณเองตั้งแต่เริ่มต้น หากคุณใช้ Trigger.dev ร่วมกับ Apidog คุณสามารถจัดทำเอกสารเวิร์กโฟลว์การทำงานของคุณ ทดสอบเพย์โหลด ตรวจสอบสถานะการทำงาน และแชร์ข้อมูลอ้างอิงภายในที่สามารถทำซ้ำได้สำหรับทีมแบ็กเอนด์และทีม QA ของคุณ

บทนำ

งานเบื้องหลังดูเหมือนจะง่ายจนกว่าจะเริ่มล้มเหลวในการผลิต คุณจัดคิวงาน รอผลลัพธ์ เพิ่มการลองใหม่ เพิ่มการสังเกตการณ์ เพิ่มการทำงานแบบหน่วงเวลา และทันใดนั้นคุณก็กำลังดูแลรักษาระบบงานทั้งหมดแทนที่จะนำเสนอคุณสมบัติที่คุณสนใจตั้งแต่แรก

นั่นคือเหตุผลที่ Trigger.dev กลายเป็นที่น่าสนใจสำหรับทีมสมัยใหม่ Trigger.dev คือเฟรมเวิร์กงานเบื้องหลัง โอเพนซอร์ส สำหรับการเขียนเวิร์กโฟลว์ที่ทำงานนานในโค้ดแบบอะซิงโครนัสธรรมดา พร้อมด้วยการลองใหม่ การจัดกำหนดการ การสังเกตการณ์ และการอัปเดตสถานะการทำงานแบบเรียลไทม์ในตัว จากเอกสาร Trigger.dev อย่างเป็นทางการที่ตรวจสอบเมื่อวันที่ 26 มีนาคม 2026 แพลตฟอร์มนี้ให้ SDK ที่เน้นงานเป็นหลัก, Runs API, การรองรับการประมวลผลเป็นชุด, การทำงานแบบหน่วงเวลา, การเล่นซ้ำ, การยกเลิก และการสมัครรับข้อมูลแบบเรียลไทม์สำหรับการเปลี่ยนแปลงสถานะการทำงาน

Trigger.dev API แก้ปัญหาอะไรบ้าง

Trigger.dev สร้างขึ้นสำหรับทีมที่ต้องการการดำเนินการเบื้องหลังที่เชื่อถือได้โดยไม่ต้องเชื่อมโยงคิว (queue), ฝูงเวิร์กเกอร์ (worker fleet), ตรรกะการลองใหม่ที่กำหนดเอง (custom retry logic) และเลเยอร์การตรวจสอบ (monitoring layer) ด้วยตนเอง แทนที่จะจัดการชิ้นส่วนที่เคลื่อนที่ได้หลายส่วนแยกกัน คุณจะกำหนดงานในโค้ดและให้ Trigger.dev จัดการการดำเนินการ, การลองใหม่, สถานะรอ, การทำงานที่หน่วงเวลา และการสังเกตการณ์

จากเอกสารทางการ คุณค่าหลักนั้นตรงไปตรงมา:

• เขียนงาน (tasks) ในโค้ดเบสที่มีอยู่ของคุณ
• เรียกใช้งาน (trigger) แบบโปรแกรมด้วยเพย์โหลดที่มีประเภท
• ตรวจสอบการทำงาน (run) และการลอง (attempt) แต่ละครั้งเมื่อเวลาผ่านไป
• เล่นซ้ำ (replay) หรือยกเลิก (cancel) การทำงานเมื่อจำเป็น
• สมัครรับข้อมูลอัปเดตการทำงานแบบเรียลไทม์
• รันบน Trigger.dev Cloud หรือโฮสต์เอง

สิ่งนี้สำคัญเพราะงานเบื้องหลังไม่ค่อยเป็นเพียงแค่ "รันฟังก์ชันนี้ทีหลัง" ในทางปฏิบัติ ทีมงานต้องการ:

• การลองใหม่ที่เชื่อถือได้สำหรับความล้มเหลวชั่วคราว
• การมองเห็นสถานะระหว่างการทำงานที่ใช้เวลานาน
• Idempotency เพื่อหลีกเลี่ยงการทำงานซ้ำซ้อน
• การหน่วงเวลาและ TTL สำหรับงานที่ต้องอาศัยเวลา
• วิธีที่ปลอดภัยในการจัดทำเอกสารและทดสอบเวิร์กโฟลว์การดำเนินงาน

นี่คือความท้าทายด้านสถาปัตยกรรมในโลกแห่งความเป็นจริง:

User action -> Trigger task -> Queue and execution -> Run status changes -> Result handling -> Retry or replay

หากทุกส่วนของห่วงโซ่นั้นอยู่ในที่ที่แตกต่างกัน การดีบั๊กก็จะช้าลง สมาชิกทีมคนหนึ่งตรวจสอบบันทึก อีกคนตรวจสอบแดชบอร์ด อีกคนเล่นซ้ำงานด้วยตนเอง และไม่มีใครแชร์ตัวอย่างคำขอหรือคำศัพท์สถานะเดียวกัน Apidog ช่วยปิดช่องว่างนั้นโดยให้ทีมของคุณมีที่เดียวในการจัดทำเอกสารอินพุต สถานะการทำงานที่คาดหวัง และการเรียกใช้ API ที่สนับสนุนรอบๆ เวิร์กโฟลว์ Trigger.dev ของคุณ

Trigger.dev API ทำงานอย่างไร

Trigger.dev มุ่งเน้นไปที่งาน (tasks) และการทำงาน (runs)

Tasks (งาน)

Task (งาน) คือหน่วยของงานเบื้องหลังที่คุณกำหนดในแอปพลิเคชันของคุณ คุณเขียนตรรกะในโค้ด จากนั้น Trigger.dev จะจัดการการดำเนินการ การลองใหม่ และการจัดการรอบๆ งานนั้น

นี่เป็นความแตกต่างที่สำคัญจากผลิตภัณฑ์ "API งานระยะไกล" แบบดั้งเดิม Trigger.dev ไม่ใช่แค่เอนด์พอยต์ REST ธรรมดาที่คุณส่งงานแบบสุ่มไปยังกล่องดำเท่านั้น แต่เป็นเฟรมเวิร์กบวกแพลตฟอร์ม แอปพลิเคชันของคุณกำหนดงาน และ Trigger.dev ให้ API และ SDK แก่คุณเพื่อเรียกใช้และตรวจสอบงานเหล่านั้นได้อย่างน่าเชื่อถือ

Runs (การทำงาน)

ตามเอกสารอย่างเป็นทางการ run (การทำงาน) จะถูกสร้างขึ้นทุกครั้งที่คุณเรียกใช้ task (งาน) run จะแสดงถึงอินสแตนซ์หนึ่งของการทำงานของ task นั้นด้วย payload (เพย์โหลด) ที่เฉพาะเจาะจง แต่ละ run มี:

• รหัส run ที่ไม่ซ้ำกัน
• สถานะปัจจุบัน
• input payload (เพย์โหลดอินพุต)
• metadata (ข้อมูลเมตา) ที่เกี่ยวข้อง

โมเดลที่เน้น run นี้เป็นส่วนที่คุณต้องทำความเข้าใจก่อน เพราะเวิร์กโฟลว์การทำงานส่วนใหญ่ใน Trigger.dev จะหมุนรอบ run มากกว่าที่จะเป็นคำขอ HTTP ทั่วไป

Attempts (การลอง)

Run (การทำงาน) สามารถมีการลอง (attempts) ได้ตั้งแต่หนึ่งครั้งขึ้นไป หาก task สำเร็จในการลองครั้งแรก run จะมีการลองเพียงครั้งเดียว หากล้มเหลวและมีการลองใหม่ Trigger.dev จะสร้างการลองเพิ่มเติมจนกว่า task จะสำเร็จหรือถึงขีดจำกัดการลองใหม่

นั่นหมายความว่า "run failed" (การทำงานล้มเหลว) และ "attempt failed" (การลองล้มเหลว) ไม่ใช่สิ่งเดียวกัน นี่เป็นหนึ่งในจุดที่ทีมมักจะสับสนได้ง่ายที่สุดเมื่อพวกเขาสร้างระบบงานขึ้นมาเป็นครั้งแรก Run คือวัตถุวงจรชีวิตที่ใหญ่กว่า Attempt คือการดำเนินการหนึ่งครั้งภายใน Run นั้น

Lifecycle states (สถานะวงจรชีวิต)

Trigger.dev จัดทำเอกสารตัวช่วยสถานะรัน (run-state helpers) หลายรายการ รวมถึงสถานะที่ถูกจัดคิว (queued), กำลังดำเนินการ (executing), กำลังรอ (waiting), เสร็จสมบูรณ์ (completed), ถูกยกเลิก (canceled) และล้มเหลว (failed) นอกจากนี้ยังแยกความแตกต่างระหว่างสถานะรอ (waiting states) กับสถานะการดำเนินการที่ใช้งานอยู่ (active execution states) ซึ่งมีความสำคัญเมื่อคุณพิจารณาเกี่ยวกับการทำงานพร้อมกัน (concurrency) และโหลดของระบบ (system load)

สำหรับทีมที่สร้างแดชบอร์ดหรือการแจ้งเตือน โมเดลสถานะนี้มีประโยชน์เพราะมันให้คำศัพท์ร่วมกัน:

• QUEUED หรืองานที่ล่าช้าได้รับการยอมรับแล้วแต่ยังไม่เริ่มทำงาน
• EXECUTING หรืองานที่ถูกถอนออกจากคิวกำลังใช้เวลาในการดำเนินการอย่างแข็งขัน
• WAITING หมายถึงรันถูกหยุดชั่วคราวโดยไม่ได้ดำเนินการอย่างแข็งขัน
• สถานะ completed หมายถึงรันเสร็จสมบูรณ์แล้วด้วยความสำเร็จหรือผลลัพธ์สุดท้าย

นั่นคือรายละเอียดของวงจรชีวิตที่คุ้มค่าแก่การจัดทำเอกสารใน Apidog สำหรับผู้ใช้ภายใน โดยเฉพาะอย่างยิ่งหากทีมสนับสนุนหรือทีม QA จำเป็นต้องพิจารณาความคืบหน้าของงาน

ส่งและตรวจสอบ Trigger.dev Run แรกของคุณ

เอกสารอย่างเป็นทางการแสดงการใช้งาน Trigger.dev ผ่าน SDK นั่นคือจุดเริ่มต้นที่ถูกต้องเพราะมันสะท้อนให้เห็นว่าทีมส่วนใหญ่รวมแพลตฟอร์มเข้าด้วยกันอย่างไร

เรียกใช้งาน (Trigger a task)

นี่คือตัวอย่างที่ง่ายขึ้นตามเอกสาร:

import { tasks } from "@trigger.dev/sdk";
import type { myTask } from "./trigger/myTask";

const response = await tasks.trigger<typeof myTask>({
 foo: "bar"
});

console.log(response.id);

สิ่งนี้จะสร้าง run และให้การตอบสนองที่คุณสามารถใช้เพื่อดึงข้อมูล run เต็มรูปแบบในภายหลัง

ดึงข้อมูล run (Retrieve a run)

เมื่อ task ถูกเรียกใช้แล้ว คุณสามารถดึงข้อมูล run ได้:

import { runs } from "@trigger.dev/sdk";

const run = await runs.retrieve("run_1234");

console.log(run.status);
console.log(run.payload);
console.log(run.output);

หากคุณมีประเภท task ที่พร้อมใช้งาน คุณสามารถรักษาความถูกต้องของการพิมพ์ payload และ output ได้:

import { runs } from "@trigger.dev/sdk";
import type { myTask } from "./trigger/myTask";

const run = await runs.retrieve<typeof myTask>("run_1234");

console.log(run.payload.foo);
console.log(run.output?.bar);

สมัครรับข้อมูลอัปเดตแบบเรียลไทม์

หนึ่งในความสามารถที่มีประโยชน์มากขึ้นของ Trigger.dev คือการตรวจสอบ run แบบเรียลไทม์ แทนที่จะสุ่มสำรวจ คุณสามารถสมัครรับการเปลี่ยนแปลงของ run ได้:

import { runs } from "@trigger.dev/sdk";

for await (const run of runs.subscribeToRun("run_1234")) {
 console.log(run.status);

 if (run.isCompleted) {
 console.log("Run completed");
 break;
 }
}

สิ่งนี้เหมาะอย่างยิ่งสำหรับ UI ความคืบหน้าสำหรับผู้ใช้ และสำหรับเครื่องมือการดำเนินงานภายใน

ยกเลิกหรือเล่นซ้ำ run

Trigger.dev ยังจัดทำเอกสารวิธีการยกเลิกและเล่นซ้ำ run:

import { runs } from "@trigger.dev/sdk";

await runs.cancel("run_1234");
await runs.replay("run_1234");

สิ่งนี้มีความสำคัญในการดำเนินงานเนื่องจากเวิร์กโฟลว์เบื้องหลังไม่ได้สิ้นสุดลงเสมอไปเมื่อการนำไปใช้งานครั้งแรกทำงาน ทีมงานต้องการวิธีที่ปลอดภัยในการหยุดการทำงาน เล่นซ้ำงาน หรือกู้คืนหลังจากปัญหาชั่วคราว

ใช้ idempotency และ TTL

เอกสารยังกล่าวถึงคีย์ idempotency และการตั้งค่า TTL สิ่งเหล่านี้ไม่ใช่รายละเอียดที่เลือกได้หากงานของคุณสามารถถูกเรียกใช้งานโดยการดำเนินการของผู้ใช้ การลองใหม่ของ webhook หรือบริการแบบกระจาย

ตัวอย่าง:

await yourTask.trigger(
 { orderId: "ord_123" },
 {
 idempotencyKey: "order-ord_123",
 ttl: "10m"
 }
);

สิ่งนี้ให้การป้องกันที่สำคัญสองประการแก่คุณ:

1. คุณหลีกเลี่ยงการดำเนินการซ้ำซ้อนสำหรับเหตุการณ์ทางธุรกิจเดียวกัน
2. คุณหยุดงานที่ต้องใช้เวลาไม่ให้เริ่มต้นช้าเกินไป

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

แนวทางปฏิบัติที่ดีที่สุดสำหรับเวิร์กโฟลว์ Trigger.dev API

เมื่อการรวมระบบพื้นฐานทำงานแล้ว นี่คือแนวทางปฏิบัติที่สำคัญที่สุด

1. พิจารณา Idempotency เป็นส่วนหนึ่งของสัญญา API

หากเหตุการณ์เดียวกันสามารถเกิดขึ้นได้สองครั้ง ให้กำหนดกลยุทธ์คีย์ Idempotency ตั้งแต่เนิ่นๆ อย่าปล่อยให้เป็นวิธีการแก้ไขความน่าเชื่อถือในระยะสุดท้าย

2. แยกความสำเร็จในการเรียกใช้จากความสำเร็จทางธุรกิจ

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

3. จัดทำเอกสารความหมายของสถานะการทำงานแต่ละสถานะ

ทีมแบ็กเอนด์ของคุณอาจเข้าใจสถานะ `WAITING` หรือสถานะที่ล่าช้าได้ทันที ทีมอื่นอาจไม่เข้าใจ อธิบายความหมายของแต่ละสถานะสำหรับผู้ใช้และการดำเนินงาน

4. ตัดสินใจว่าเมื่อใดที่การเล่นซ้ำปลอดภัย

การเล่นซ้ำมีประโยชน์ แต่ไม่ใช่ทุกงานที่ปลอดภัยในการเล่นซ้ำ ผลกระทบทางการเงิน การส่งข้อความออกภายนอก และการเขียนข้อมูลไปยังบุคคลที่สามจำเป็นต้องมีกฎการเล่นซ้ำที่ชัดเจน

5. กำหนดพฤติกรรมการยกเลิกให้ชัดเจน

หาก run ถูกยกเลิก ผู้ใช้ควรเห็นอะไร? เกิดอะไรขึ้นกับงานย่อย? ฝ่ายสนับสนุนควรทำอย่างไรต่อไป? สิ่งเหล่านี้คือคำถามเกี่ยวกับเวิร์กโฟลว์ ไม่ใช่แค่คำถามเกี่ยวกับ SDK

6. รักษา Apidog และ Trigger.dev docs ให้สอดคล้องกัน

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

ดาวน์โหลด Apidog ฟรีเพื่อจัดทำเอกสารเวิร์กโฟลว์ Trigger.dev ของคุณ บันทึกตัวอย่างคำขอ และเปลี่ยนพฤติกรรมงานเบื้องหลังให้เป็นข้อมูลอ้างอิงร่วมกันของทีม

ทางเลือกและการเปรียบเทียบ Trigger.dev

หากคุณกำลังประเมิน Trigger.dev คุณอาจกำลังเปรียบเทียบระบบที่เน้นคิวเป็นอันดับแรก การตั้งค่า cron และ worker ภายใน หรือแพลตฟอร์มเวิร์กโฟลว์ที่กว้างขึ้นด้วย

การเปรียบเทียบที่มีประโยชน์ไม่ใช่ "เครื่องมือใดที่ส่งคำขอ HTTP" แต่เป็น "การตั้งค่าใดที่ให้ทีมของคุณมีเส้นทางที่เร็วที่สุดจากแนวคิดงานเบื้องหลังไปสู่เวิร์กโฟลว์การผลิตที่เชื่อถือได้" Trigger.dev ช่วยในการดำเนินการ Apidog ช่วยในการจัดทำเอกสาร การทดสอบ และความชัดเจนของทีมเกี่ยวกับการดำเนินการนั้น

บทสรุป

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

หากคุณต้องการทำงานได้เร็วขึ้น ให้เริ่มต้นด้วยการกำหนดเวิร์กโฟลว์ทางธุรกิจจริงหนึ่งรายการใน Trigger.dev จากนั้นจัดทำเอกสารข้อมูลอินพุตของทริกเกอร์ สถานะการทำงาน และการดำเนินการกู้คืนใน Apidog สิ่งนี้จะช่วยให้ทีมของคุณมีเส้นทางที่ชัดเจนขึ้นตั้งแต่การนำไปใช้งานไปจนถึงการดำเนินงาน มากกว่าการอาศัยความรู้จากแดชบอร์ดเพียงอย่างเดียว

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

Trigger.dev API ใช้สำหรับอะไร

Trigger.dev API ใช้สำหรับเรียกใช้และจัดการการดำเนินการงานเบื้องหลังผ่าน tasks (งาน) และ runs (การทำงาน) จากเอกสารอย่างเป็นทางการ API รองรับการเรียกดู run, การแสดงรายการ, การเล่นซ้ำ, การยกเลิก, การหน่วงเวลา, TTL, การประมวลผลเป็นชุด และการสมัครรับข้อมูล run แบบเรียลไทม์

Trigger.dev เป็น REST API หรือ SDK

สำหรับนักพัฒนาส่วนใหญ่ จะได้รับประสบการณ์ผ่าน SDK และแพลตฟอร์ม Trigger.dev ที่กว้างขึ้น เอกสารเน้นไปที่ tasks, runs และ runtime helpers มากกว่าอินเทอร์เฟซ REST เพียงอย่างเดียว

run ใน Trigger.dev คืออะไร

Run คือหนึ่งอินสแตนซ์การดำเนินการของ task ประกอบด้วย payload, สถานะ, metadata และการลอง (attempts) หนึ่งครั้งหรือมากกว่านั้น ขึ้นอยู่กับว่ามีการลองใหม่เกิดขึ้นหรือไม่

ความแตกต่างระหว่าง run และ attempt คืออะไร

Run คือวัตถุวงจรชีวิตทั้งหมดสำหรับ task ที่ถูกเรียกใช้ Attempt คือการดำเนินการหนึ่งครั้งภายใน run นั้น หากมีการลองใหม่เกิดขึ้น run หนึ่งสามารถมีการลองได้หลายครั้ง

ฉันสามารถเล่นซ้ำหรือยกเลิก Trigger.dev runs ได้หรือไม่

ได้ เอกสารอย่างเป็นทางการอธิบายทั้ง `runs.replay()` และ `runs.cancel()` สำหรับการจัดการการดำเนินการ run หลังจาก task ถูกเรียกใช้

ฉันจะตรวจสอบ Trigger.dev runs แบบเรียลไทม์ได้อย่างไร

Trigger.dev มีเอกสารเกี่ยวกับการสมัครรับข้อมูลแบบเรียลไทม์ที่ช่วยให้คุณสามารถดูการอัปเดต run ได้ในขณะที่เกิดขึ้น สิ่งนี้มีประโยชน์สำหรับแดชบอร์ดการดำเนินงานและประสบการณ์ความคืบหน้าสำหรับผู้ใช้

Apidog มีบทบาทอย่างไรหากฉันใช้ Trigger.dev

Apidog เหมาะสมกับเวิร์กโฟลว์ มันช่วยให้คุณจัดทำเอกสารอินพุต เอาต์พุต การเปลี่ยนสถานะ และเอนด์พอยต์ที่สนับสนุนที่แอปพลิเคชันของคุณใช้ร่วมกับ Trigger.dev จากนั้นจึงแชร์ข้อมูลอ้างอิงนั้นระหว่างทีมวิศวกรรมและทีม QA