Video Api Laravel Package

Product Decisions This Supports

• Build vs. borrow vs. buy for video metadata. This package is the "borrow" option: a thin Laravel wrapper over YouTube Data API v3 (videos.list) and Vimeo's video endpoint, normalizing title, description, thumbnails, and duration. Benchmark it against (a) ~100–200 lines written in-house on Laravel's HTTP client, (b) keyless oEmbed (youtube.com/oembed, vimeo.com/api/oembed.json), and (c) a paid unfurl/metadata vendor (Embedly, Iframely).
• Whether video is a first-class content type or an embed string. If the roadmap implies a media library — provider ID, thumbnail, duration, publish date, refresh job, schema.org VideoObject markup — you need a small internal abstraction. If it just needs a preview card, this is over-scoped.
• Feature scoping for common video surfaces: link unfurling in feeds/comments, CMS media attachments, LMS lesson videos, marketplace listing previews, support-ticket attachments, marketing asset catalogs.
• Provider abstraction investment. Roadmaps that touch more than YouTube/Vimeo (Wistia, Mux, TikTok, Brightcove) should not take a hard dependency here; the right call is an internal VideoMetadataResolver interface with this (or a fork) as one implementation.
• Operational budgeting: API key custody, quota planning (YouTube's default 10,000 units/day; videos.list costs ~1 unit per call — fine for organic traffic, not for bulk backfills), cache TTLs, and queued refresh.
• Compliance posture: YouTube's terms require refreshing stored API data at least every ~30 days. Any adoption decision carries that recurring job regardless of which library you pick.

When to Consider This Package

Consider it when:

• The app is on Laravel 5.x / PHP 7.x and there's no appetite to modernize the runtime.
• Requirements are genuinely shallow: a URL or video ID in, title/description/thumbnail/duration out.
• It's a prototype, internal tool, or stakeholder demo, with a small blast radius if it breaks.
• You are willing to vendor or fork the code, pin the version, and wrap it in an adapter you control.
• You want a one-day spike to validate demand before committing engineering time.

Look elsewhere when:

• You are on Laravel 9/10/11 or PHP 8.1+. Last release was 2017-03-20 (Laravel 5.4 era), with zero dependents and no visible CI — expect Guzzle 6 constraints and service-provider/facade drift. The fork usually costs more than a rewrite.
• You need queued or parallel fetching, retry with backoff, circuit breakers, or per-provider rate limiting.
• You need transcripts/captions, chapters, live status, playlists, channel data, or engagement metrics.
• oEmbed covers the use case — no API key, no quota, no key rotation. For pure embed previews, that is the better buy.
• You need non-YouTube/Vimeo providers, or a maintained dependency with security patching.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed utility that saves roughly one to two engineer-days of YouTube/Vimeo integration. It is not a strategic dependency: 54 stars, zero dependents, last release 2017. Its high quality score and low opportunity score (0.11) point the same way — competent at a commodity job, with no differentiation to build a bet on. Recommend a timeboxed spike (1–2 days); if it holds, fork it behind an interface so we can replace it without a rewrite.

Engineering: The value is URL parsing, provider dispatch, and response normalization — reproducible in roughly 150 lines on Laravel's HTTP client, with caching and retries built in. Either path leaves us owning API keys, quota budget, and the 30-day metadata refresh YouTube's terms require. Pin or fork; do not depend on upstream.

Product: The decision this actually unblocks is whether video metadata is a platform capability (abstraction, cache, refresh, provider extensibility) or a per-feature convenience (oEmbed inline, nothing stored). The package choice is downstream of that call — settle the capability question first, then adopt the cheapest thing that satisfies it.