Mixed-provider reference architecture

On a narrow screen, swipe the diagram horizontally to keep its labels readable.

Scenario and proposed stack synthesis

Worked design, not a published customer result. A React portal mixes public YouTube/Vimeo lessons and owned HLS media. Use a NestJS catalog API with PostgreSQL records; ReactPlayer v3 handles the verified provider subset, while a dedicated owned-media player remains an option for richer diagnostics.

Catalog shape synthesis

// Proposed application model, not a library API.
type LessonMedia = {
  id: string;
  provider: "youtube" | "vimeo" | "owned-hls";
  source: string;
  status: "processing" | "ready" | "failed";
  capabilities: { seek: boolean; captions: boolean; rate: boolean };
};

Flow and decision synthesis

Render lesson metadata and a poster first. After loading the browser-side adapter, wait for readiness before restoring permitted progress. Save debounced progress hints through the application API, with provider details retained for diagnosis. Prefer a focused YouTube wrapper when only that provider is required; the multi-provider façade pays off when sources really vary.

Failure → improvement synthesis

A provider can recognize the URL while content is unavailable. Offer an explicit retry/error panel and let the user navigate away. Keep catalog state separate from player loading state. Measure per-provider start success; do not infer secure attendance from a client completion event.