Neo4J Bundle Laravel Package

Product Decisions This Supports

• Feature gating for graph-native roadmap items. If the roadmap contains social graphs, recommendation engines, fraud-ring detection, knowledge graphs, org/permission hierarchies, or dependency mapping, this package is a data point in that decision — not the enabling technology. It shows the shape of a Symfony↔Neo4j integration (DI wiring, multi-connection config, query profiling) which is useful for scoping effort, but its abandoned status means the decision it actually supports is "graph features need a driver-level plan, not a bundle."

• Build vs. buy vs. defer, with a fourth option: wrong stack. For a Laravel product the honest framing is a four-way choice: (a) adopt the framework-agnostic official driver neo4j/neo4j-php-client behind a thin Laravel service provider, (b) use a maintained OGM such as laudis/neo4j-php-ogm, (c) defer graph features entirely, or (d) adopt a Symfony bundle — which for a Laravel codebase means running Symfony components alongside Laravel's container. This package closes off (d) convincingly: deprecated and structurally mismatched. That sharpens the remaining three.

• Roadmap sequencing and sprint hygiene. Any ticket naming this package in its acceptance criteria should be re-scoped before commitment. Treat the repo as prior-art reference for a discovery spike only (≤ 2 days), never as a line item in a delivery plan.

• Dependency governance policy input. This is a clean worked example for an approved-dependency checklist: MIT-licensed, publicly deprecated, with a named migration path, 1 star, 0 dependents. It is cheap to reject and cheap to replace — the opposite of a silently rotting dependency, and a useful contrast case when policy debates get abstract.

• Platform-level risk surfacing. The thinness and abandonment of the PHP/Symfony graph ecosystem is itself a strategic signal. If graph modeling is central to the product thesis, ecosystem fragility belongs in the platform risk register, not buried in a story-level spike.

When to Consider This Package

Consider only as a reference implementation, never as a dependency. Legitimate uses:

• Reading the source during a timeboxed spike (≤ 2 days) to understand what a Neo4j integration looks like in a Symfony app — specifically the service definitions, multi-connection config, and profiling hooks — and to estimate effort for a custom integration.
• Auditing an inherited legacy codebase, where the decision is a migration plan, not an adoption decision.
• Historical archaeology when investigating why a previous team's graph feature stalled.

Look elsewhere — always, for production. Concretely:

• Stack mismatch is disqualifying on its own. This is a Symfony bundle: no service provider, no facade, no config publishing, no Laravel-native integration. Adopting it means either bootstrapping Symfony kernel assumptions inside Laravel (fragile, duplicate container lifecycles) or bypassing the bundle and using the underlying client directly — at which point the bundle contributes nothing.

• Maintenance status is disqualifying on its own. The description itself redirects to neo4j-contrib/neo4j-symfony. An unmaintained package will not track Neo4j server upgrades, Bolt protocol changes, or PHP/Symfony major releases. You inherit every future incompatibility, with no escalation path.

• Zero dependents and 1 star means no peer signal. No Stack Overflow corpus, no third-party bug reports, no downstream validation. Every defect is yours to find — and you will find it in production.

• Security and compliance. No active maintainer means no CVE response path and no disclosure channel. On a supply-chain review this fails outright.

• Viable alternatives exist. For Laravel: the official neo4j/neo4j-php-client registered as a singleton in a thin service provider (config publishing, Octane-safe connection pooling, queue-safe handling, a normal composer update story). For Symfony: neo4j-contrib/neo4j-symfony, the maintainer's own redirect — validate its release cadence and Symfony version matrix before committing.

• Step back one level. If graph queries are incidental rather than central, Postgres with recursive CTEs, or a managed graph service over HTTP, usually beats standing up Neo4j inside a PHP monolith. The cheapest graph feature is often no graph database.

How to Pitch It (Stakeholders)

For executives — one line: This is an abandoned open-source connector — one star, zero users, its own authors pointing to a replacement — and it targets the wrong framework for us. We are not adopting it. It is useful only as a map of what a graph-database integration entails.

The strategic framing:

• Cost of adoption is not the license — it's the ownership. MIT and free to download, but with no maintainer we inherit all maintenance, upgrade, and security-response work. That converts a "free" dependency into a permanent, unbudgeted engineering line item, staffed by people who did not write it.

• Risk is asymmetric. Upside: a few weeks saved on integration scaffolding. Downside: a hard block on the next PHP, Laravel, or Neo4j upgrade — discovered mid-quarter, with no upstream to escalate to — plus a container-lifecycle hazard under Octane and queue workers. We decline those trades.

• Good news: there is a clean exit before we start. The authors name a maintained successor; the official PHP driver is framework-agnostic and supported. We lose nothing by starting there, and we keep the option to drop the bundle abstraction entirely.

• The real decision is the graph thesis, not the tooling. Before any integration work, confirm graph modeling is central to the product. If it isn't, the cheapest answer is not to run Neo4j at all.

For engineering — the ask:

1. Do not add this to composer.json. If present anywhere, flag it and open a migration ticket against the official PHP driver (Laravel) or neo4j-contrib/neo4j-symfony (Symfony).

2. Timebox a spike (2 days max) using neo4j/neo4j-php-client as the baseline; use this package's source only as a design reference for the read/write and connection-config paths.

3. Build a thin Laravel wrapper: one service provider, one config file, a connection factory and health check — kept thin so the driver stays swappable. Load-test the connection layer before any feature work.

4. Bring back a one-page comparison — maintained bundle/OGM vs. thin custom client — covering framework version support, upgrade cadence, test coverage, Bolt/Neo4j server compatibility, and a named maintenance owner. That document, not the star count, is what we decide on.