Neo4J Bundle Laravel Package

Technical Evaluation

Architecture fit. This is a Symfony bundle that wraps graphaware/neo4j-php-client and exposes it through Symfony's DI container, YAML configuration, and bundle conventions. It is not a Laravel package: there is no service provider, facade, config publish command, or Laravel-native lifecycle handling. In a Laravel codebase it is a structural mismatch — using it would mean running Symfony container/bootstrapping assumptions alongside Laravel's, or bypassing the bundle and calling the underlying client directly, at which point the bundle contributes nothing.

Integration feasibility. Low. The repository description declares "NOT MAINTAINED ANYMORE" and redirects to neo4j-contrib/neo4j-symfony. With 1 star and 0 dependents there is no downstream usage validating compatibility, no user community to inherit maintenance, and no evidence of production operation. Every integration is greenfield risk with no ecosystem backstop.

Technical risk. High on all axes:

• Abandonment is already realized — the maintainer has publicly disclaimed the package.
• Version drift: unmaintained PHP code rots against PHP minor releases, PSR changes, and framework majors; the embedded Neo4j driver's Bolt protocol will lag Neo4j server releases.
• Security: no disclosure channel or patch path; a CVE in a transitive dependency has no remediation short of a fork.
• Correctness: Cypher/Bolt changes in Neo4j 5.x are unlikely to be reflected — silent behavioral drift is plausible.
• Laravel-specific: the bundle's service wiring would fight Laravel's container and long-lived-worker lifecycle (Octane, queue consumers).

Key questions a TPM should force answers to.

1. Is Neo4j actually required, or is this a graph-shaped problem a relational store (recursive CTEs) or managed graph service solves more cheaply?
2. If Neo4j is required, why evaluate an explicitly deprecated package over the maintainer-recommended successor (neo4j-contrib/neo4j-symfony) or the framework-agnostic official driver (neo4j/neo4j-php-client)?
3. Is the target stack genuinely Laravel? If so, the correct evaluation set is driver-level packages, not Symfony bundles.
4. Who owns the fork if we proceed? Deprecation means assuming maintenance on day one.
5. Which Neo4j server version is in scope, and does this bundle's driver support it?

Leverage decision. The only defensible TPM use of this package is as a reference implementation and scoping artifact. Do not add it to composer.json. Use the repo to estimate integration effort, to name a concrete example in dependency-governance policy, and to redirect the team to a maintained successor. Recommendation: close the evaluation and re-scope at the driver layer.

Integration Approach

Stack fit. Poor for Laravel. The idiomatic path is a thin Laravel service provider around a maintained, framework-agnostic driver — the official neo4j/neo4j-php-client, or a maintained OGM such as laudis/neo4j-php-ogm if entity mapping is genuinely needed. That yields config publishing, connection handling under Octane, queue-safe lifecycle, and a normal composer update maintenance story. The bundle layer adds abstractions we would have to own and later unwind.

Migration path. There is no installed base to migrate from (0 dependents), so this is a selection decision, not a migration. Sequence:

1. Confirm graph requirement, query patterns, and target Neo4j server version.
2. Select the official PHP driver directly; skip the bundle.
3. Wrap it in a single service provider plus config file; keep the wrapper thin (connection factory + health check) so the driver stays swappable.
4. If Symfony is actually the target, use neo4j-contrib/neo4j-symfony and validate its release cadence before committing.

Compatibility. Unknown and unverifiable without auditing stale composer constraints against our PHP and framework versions. Assume constraints are outdated and that composer require either resolves to an ancient locked set or needs lenient overrides — both are red flags. Independently verify the underlying Bolt protocol version against the target Neo4j server.

Sequencing. (a) 1–2 day requirements spike on graph need and query shape. (b) Driver selection and compatibility matrix, including a spike against the target server. (c) Thin wrapper plus connection health check. (d) Load/soak test the connection layer before feature work. Do not sequence any of this behind a bundle evaluation — the bundle is out of scope after (a).

Operational Impact

Maintenance. Effectively total ownership. An unmaintained package is a permanent line item: watching upstream dependencies, patching security issues, and revalidating against every PHP/Neo4j release. With 1 star and 0 dependents there is no prospect of the community absorbing this cost. The official driver has a real maintainer team and is the only defensible choice; the successor bundle reduces but does not eliminate this.

Support. None. No issue triage, no security contact, no upgrade guide. Internal engineers become de facto maintainers of code they neither wrote nor chose, and onboarding docs must be reverse-engineered from source.

Scaling. The bundle contributes no scaling capability beyond the driver — pooling, concurrency, read/write routing, and cluster-aware routing are all driver concerns. Any scaling work lands on the driver anyway, so the bundle is dead weight in the scaling story, not an enabler.

Failure modes. Anticipated patterns: (1) silent breakage on PHP upgrade via an abandoned transitive dependency; (2) Bolt protocol incompatibility surfacing as connection resets under load after a Neo4j server upgrade; (3) container-lifecycle bugs — stale or leaked connections in long-lived workers (Octane, queue consumers); (4) security exposure with no patch path; (5) knowledge concentration when one engineer reverse-engineers the bundle's internals and leaves.

Ramp-up. Deceptively steep. Surface usage looks simple, but engineers will burn disproportionate time discovering undocumented behavior, debugging wiring that doesn't match Laravel conventions, and working around stale constraints. Budget several days a maintained driver would not require — and that cost recurs with every new team member.

Net TPM assessment. This is a redirect notice with a composer.json attached. The actionable outputs are: a dependency-governance example, a scoping reference for the graph feature, and a pointer to neo4j-contrib/neo4j-symfony (if Symfony) or the official PHP driver (if Laravel). Escalate the graph-feature decision on product merit, not tooling, and gate any Neo4j adoption on that answer.