Build Camera Infrastructure Yourself or Use a Camera API/SDK?

说明与用途

构建摄像头基础设施或使用API/SDK的结构化决策流程，重点关注责任分配、测试和可维护性。

Deciding whether to build an IP camera backend from scratch or use a vendor API/SDK for live video integration.

A structured decision process that reduces build risk, clarifies ownership, and ensures maintainable camera integration.

1. Ask engineer to list recent non‑domain pages and device firmware involvement.
2. Require named on‑call rotation and device lab budget in ticket.
3. If missing, default to API/SDK adapter + MediaPort.
4. Write technical trade‑off note on ticket.
5. Estimate maintenance burden (inventory sync, capability drift, player versions, playback, secrets).
6. Run a two‑day spike: fake MediaPort + nested live route; one staging device through API/SDK adapter.
7. If spike fails, identify inventory or ticket scope issues.
8. Define hidden work: certificate rotation, capability refresh, player upgrade, delete path, load test.
9. Document failure injection tests and ensure UI does not crash on media errors.
10. Decide on platform API usage based on production implementation and UI type.
11. Write internal docs on capability sync and latency measurement; avoid public SKU lists.
12. Organize code: domain folders, adapters, MediaPort interface, optional gateway implementation.
13. If engineer still wants gateway, require implementing MediaPort twice (fake + gateway) before deleting adapter folder.

I will build when custody or protocol coverage forces me to. I will not build so a vertical SaaS can show live video on a site page.

If the ticket says “we might need RTSP later,” that is not a build decision. That is a MediaPort decision.

I refuse a spike that starts with protocol comparison spreadsheets and no route.