Weave Code
Dataflow Bundle Laravel Package
code-rhapsodie/dataflow-bundle
Symfony bundle for building import/export dataflows with one reader, any number of sync or async processing steps, and one or more writers. Schedule and run jobs, manage dataflows from the command line, and work with multiple Doctrine DBAL connections.
Data processing framework inspired by PortPHP
Frequently asked questions about Dataflow Bundle
- Can I use code-rhapsodie/dataflow-bundle in a Laravel application?
- No. Despite being installable via Composer, this is a Symfony bundle rather than a framework-agnostic library. It registers through config/bundles.php, depends on Symfony's DI container and tagged-service autoconfiguration via the coderhapsodie.dataflow.type tag, and exposes CLI entry points under bin/console. Laravel has no bundle kernel or compiler passes, so there is no supported install-and-use path. Pulling it in alongside Laravel typically means two competing service containers and Composer conflicts with the Symfony framework stack.
- What does the Code Rhapsodie Dataflow Bundle actually do?
- It provides a linear dataflow pattern for import/export pipelines: one reader, any number of synchronous or asynchronous steps, and one or more writers. On top of that it adds scheduled job runs, command-line management of dataflows, last-job result inspection, and support for multiple Doctrine DBAL connections. The design is inspired by PortPHP.
- What is the Laravel equivalent for building import/export dataflows?
- Build it with first-party primitives instead of porting the bundle. Illuminate\Pipeline or chained queued jobs model the reader/step/writer flow, Bus/Queue with Horizon gives you concurrency and retries, Schedule handles cron, and Storage (already Flysystem 3) covers exception dumps and file sinks. A local dataflow_runs table replaces the bundle's job and schedule tables. The skeleton is roughly 3 to 5 engineer-days, and the result is idiomatic and supportable in Laravel.
- Which Symfony versions does code-rhapsodie/dataflow-bundle support?
- The 6.x line requires Symfony ^7.4, 5.x targets ^7.3, and 4.x covers Symfony 3.4 through 6.x. The older 3.x, 2.x and 1.x branches are marked unsupported. Because each major line maps to a different Symfony range, upgrades are usually branch switches rather than normal minor upgrades. Note that Symfony 4.x before 4.1.12 has a known security advisory.
- Can I use PortPHP readers and writers with this bundle?
- Yes. The README recommends PortPHP for generic readers, writers and steps, and you wire PortPHP writers through CodeRhapsodie\DataflowBundle\DataflowType\Writer\PortWriterAdapter. PortPHP itself is a standalone library with no Symfony dependency, which makes it the most portable piece if you ever reimplement the flow. In a Laravel port you can keep using PortPHP readers and writers inside Pipeline steps unchanged.
- How does the bundle handle asynchronous processing steps?
- Asynchronous steps rely on Amp generators and scale factors rather than a conventional queue worker. That is a niche concurrency model with a thin operational story, so expect less visibility, retry control and backoff behaviour than a mature queue system provides. If you need at-least-once delivery, idempotent writers or explicit retry policies, verify the bundle's job table and Amp integration meet those semantics before adopting. Laravel's queue plus Horizon gives you those guarantees out of the box.
- Is code-rhapsodie/dataflow-bundle actively maintained and safe to depend on?
- The signals are weak: roughly 18 GitHub stars, 0 dependents, single-vendor stewardship, and maturity that looks README-and-releases only. It is MIT licensed, so forking is an option if the vendor deprioritizes it, but that shifts maintenance onto your team. Re-verify release dates and the version matrix directly on Packagist before deciding, and plan a licensing and compliance review if the flows touch PII.
- Can I run this Symfony bundle as a separate service next to my Laravel app?
- Yes, and it is the least-bad option if you must use the bundle as-is. Deploy a small dedicated Symfony app that owns the schedules and jobs, expose the dataflows over HTTP or a message transport, and let Laravel dispatch work to it. The trade-off is running a second runtime and stack, so weigh it against a 3 to 5 day Laravel reimplementation. This only makes sense if you already operate Symfony elsewhere.
- How do I create the database tables that the dataflow bundle needs?
- Schema management is manual. The bundle ships a dump-schema command that outputs SQL you paste into your own migration tool, and it does not own the cr_dataflow_job and cr_dataflow_scheduled tables through Doctrine migrations. That shifts migration discipline onto the adopting team. In a Laravel reimplementation, a single versioned migration for a dataflow_runs table with schedule columns is simpler and travels with your app.
- How would I test a dataflow if I reimplement it in Laravel?
- Test the reader as a plain generator unit, the steps as Pipeline pipes with fakes, and the writers against a fake disk or an in-memory database. Use Queue::fake() to assert that write jobs are dispatched, and assert run-state transitions on your dataflow_runs table. Because you own the code you get full unit and feature coverage instead of working around a container-bound Symfony bundle. Pest or PHPUnit both fit naturally.
Weaver
How can I help you explore Laravel packages today?