# จะแทนที่การ polling และ webhook ของ Replicate Prediction ในแอปเดิมได้อย่างไร > วางระเบียนงานอะซิงโครนัสที่ไม่ผูกกับผู้ให้บริการไว้ระหว่างผลิตภัณฑ์กับ API ให้ webhook ที่ตรวจสอบแล้วหรือ worker polling แบบมีขอบเขตอัปเดตตัวจบงานแบบ idempotent เดียวกัน ทำสถานะให้เป็นมาตรฐาน และคัดลอกไฟล์เสร็จแล้วไปยังพื้นที่เก็บถาวร แทนที่ polling และ webhook ของ Replicate ด้วยชั้นงานที่ไม่ผูกกับผู้ให้บริการระหว่างแอปกับ API อนุมาน ทำการสร้าง สถานะ การยกเลิก เหตุการณ์เสร็จสิ้น และการเก็บผลลัพธ์ให้เป็นมาตรฐาน เพื่อให้ส่วนอื่นของผลิตภัณฑ์ไม่ขึ้นกับออบเจ็กต์ prediction หรือ URL ของ Replicate อย่าเพียงเปลี่ยน callback URL หนึ่งเป็นอีก URL ในโค้ดผลิตภัณฑ์ ให้กำหนดสัญญาอะซิงโครนัสที่แอปต้องการก่อน ## บันทึกพฤติกรรมปัจจุบัน การสร้างแบบอะซิงโครนัสของ Replicate ส่งคืน ID prediction สถานะวงจรชีวิต และ URL อำนวยความสะดวก แอปอาจ polling `urls.get` รับ webhook POST หรือใช้ server-sent events ที่รองรับ บันทึกเส้นทางของแต่ละ workflow และสิ่งที่ผลิตภัณฑ์ทำในทุกการเปลี่ยนสถานะ | แนวคิดของ Replicate | สิ่งแทนในระดับแอปพลิเคชัน | |---|---| | ID prediction | ID งานผู้ให้บริการพร้อม ID งานภายใน | | `starting`, `processing` | `queued`, `running` | | `succeeded` | `completed` | | `failed`, `canceled` | `failed`, `canceled` | | `urls.get` | เมธอดสถานะของ adapter | | เพย์โหลด webhook | เหตุการณ์เสร็จสิ้นที่ทำให้เป็นมาตรฐาน | | URL ผลลัพธ์ | สินทรัพย์ถาวรที่แอปเป็นเจ้าของ | เก็บสถานะดิบของผู้ให้บริการแยกจากสถานะมาตรฐาน วิธีนี้รักษาหลักฐานการวินิจฉัยเมื่อผู้ให้บริการสองรายมีรายละเอียดวงจรชีวิตต่างกัน ## เพิ่มระเบียนงานภายใน สร้างแถวฐานข้อมูลก่อนเรียกผู้ให้บริการใหม่: ```json { "job_id": "job_01J...", "provider": "target", "provider_job_id": null, "state": "creating", "attempt": 1, "output_assets": [] } ``` ใช้ `job_id` ภายในใน UI คิว และการแจ้งเตือน หลังสร้างสำเร็จให้แนบ ID งานของผู้ให้บริการ คีย์ idempotency หรือโทเค็นการสร้างควรป้องกันไม่ให้การลองใหม่หลังเครือข่ายขัดข้องเปิดงานแบบเสียเงินสองครั้ง ## แทน polling ด้วย worker แบบมีขอบเขต หาก API ปลายทางดึงข้อมูลงานได้แต่ไม่มี webhook ให้ย้าย polling ไปยัง worker เบื้องหลัง ใช้ exponential backoff พร้อม jitter เส้นตาย และช่วงเวลาสูงสุด หยุดที่สถานะปลายทางทุกแบบ ไม่ใช่เฉพาะสำเร็จและล้มเหลว การยกเลิกต้องหยุดลูปด้วย อย่า polling จากเบราว์เซอร์ worker ฝั่งเซิร์ฟเวอร์ทำงานต่อได้หลังปิดแท็บ รวมการจำกัดอัตราไว้ศูนย์กลาง และบันทึกการเปลี่ยนสถานะแบบธุรกรรมได้ ## แทน webhook ด้วยเหตุการณ์ที่ตรวจสอบแล้ว หากปลายทางรองรับ webhook ให้ handler มีหน้าที่น้อย: * ตรวจสอบลายเซ็นหรือความลับร่วมก่อนแยกวิเคราะห์ข้อมูล; * กำจัดซ้ำด้วย ID เหตุการณ์หรือ ID งานผู้ให้บริการรวมกับสถานะ; * ตอบรับอย่างรวดเร็วแล้วส่งการประมวลผลเข้าคิว; * ดึงงานจากแหล่งจริงเมื่อเพย์โหลดไม่ครบ; * รองรับการส่งซ้ำและไม่เรียงลำดับ Replicate รองรับตัวกรองเหตุการณ์ เช่น start, output, logs และ completed ปลายทางอาจส่งเฉพาะเหตุการณ์สุดท้าย สร้างการรายงานความคืบหน้าใหม่เมื่อข้อมูลมีความหมายเท่านั้น อย่าสร้างความแม่นยำปลอมจากสถานะที่ห่างกัน ## ใช้เส้นทางจบงานเดียว ทั้ง polling และ webhook ต้องเรียกตัวจบงานแบบ idempotent ตัวเดียวกัน ตัวจบงานจะล็อกงานภายใน ยืนยัน ID ผู้ให้บริการ บันทึกสถานะสุดท้าย คัดลอกไฟล์ผลลัพธ์ไปยังพื้นที่เก็บถาวร และปล่อยเหตุการณ์แอปหนึ่งครั้ง วิธีนี้ป้องกันการแจ้งเตือนซ้ำเมื่อ webhook และผล polling ครั้งสุดท้ายมาถึงพร้อมกัน ## เก็บไฟล์ก่อนหายไป เอกสาร Replicate ระบุว่าไฟล์อินพุตและเอาต์พุตของ prediction ผ่าน API จะถูกลบอัตโนมัติหลังช่วงเวลาจำกัด ผู้ให้บริการใหม่อาจมีระยะเก็บหรืออายุ URL ลงนามต่างกัน ให้ถือ URL ผู้ให้บริการเป็นกลไกส่งมอบ ไม่ใช่พื้นที่เก็บถาวร ดาวน์โหลดผลลัพธ์ที่สำเร็จทันที ตรวจชนิดเนื้อหาและขนาด สแกนเมื่อจำเป็น เก็บใต้คีย์ที่แอปควบคุม และบันทึก checksum ให้ URL สินทรัพย์ที่เสถียรของคุณกับไคลเอนต์ ## ทดสอบความล้มเหลวและการกู้คืน การทดสอบสัญญาควรครอบคลุมการตอบกลับการสร้างล่าช้า webhook ซ้ำหรือหาย การตอบ polling แบบ 429 และ 5xx การแข่งยกเลิก URL ผลลัพธ์หมดอายุ เพย์โหลดผิดรูป และ worker เริ่มใหม่กลางงาน รัน adapter ทั้งสองในโหมด shadow สำหรับอินพุตที่ปลอดภัย เปรียบเทียบสถานะสุดท้ายและจำนวนสินทรัพย์ก่อนย้ายทราฟฟิกจริงแบบ canary ## สรุป สิ่งทดแทน polling และ webhook ของ Replicate ที่ทนทานคือสัญญางานอะซิงโครนัสภายใน ไม่ใช่ callback เฉพาะผู้ให้บริการที่กระจายอยู่ทั่วแอป ทำสถานะให้เป็นมาตรฐาน ทำตัวจบงานให้ idempotent เก็บไฟล์ทันที และให้ webhook ที่ตรวจสอบแล้วหรือ worker แบบมีขอบเขตขับเส้นทางจบงานเดียวกัน ## FAQ ### เบราว์เซอร์ควร polling API ใหม่โดยตรงหรือไม่ ควรใช้ worker ฝั่งเซิร์ฟเวอร์ เพราะทำงานต่อได้หลังปิดเบราว์เซอร์ รวมการจำกัดอัตราและการลองใหม่ไว้ศูนย์กลาง และอัปเดตสถานะภายในอย่างสอดคล้อง ### ควรแมปสถานะ prediction ของ Replicate อย่างไร แมปไปยังวงจรชีวิตภายในขนาดเล็ก เช่น creating, queued, running, completed, failed และ canceled พร้อมเก็บสถานะดิบเพื่อการวินิจฉัย ### จะหลีกเลี่ยงการประมวลผล webhook ซ้ำได้อย่างไร ตรวจสอบต้นทาง กำจัดเหตุการณ์ซ้ำตามเหตุการณ์หรือ ID งานกับสถานะ แล้วส่งทั้ง webhook และ polling ไปยังตัวจบงานแบบ idempotent ที่ใช้ธุรกรรมเดียวกัน ### ถ้าผู้ให้บริการใหม่ไม่มี webhook ควรทำอย่างไร ใช้ worker เบื้องหลังที่มี exponential backoff, jitter, เส้นตาย และการจัดการสถานะปลายทางทุกแบบอย่างชัดเจน ### แสดง URL ผลลัพธ์ของผู้ให้บริการแบบถาวรได้หรือไม่ ไม่ควรถือว่า URL เหล่านั้นถาวร ให้ดาวน์โหลดผลลัพธ์ทันทีและให้บริการผ่าน URL สินทรัพย์ของแอปพลิเคชันพร้อมการควบคุมการเข้าถึงของคุณ ### ควรทดสอบความล้มเหลวแบบใด ทดสอบเหตุการณ์ซ้ำหรือสูญหาย การจำกัดอัตรา ข้อผิดพลาดชั่วคราว การแข่งกันยกเลิก ผลลัพธ์หมดอายุ เพย์โหลดผิดรูป และ worker เริ่มใหม่