Pumukit External Api Bundle Laravel Package

Technical Evaluation

Bottom line: this is not a standalone Laravel or general-purpose PHP package. teltek/pumukit-external-api-bundle is a Symfony bundle that exists only as an extension of Pumukit, Teltek's Symfony/MongoDB open-source video management platform. Evaluated as a Laravel dependency, it is a category error: there is no service provider, no Laravel contract, no Composer package that can be dropped into a Laravel app. It is a plugin to a specific host application.

Architecture fit

• Fit is binary: it is a strong fit only if your product roadmap is "run or extend a Pumukit instance and expose its catalog over HTTP." In every other scenario — even other Symfony applications — fit is near-zero, because the bundle reads and writes Pumukit domain documents (series, multimedia objects, tags, playlists) via Doctrine MongoDB ODM mappings owned by the Pumukit core bundles.
• The API surface is therefore not an abstraction over your data model; it is Pumukit's data model, serialized. Any consumer couples to Pumukit's schema semantics, not to a neutral contract.
• The bundle is the integration layer, not the product. Adopting it means adopting Pumukit as the system of record for media metadata, with all the architectural commitments that implies (Symfony kernel, MongoDB, Pumukit's bundle graph, its encoding pipeline).

Integration feasibility

• Feasibility is gated by host-version alignment. Pumukit is a Symfony 2.x/3.x-era application; the bundle's composer.json constraints and its use of Doctrine ODM and Pumukit core services mean it must be installed into a Pumukit kernel at a matching version. There is no path to install it into a modern Laravel 10/11 app.
• Assuming a Pumukit host, integration work is real but bounded: register the bundle, configure routing and security/firewall for the API prefix, configure authentication (the API typically relies on Pumukit's user/token model), and map the exposed resources to consumer needs. Plan on reading the source because documentation is thin to nonexistent.
• Signals are poor: zero GitHub stars, zero dependents, composite score 0.1. That is the profile of an internal Teltek component published publicly with no community pull. Expect to be the only party exercising it.

Technical risk

• Abandonment risk: high. Zero stars and zero dependents on a 0.1 score is the strongest available proxy for "unmaintained." If a Pumukit core upgrade breaks an assumption, you own the fix.
• Version lock-in: high. You inherit Pumukit's PHP and Symfony version floor. That constrains your broader stack and, in practice, freezes you on an older PHP runtime — a security-patching concern you must size.
• Schema coupling: high. Doctrine ODM document mappings leak into API payloads. Changing Pumukit internals becomes a breaking API change for your consumers.
• Security surface: medium-high. An externally reachable API over a media catalog exposes write paths, media URLs, and user context. With no upstream security process, CVE response is yours.
• Support vacuum: high. No stars means no issue traffic, no Stack Overflow corpus, no third-party tutorials. Every question is answered by reading code.

Key questions to resolve before commitment

1. Are we already committed to Pumukit as the media system of record, or is Pumukit merely one candidate? If the latter, evaluate Pumukit first and treat this bundle as a feature of it.
2. Which Pumukit release does this bundle's composer.json actually target, and is that release still receiving security patches?
3. Does the API satisfy our required contract (auth model, pagination, filtering, media delivery, webhooks/events), or will we fork it?
4. What is the real total cost of ownership including a fork-and-maintain contingency?
5. Is there a maintained alternative — a headless media platform with a supported API — that avoids coupling to a dead plugin?

Integration Approach

Stack fit

• Target host: a Pumukit application on Symfony with MongoDB and Doctrine ODM. Not Laravel. If the surrounding product is Laravel, the correct pattern is service boundary, not library: run Pumukit + this bundle as a separate media service and integrate over HTTP from Laravel. Do not attempt to share a process or a codebase.
• If the surrounding product is not Pumukit at all, stop here and re-scope; no integration approach makes this bundle useful.

Migration path

• Because there is no incumbent to migrate from within this package, treat migration as "extract media responsibilities out of the monolith into a Pumukit service."
• Phase the extraction: (1) stand up Pumukit + bundle in a non-production environment and characterize the actual API; (2) implement an anti-corruption layer in the consuming app — a thin client with your own DTOs — so Pumukit's schema never reaches your domain; (3) dual-write or sync media metadata while the old path still serves reads; (4) cut reads over, then writes; (5) decommission the old path.
• The anti-corruption layer is non-negotiable given the coupling risk; it is also your insurance policy if you later replace Pumukit with a maintained platform.

Compatibility

• Pin exact versions of Pumukit core bundles and this bundle together in composer.lock, and treat any bump as a change requiring regression tests.
• Audit the runtime: PHP minor version, Symfony major version, MongoDB driver and server versions, and the Doctrine ODM release. Document the supported matrix explicitly — you are creating the compatibility policy the upstream does not provide.
• Verify the bundle is actually loadable in your kernel and that its routes register; confirm authentication works against your Pumukit user model before building consumers.

Sequencing

1. Spike: stand up Pumukit + bundle, exercise every endpoint, capture request/response shapes into a written contract spec. Timebox this — it is also the decision gate.
2. Decision gate: proceed only if the spike confirms the API covers your contract and the host stack is patchable.
3. Vendor/fork: mirror the repo into your own namespace so you control patches; add CI, a smoke test suite, and a dependency-update job.
4. Build the client/ACL layer, then integrate feature by feature behind flags.
5. Only after the contract is proven, migrate traffic and retire the legacy path.

Operational Impact

Maintenance

• Assume you are the maintainer. Budget ongoing effort for dependency bumps (Symfony, Doctrine ODM, MongoDB driver), PHP security patches, and the inevitable upstream-drift reconciliation. A realistic plan carries a standing allocation, not a one-time integration cost.
• Fork-and-own is the expected end state. Establish a private mirror with a documented patch queue and a policy for rebasing on upstream (which may never move).

Support

• No community, no maintainer responsiveness guarantee, no vendor SLA unless you contract Teltek directly — and that should be priced explicitly if the platform is business-critical. Ask for a support agreement in writing; assume nothing from a 0-star repo.
• Internal supportability depends entirely on the contract spec and ACL you write in the integration phase. Treat that documentation as a deliverable, not an afterthought — it is the only institutional knowledge you will have.

Scaling

• Scaling characteristics are Pumukit's, not the bundle's: MongoDB for metadata, the encoding/transcoding pipeline for media, and Pumukit's own caching. The bundle adds a thin HTTP layer, so it is unlikely to be your bottleneck — but it also gives you no rate limiting, no response caching, and no pagination guarantees you don't verify yourself.
• Put a gateway in front: TLS termination, rate limits, request quotas per consumer, and caching for catalog reads. Instrument latency and error rates per endpoint from day one, since upstream will never publish them.

Failure modes

• Host upgrade breakage: a Pumukit or Symfony bump changes a document mapping and the API payload shifts silently. Mitigate with contract tests in CI.
• Unpatched vulnerability: a CVE in PHP, Symfony, or MongoDB driver goes unaddressed because nobody upstream is tracking. Mitigate with your own dependency scanning and a patch SLA.
• Schema leak: consumers bind to Pumukit internals, making replacement expensive. Mitigate with the ACL and versioned public DTOs.
• Silent abandonment: the repo goes quiet (it already is) and you mistake that for stability. Mitigate by treating the fork as the real dependency.
• Knowledge concentration: one engineer understands the integration. Mitigate with the written contract spec and runbooks.

Ramp-up

• Expect a steep, source-reading ramp: no tutorials, no examples, no issue history. A competent Symfony/PHP engineer should plan roughly one to two weeks to stand up the host, characterize the API, and produce the contract spec — and that spike should be framed as a go/no-go gate, not sunk cost.
• The consuming-app side is cheaper if the ACL is built first; otherwise every feature team relearns Pumukit's model.

Recommendation: do not adopt this as a "Laravel/PHP package." Evaluate it only as one component of a Pumukit platform decision. If Pumukit is already the media system of record, the bundle is a reasonable starting point — but budget for a fork, an anti-corruption layer, and first-class operational ownership. If Pumukit is not already committed, the 0.1 score, zero dependents, and zero stars make this a poor foundation; prefer a maintained headless media platform whose API contract you can hold to an SLA.