Extractor Bundle Laravel Package

Technical Evaluation

keboola/extractor-bundle is a Symfony bundle for authoring Keboola extractor components — the containerized jobs that pull data from a third-party API into Keboola Storage. It is not a Laravel package and not a client for consuming Keboola data. For a TPM, the first job is to confirm which of those two problems the team is actually solving, because the recommendation flips entirely on that answer.

Architecture fit

• The bundle assumes a Symfony kernel, bundle registration, and the Keboola component runtime contract (/data/config.json, a run action, input/output state files, Storage API tokens, exit-code semantics). A Laravel application has no bundle registry; its service definitions will not auto-load, and there is no natural host for an extractor run() lifecycle inside an HTTP request or queue worker.
• If the mandate is authoring a Keboola extractor, this is the intended scaffolding and belongs in a standalone Composer project / Docker image, not inside the Laravel monolith.
• If the mandate is consuming Keboola (triggering jobs, reading Storage tables), this is the wrong package; use the Storage/Job Queue REST APIs or a Keboola client library instead.

Integration feasibility

• Low-to-moderate, and viable only as a sidecar service invoked from Laravel over HTTP or Symfony\Process. Booting the bundle inside Laravel's container via manual service-provider bridging is technically possible but buys nothing and imports the full Symfony DI surface into the app.
• Composer resolution is the first gate. Symfony minor-version constraints, a PHP floor, and a hard dependency chain on keboola/php-component will very likely conflict with a current Laravel (Symfony 6/7) install. A 1–2 day spike resolves this definitively.

Technical risk

• Adoption signal is weak. Bitbucket hosting makes the 0-star metric an artifact rather than a verdict, but zero recorded dependents and no Packagist presence mean no ecosystem pressure to keep constraints current and no public failure corpus to learn from.
• Supersession risk. Keboola's tooling has evolved; keboola/php-component absorbed much of the extractor scaffolding. We must confirm whether this bundle is still the recommended path before investing in it.
• Hosting risk. The canonical source is private-ish Bitbucket. Mirroring/forking into our VCS is mandatory, not optional, and the license/redistribution terms must be confirmed before adoption.

Key questions

1. What is the job to be done — build a new Keboola extractor, or pull Keboola data into our Laravel product?
2. Is this bundle still maintained and recommended by Keboola, or has it been folded into keboola/php-component? Check commit recency and developer docs.
3. What Symfony/PHP constraints does the tagged release declare, and do they resolve against our Laravel version?
4. What are the license and redistribution terms — can we vendor a fork internally?
5. Do we have an existing Keboola contract/tenant, or is this speculative?

Integration Approach

Stack fit

• Recommended pattern: separate deployable. The extractor lives in its own repo/image built on this bundle; Laravel triggers it via a queued job that shells out or calls an internal HTTP endpoint. Data lands in Keboola Storage (or is pulled back via the Storage API) — never in the application container.
• Fallback only: embed by manually registering the bundle's services in a Laravel service provider, constructing the extractor from the container, and isolating every Keboola runtime concern (state files, config parsing, exit codes) behind a single adapter class.

Migration path

• Greenfield: bootstrap from Keboola's component template rather than retrofitting into Laravel. Keep the extractor's composer.json fully independent so its dependency graph never touches the app's.
• Existing component: no migration needed — keep it where it is and add the invocation boundary from Laravel. This is the lowest-risk path and the one to prefer if a component already exists.

Compatibility

• Verify: PHP floor vs. our runtime; Symfony component versions vs. Laravel's; PSR-3 logger binding (the bundle expects Monolog/PSR-3); and whether the bundle requires a full Kernel at boot. Also confirm the keboola/php-component peer version it pairs with — that pairing dictates the runtime contract more than the bundle itself does.

Sequencing

1. Spike (1–2 days). Fresh composer require of the pinned tag into both a bare PHP image and a clone of our Laravel app; record the resolution outcome. This single test decides the architecture — fund it before anything else.
2. Confirm maintenance status with Keboola docs/community, select a pinned commit, fork to internal VCS, and log the fork point.
3. Build the invocation boundary (queue job → container/HTTP) and define the config/state contract explicitly.
4. Contract tests against a real Keboola project (non-prod) before any production wiring.

Operational Impact

Maintenance

• Expect to own it. Zero dependents and Bitbucket hosting imply minimal external bug-fixing pressure; if we adopt it, we are maintaining a fork. Budget for dependency bumps whenever Keboola's API or Symfony versions move. Pin to a commit SHA and document the fork point in the service README.

Support

• No commercial support is implied by the package. Recourse is Keboola developer documentation, their community channels, and any existing commercial relationship we hold with Keboola. If the extractor becomes business-critical, that relationship — not the library — must be the named support path.

Scaling

• The library is not the scaling unit. Extractors run as ephemeral containers; throughput is governed by Keboola's job queue plus our orchestration (memory/CPU limits, parallelism caps) and source-system API rate limits. Plan per-extractor resource limits and concurrency explicitly, and treat those limits as capacity-planning inputs, not implementation details.

Failure modes

• Build time: Composer resolution failures — the most likely early blocker.
• Boot time: Symfony DI boot errors when hosted outside a Symfony kernel.
• Run time: configuration/validation exceptions surfacing at execution rather than deploy. The component contract distinguishes user errors from application errors via exit codes; mis-mapping them causes jobs to be retried inappropriately or silently dropped.
• State handling: incremental extraction depends on input/output state round-tripping. A lost or malformed state file causes silent full reloads or data gaps — the highest-severity failure mode and the one most likely to go unnoticed.
• Memory: exhaustion on large extracts where rows are buffered in PHP memory.
• Upstream: source API changes and rate limiting — the most common real-world failure, and one this package does nothing to mitigate.

Ramp-up

• A mid-level PHP developer unfamiliar with Keboola needs roughly 1–2 weeks to be productive: component conventions (config.json, config rows, run action, state files), Docker packaging, Storage API basics, and Symfony DI. Laravel familiarity does not transfer to the bundle's idioms. Assign one dedicated owner rather than spreading this across the team.

TPM bottom line: adopt only if the mandate is to author Keboola extractors, and then strictly as an isolated service on a pinned internal fork. Do not introduce this bundle into the Laravel application's dependency graph. If the underlying need is data consumption, redirect to the Keboola APIs before any code is written — and elevate the real decision (build vs. buy for data ingestion) as the one worth funding.