Connection Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on relationship modeling. The real decision this package surfaces is whether the product needs a first-class, typed, directed relationship graph or another one-off join table. The package itself is a Symfony 2-era bundle (13 stars, zero dependents); the durable asset is its pattern — an adjacency edge table (source, target, type, direction, metadata) with a service layer on top. Leverage it as a design reference for that decision, not as a composer require on a Laravel roadmap.
• Roadmap triage for "secretly graph-shaped" features. Follows, likes, tags, hierarchies, "related products," content cross-links, org/permission inheritance, and recommendation seeds all reduce to "object A relates to object B, with a type and a direction." A generic edge model lets product ship these without a migration per feature — a schedule and cost lever, not just an architecture preference.
• Timing of data-model investment. Committing to an adjacency edge table early is dramatically cheaper than retrofitting joins per feature later. For any roadmap with two or more social/linking features in the next two quarters, the edge model is a sequencing decision a PM can defend.
• Scope boundaries for graph features. This pattern is a good fit for sparse, human-curated, low-fan-out links. It is a poor fit for multi-hop traversal, shortest-path, ranking, or recommendation over millions of edges — those are graph-store (Neo4j, Postgres AGE) or recursive-CTE problems. Using this as the boundary marker prevents overscoping an ORM into a graph engine.
• Not a dependency decision on a Laravel product. Despite the framing, this is KitanoConnectionBundle — Symfony DI classes and Doctrine mappings with no service provider, no publishable config, no facade. On a modern PHP 8 / Laravel 10+ stack, the constraint resolution alone exceeds the cost of writing the edge model in-house. The PM decision is "borrow the pattern, skip the package."

When to Consider This Package

Consider it — as a dependency or as a design reference — when:

• You are on a legacy Symfony 2.x codebase already using Kitano bundles, where the maintenance and constraint debt is already sunk and the integration cost is incremental.
• You need typed, directed, arbitrary object-to-object connections and want to stop adding a join table per relationship type.
• Your query patterns are simple — adjacency lookups, shallow expansion in the request path, no multi-hop traversal.
• You are prepared to fork and own it. Thirteen stars, zero dependents, dormant vendor, no release cadence means you are the maintainer of record: named owner, org-controlled VCS, CI matrix, security triage with no upstream CVE feed.

Look elsewhere when:

• You are on modern PHP (8.x), current Symfony, or Laravel. Expect PHP 5.x-era constraints in composer.json that hard-conflict with the PHP 8.1+ floor. Treat any residual Doctrine coupling in a Laravel port as a stop sign.
• You need traversal performance, shortest path, transitive closure, or graph analytics — use a graph database or Postgres recursive CTEs. The library contributes nothing for traversal, indexing, or query performance.
• Your relationships are few and stable — native ORM associations (ManyToMany, morphToMany polymorphic pivots) are simpler, supported, and free.
• Security or compliance matters. An unmaintained dependency is a supply-chain and audit liability with no response path.
• Recommendation for most teams: treat it as a reference design. Extract the pattern into a small internal Eloquent-based package — connections table with a unique composite index, BFS with a visited set and hard max-depth, batched whereIn per hop. Leave the bundle.

How to Pitch It (Stakeholders)

Executives. Low sticker price, high ownership cost. A 13-star, Symfony 2-era bundle with zero dependents is source code we would adopt, not a supported library — so budget fork maintenance, PHP-version upgrades, and security patching as if we wrote it. The genuinely valuable asset is the pattern: one directed-connection graph instead of a growing pile of relationship tables, which lets us ship follows, tags, and cross-links without a migration each time. We can implement that in-house in days and keep it inside our own support and security posture. Recommendation: no dependency, yes to borrowing the model. Revisit only when a graph-shaped feature lands on the roadmap — and even then, evaluate a maintained alternative or a graph store first.

Engineering. It is a thin abstraction over an adjacency edge entity with direction and type. It solves "we keep adding join tables," but contributes nothing for traversal, indexing, or query performance, and the Symfony glue is inert outside Symfony's kernel. If we need this capability, define our own connections table with composite indexes on (source, type) and (target, type), keep writes behind a service layer, and build the guardrails the package lacks: cycle detection with max-depth limits, caps on per-node fan-out, a scheduled integrity job for orphaned edges (polymorphic edges cannot use foreign keys), and a unique composite index to prevent duplicate edges corrupting traversal counts. Do not add this to composer.json on Laravel or modern Symfony — the constraint resolution alone will cost more than writing the model. If the domain later proves genuinely graph-heavy, the correct escalation is Postgres AGE, Neo4j, or a dedicated graph service — not a 2015 bundle.