Pumukit Teams Bundle Laravel Package

Technical Evaluation

Architecture fit. The first thing to flag is a stack mismatch that changes the entire evaluation: teltek/pumukit-teams-bundle is a Symfony bundle for PuMuKIT, not a Laravel package. PuMuKIT is an open-source video management platform (Symfony-based, historically used by universities for lecture capture). The bundle's job is to pull Microsoft Teams meeting recordings into a PuMuKIT instance. If our target application is a Laravel service, this package does not drop in as a Composer dependency the way a Laravel package would — it expects a PuMuKIT host application, its service container conventions, its bundle registration, and its domain model (multimedia objects, tracks, profiles). The reusable asset here is not the bundle itself but the integration logic: Microsoft Graph authentication, meeting/recording discovery, download, and ingestion into a media pipeline.

Integration feasibility. Feasible, but only as a reference implementation or as part of a PuMuKIT deployment — not as a component we install into a Laravel app. The hard parts are external to the package: an Azure AD app registration with tenant admin consent, the right Graph scopes (meeting/call record and file read permissions), handling recordings that live in OneDrive/SharePoint, large-file downloads, and the fact that Teams recording availability and retention are governed by tenant policy, not by our code. Any of those can block delivery independent of the package's quality.

Technical risk. High, and concentrated in supply-chain and lifecycle rather than code quality. Zero stars and zero dependents means no community validation, no third-party issue reports, no evidence anyone outside Teltek runs it in production. It is effectively a single-vendor artifact tied to a niche platform; if Teltek deprioritizes PuMuKIT, the bundle goes stale silently. Expect tight coupling to specific Symfony and PHP versions that may be past end-of-life, and to a Graph API surface that Microsoft versions and deprecates on its own cadence. There is no signal here about test coverage, CI, or release cadence, and the overall score of 0 reinforces that we should assume nothing.

Key questions.

• Is our actual target a PuMuKIT deployment, or a Laravel app that merely needs Teams ingestion? The answer determines whether this package is a fit or a reference.
• Which Symfony and PHP versions does the bundle declare, and are they still supported upstream?
• How does it authenticate to Graph — delegated vs. application permissions, client credentials, certificate vs. secret — and where are tokens stored?
• Does it discover recordings by polling, webhook/subscription, or manual trigger? What is the latency and the rate-limit exposure?
• What is the maintenance status (last commit, open issues, tagged releases) and is there a commercial support path through Teltek?
• What is the licensing and redistribution position if we vendor or fork the Graph logic?
• How does it handle retention expiry and recordings deleted from Teams before ingestion completes?

Integration Approach

Stack fit. Three viable paths, in descending order of pragmatism:

1. Adopt PuMuKIT as the media backend if our requirement is genuinely "host and manage recorded lectures/meetings." Then the bundle is a natural fit and the Laravel app becomes a front end or orchestrator calling PuMuKIT's APIs. Highest fidelity, highest platform commitment.
2. Extract, don't install. Use the bundle as a specification for the Graph workflow and reimplement the ingestion client natively in our Laravel codebase (a queued job plus a Graph SDK client). Keeps one runtime, one deployment, one auth model. Cost is reimplementation; benefit is no Symfony coupling and full control over retries, storage, and transcoding.
3. Sidecar service. Run a small PuMuKIT-adjacent or standalone PHP service that owns Teams ingestion and hands finished media to our platform over HTTP or object storage. Good isolation, but adds an operational surface we must own.

Path 2 is the default recommendation unless PuMuKIT is already in the estate.

Migration path. There is no incremental migration from "Laravel app" to "Symfony bundle" — the gap is architectural, not versioned. Treat this as a greenfield integration: stand up an Azure AD app registration and Graph access first, prove recording retrieval in a spike, then decide whether to persist with PuMuKIT or port the logic.

Compatibility. Verify PHP and Symfony version constraints against our supported runtime before anything else, and check which Graph API version the code targets. Teams recording APIs and call-record endpoints have shifted; a bundle that has not tracked those changes will fail at the first API call, not at install time.

Sequencing.

1. Confirm the real requirement (PuMuKIT vs. Laravel-native ingestion) and get a decision on platform commitment.
2. Obtain tenant admin consent and Graph scopes in a non-production tenant; validate that we can enumerate and download a real Teams recording.
3. Timebox a spike: either install the bundle in a throwaway PuMuKIT instance or read the source and estimate the port to Laravel.
4. Fork or vendor the Graph client logic if we proceed; pin it and own it.
5. Build ingestion as an idempotent, queued pipeline with explicit states (discovered, downloaded, transcoded, published, expired) before wiring it to any user-facing surface.

Operational Impact

Maintenance. Assume we own it. Zero dependents and a single vendor mean no upstream patch flow we can rely on. Budget for a fork with a named owner, pinned dependencies, and a scheduled review against Graph API change announcements. If we adopt PuMuKIT, we inherit PuMuKIT's own upgrade treadmill as well.

Support. Escalation is to Teltek directly; there is no community to fall back on. Confirm whether a support agreement exists before this becomes load-bearing. Internally, at least two engineers should understand the Graph auth and download path so this is not a single-person dependency.

Scaling. Two distinct bottlenecks. Graph is the first: throttling on meeting and file endpoints, plus per-tenant concurrency limits, means ingestion must be rate-limited and backoff-aware rather than fanned out aggressively. Storage and transcoding are the second: Teams recordings arrive as large files and typically need normalization before they are publishable. The bundle's own scaling characteristics are unknown and should be measured, not assumed — a single-threaded console command pulling recordings serially will not survive a busy semester.

Failure modes.

• Auth expiry and consent revocation — tenant policy changes or secret/certificate expiry silently break ingestion.
• Recording not present — recording may be disabled by policy, still processing, or already expired under retention rules; the pipeline must treat "missing" as a normal state, not an error.
• Partial downloads and huge files — needs resumable transfer and checksums; silent truncation produces corrupt media that surfaces late.
• Graph throttling and transient 5xx — without idempotency and retry with backoff, duplicates and gaps accumulate.
• Upstream abandonment — the package stops tracking Graph or Symfony; we discover it in production.
• Duplicate ingestion — the same recording picked up twice after a retry, producing duplicate catalogue entries.

Ramp-up. Low for a Symfony-fluent engineer if PuMuKIT is in play — a few days to read the bundle and stand up a test instance. High for a Laravel-only team, because the real learning is Microsoft Graph tenancy, permissions, and recording lifecycle, not the PHP. Estimate two to three weeks before a team is productive on the Graph side, most of it spent on admin consent and discovering how our tenant actually stores and retains recordings. Given zero community signal, plan for the first integration attempt to be a learning exercise rather than a deliverable, and keep the option to port to Laravel open until the spike proves otherwise.