freema/react-admin-api-bundle
Symfony bundle that adds a react-admin compatible API backend to your app, handling dataprovider requests, filters, pagination and Doctrine ORM resources so you can connect a react-admin frontend with minimal custom code.
Architecture fit. The package is freema/react-admin-api-bundle, a Symfony bundle that exposes Doctrine entities to React Admin clients through list/delete/sort traits. This is a material framing point: the brief asks for a Laravel/PHP package assessment, but this release is explicitly built and tested against Symfony 6.4, 7.4 and 8.x with DoctrineBundle and doctrine/orm — there is no Illuminate/Laravel support surface anywhere in the notes. Any plan to drop this into an Eloquent-based Laravel service should be treated as a non-starter; the realistic target is a Symfony application, or a Laravel codebase only if it is already running Doctrine ORM + Symfony components as an interoperability layer. That distinction should be resolved before any estimation work begins.
Integration feasibility. For a Symfony target, feasibility is high: Symfony 6.4 and 7 remain supported with no behaviour change, so an existing install can take 1.3.0 as a routine patch. Symfony 8 is additive and gated on PHP 8.4 and DoctrineBundle 3, meaning the runtime upgrade path for that piece is governed by DoctrineBundle's own upgrade notes rather than this package. The 1.3.0 release removes tests, CI and development files from the Composer archive — a positive for production artefact size, but it means downstream consumers cannot run the bundle's own test suite from a vendor install and must rely on the upstream CI matrix (PHP 8.2–8.5, Symfony 6.4/7.4/8.x, PHPStan level 8) as the quality signal.
Technical risk. The dominant risk is that 1.2.0 shipped a defect where SoftDeleteTrait::delete() failed on every call with a TypeError, thrown after the entity had already been soft-deleted or removed. That is a silent data-integrity hazard, not just an error: callers receive an exception, may treat the operation as failed and retry or roll back, while the mutation has in fact landed. Any product currently on 1.2.0 using soft delete should treat this as an urgent upgrade, and should audit for entities that were soft-deleted but reported as failures. Secondary risk: the sorting fix is conditional on the installed ORM version (enum on 3.7+, string on older), which introduces version-dependent code paths that need explicit test coverage in our integration layer, not just upstream. The stated return contract is now aligned with DeleteTrait — success, or 400 for an unknown id — which is a behaviour change for anyone who built client handling around the old exception.
Key questions.
SoftDeleteTrait::delete() TypeErrors in production, and if so what is the reconciliation plan for entities deleted-but-reported-failed?Stack fit. Assume a Symfony service with DoctrineBundle and doctrine/orm, fronted by a React Admin SPA. The bundle is a thin trait/controller layer over entity metadata, so it fits as a read/delete API façade and should not be expected to carry domain logic, authorisation policy or validation — those remain ours. If the intended host is Laravel, the correct output of this assessment is a recommendation against adoption absent an existing Doctrine investment; retrofitting Doctrine and Symfony bundles into an Eloquent application to gain CRUD scaffolding is a poor trade.
Migration path. Two distinct tracks. Track A (staying on Symfony 6.4/7): a straight composer require bump to 1.3.0, no code changes, and this is where the soft-delete fix lands. Track B (Symfony 8): PHP 8.4 first, then DoctrineBundle 3, then Symfony 8, then this bundle — sequencing dictated by DoctrineBundle. Do not couple the two tracks; decoupling them is what lets the urgent correctness fix ship now while the platform upgrade proceeds on its own schedule.
Compatibility. Pin to 1.3.0 or later, and treat 1.2.0 as a floor we must vacate. Verify our doctrine/orm minor version explicitly so we know which branch of the sort-direction logic we exercise — 3.7+ uses the SortDirection enum, earlier uses the string. Confirm PHP version per environment against the 8.2–8.5 supported range. Note that the removal of tests and CI files from the Composer package does not affect runtime compatibility but does reduce what our own CI can introspect from vendor.
Sequencing. (1) Immediate: upgrade to 1.3.0 on all Symfony 6.4/7 environments for the soft-delete fix; no feature work bundled with it. (2) Short: add integration tests for delete semantics (success, unknown-id 400) and sort direction across our ORM version, since these are the two surfaces that changed. (3) Short: reconcile any soft-delete records created during the 1.2.0 window. (4) Medium: evaluate Symfony 8 / PHP 8.4 / DoctrineBundle 3 as a separate platform initiative, with this bundle as a dependent, not a driver.
Maintenance. Low ongoing cost while on Symfony 6.4/7 — the release notes state nothing changes for applications that stay there. The maintenance burden concentrates in the version-conditional sorting code and in any future Symfony/Doctrine major bumps, both of which we inherit from upstream rather than control. Losing the shipped tests and CI files means we cannot locally reproduce upstream's verification; budget for our own regression tests around the trait behaviour we depend on.
Support. Upstream provides an UPGRADING.md and an actively unified CI matrix (PHP 8.2–8.5, Symfony 6.4/7.4/8.x, PHPStan 2 at level 8), which is a reasonable support posture for a small open-source bundle. There is no vendor SLA. The practical support risk is bus-factor: one maintainer, and a defect of the severity of the 1.2.0 TypeError reaching a release suggests the pre-1.3.0 CI did not exercise the soft-delete path in a way that would have caught it. If soft delete is business-critical, plan for the option to fork and pin, and confirm licensing permits that.
Scaling. The bundle is a thin pass-through to Doctrine; scaling characteristics are those of Doctrine and the underlying database rather than the bundle itself. List endpoints with sorting are the hot path, and the 1.3.0 change is confined to how the direction argument is typed — no query-shape or pagination change is announced. No scaling work is justified by this release.
Failure modes. (a) Silent mutation with a reported failure — the 1.2.0 soft-delete defect; entities were deleted or removed before the TypeError surfaced, so retries and client-side rollbacks can diverge from database state. This is the failure mode to design out with a post-upgrade data audit. (b) Version drift — running an ORM below 3.7 while another environment runs above means the two branches of the sort logic are exercised inconsistently; enforce a single pinned ORM version across environments. (c) Client contract break — delete now returns success or a 400 for unknown id; React Admin front-ends that special-cased the old error will need review. (d) Platform-upgrade deadlock — a Symfony 8 initiative blocked on PHP 8.4 or DoctrineBundle 3 could stall unrelated work if sequenced as one change.
Ramp-up. Minimal for engineers already fluent in Symfony and Doctrine traits; the mental model is "annotate the entity, get a list/delete endpoint." The non-obvious parts to document are the soft-delete semantics (post-1.3.0), the 400-on-unknown-id contract, and the ORM-version-dependent sorting. For a Laravel-only team, ramp-up should be assessed as the cost of adopting Doctrine and Symfony bundle conventions wholesale — typically weeks, not days — which is the strongest argument for scoping this evaluation to Symfony hosts.
How can I help you explore Laravel packages today?