Pumukit Youtube Bundle Laravel Package

Technical Evaluation

Architecture fit. The package is not a Laravel package — it is a Symfony bundle (teltek/pumukit-youtube-bundle) that extends the Pumukit video management platform, wiring YouTube publishing/ingestion into Pumukit's domain model (multimedia objects, tracks, materials). Adoption for a standard Laravel/TPM-scoped web application is effectively zero: it is not designed for, nor installable as, a generic Composer library inside a Laravel service container. The realistic architectural fit is narrow — organizations already running Pumukit (typically university or public-broadcaster lecture-capture stacks) that want first-class YouTube upload/import workflows.

Integration feasibility. Composer-installable in principle, but it depends on Pumukit core bundles and the Google API client, so it must be loaded inside a Symfony kernel with Pumukit's security context, configuration hierarchy, and MongoDB-backed persistence available. There is no Laravel service provider, no facades, no config-publishing conventions. Integration cost is dominated by the platform, not the package.

Technical risk. High. Signals: 2 GitHub stars, 0 downstream dependents, a composite score of ~2.6, and an opportunity score of 26.7 — all consistent with a single-org, single-consumer internal bundle. Bus factor is effectively one maintainer organization; the YouTube Data API is a moving target (quota model changes, OAuth scope changes, deprecation of legacy upload endpoints), so an unmaintained wrapper degrades silently in production. Version compatibility with newer Pumukit releases is unverified.

Key questions. (1) Are we already a Pumukit shop, or is this being considered for a Laravel app? If the latter, stop — it is the wrong tool. (2) Which Pumukit major version does the bundle target, and is that version still in security support? (3) Who owns YouTube API credentials and quota budgeting? (4) Is there a maintained fork or an internal fork we would need to carry?

Integration Approach

Stack fit. Poor for a Laravel/Symfony-generic stack; acceptable only for an existing Pumukit deployment. Treat it as a feature module of Pumukit, not as a reusable library. The correct framing in a roadmap is "enable YouTube distribution in our Pumukit instance," not "add a dependency to our app."

Migration path. There is no migration from a Laravel codebase — there is only a greenfield Pumukit deployment or an existing one. If the goal is simply "upload video to YouTube from our app," the pragmatic path is the official google/apiclient SDK plus a thin internal service class (~200–400 LOC), which is less total effort than standing up Pumukit to host this bundle.

Compatibility. Requires: matching Pumukit core version, PHP version aligned with that Pumukit release, MongoDB, the Google API PHP client, and OAuth credentials with https://www.googleapis.com/auth/youtube.upload scope. Validate each against the bundle's composer.json constraints before committing; expect to pin or patch.

Sequencing. (1) Confirm Pumukit is already in production and this is an additive feature. (2) Fork and pin the bundle into a private VCS to insulate against upstream abandonment. (3) Stand up a sandbox YouTube channel and verify OAuth + upload end-to-end. (4) Instrument quota consumption before enabling for all users. (5) Only then wire into editorial workflows.

Operational Impact

Maintenance. The dominant cost. You should assume you are adopting the code, not consuming it. Budget an owner who can read Symfony bundle internals and the YouTube Data API. Expect to absorb breaking changes in the Google client and in Pumukit itself; upstream will likely not do this for you.

Support. None commercially. No vendor SLA. Internal runbook, credential rotation procedure, and an escalation path to the single maintaining engineer are prerequisites, not nice-to-haves.

Scaling. Two independent ceilings. Platform-side, Pumukit/MongoDB scales for typical lecture-capture volumes but is not a high-concurrency transcoding farm. API-side, YouTube enforces per-project daily quota units — uploads are expensive, so a default quota can be exhausted by a handful of large videos per day. Quota increase requests are a Google process with lead time; this is a product constraint that must be surfaced to users as rate limiting, not discovered as an outage.

Failure modes. Silent upload failure on quota exhaustion; OAuth token expiry or revocation breaking all publishing at once; partial uploads leaving Pumukit and YouTube out of sync (no automatic reconciliation is implied); API deprecation rendering the wrapper inert; unmaintained bundle incompatible with a Pumukit upgrade, forcing an emergency fork-and-patch during a maintenance window.

Ramp-up. Steep and specialized: a new engineer needs Pumukit domain knowledge (its object model is non-obvious), Symfony bundle conventions, and the YouTube API. Estimate 2–4 weeks to first confident contribution for someone strong in PHP but new to Pumukit. That ramp-up cost, amortized against a 2-star bundle with no dependents, is the single strongest argument against adopting it unless Pumukit is already the house platform.