Routific Bundle Laravel Package

Technical Evaluation

Architecture fit — poor. Despite being filed as a Laravel/PHP package, foodcheri/routific-bundle is named and structured as a Symfony bundle (the -bundle suffix, the RoutificBundle namespace). That implies a Bundle class, a DependencyInjection extension, service definitions in YAML/XML, and a hard dependency on symfony/framework-bundle and symfony/http-kernel. Laravel has no bundle registration concept; there is no service provider, no facade, no config publishing. "Installing" it into a Laravel app means pulling in a parallel framework's kernel components to satisfy autoloading, or forking the source and stripping the bundle scaffolding to reach the thin client underneath. Either path is more work than writing the client ourselves.

Integration feasibility — low, and shrinking. The package is a wrapper over Routific's route-optimization (VRP) REST API: submit a set of visits and vehicles, poll for an optimized solution. That surface is small — a handful of endpoints plus auth headers. The value of an SDK here is genuinely marginal: Laravel's Http client covers the transport in a few dozen lines.

Technical risk — high on every axis:

• Abandonment. Last release 2017-04-14. Nine years of drift from both the Routific API contract and the PHP ecosystem. The SDK almost certainly encodes a v1-era endpoint shape and will return 404/410 or silently mis-parse responses if Routific has versioned or restructured its job/response schema.
• Runtime incompatibility. A 2017 package will target PHP 5.6/7.0–7.1 with declare(strict_types) gaps, and will pin Guzzle at ^5.0 or ^6.0. Modern Laravel requires Guzzle 7 and PHP 8.2+. Composer will either refuse to resolve or force a downgrade chain that breaks the host app. Expect deprecation-level fatal errors on PHP 8.x (dynamic properties, implicit nullable params, each()-era idioms).
• Zero signal. 0 stars, 0 dependents, no CI badge, no test suite of consequence. There is no community that has exercised this code in production, no issue history to mine for known failure modes, and no one watching for CVEs in its transitive tree. Our security review would start from a blank page and end in a fork.
• Bus factor zero. Single-org, single-era artifact from a defunct delivery startup's internal tooling.

Key questions for the team:

1. Does Routific publish an official PHP SDK today, and does its current API version match what this bundle assumes?
2. Is route optimization actually on the roadmap, or are we evaluating a wrapper for a vendor we haven't selected?
3. What is the real cost of a 150-line internal adapter versus the cost of auditing and maintaining a fork of this package on every PHP/Laravel upgrade?
4. Who owns the fork if we take it — and what is the exit plan if Routific changes its contract?

Integration Approach

Recommendation: do not adopt the package. Treat it as reference documentation, not a dependency.

Stack fit. Target Laravel's native Http client against Routific's documented REST endpoints, with credentials in config/services.php and a typed config object. If we want SDK ergonomics, build a small internal package (app/Domain/Routing) exposing DTOs for Visit, Vehicle, and OptimizationJob, plus a RoutificClient that speaks the current API version.

Migration path. If someone has already wired the bundle in a branch, quarantine it: introduce an interface first —

interface RouteOptimizer {
    public function optimize(OptimizationRequest $r): OptimizationResult;
}

— with a RoutificOptimizer implementation. Nothing else in the codebase talks to Routific directly. This makes the vendor swappable and reduces the bundle to a throwaway prototype behind the seam.

Compatibility. Verify against the live API in a sandbox account before committing to any contract: auth header format, request payload schema, job status polling semantics, and error codes. Contract-test the response shapes into fixtures so schema drift by Routific surfaces as a failing test rather than a silent production regression.

Sequencing.

1. Spike: two days against the Routific sandbox with raw Http calls; capture real request/response payloads.
2. Decision gate: does the API model match our domain (time windows, capacity, multi-depot) at acceptable cost?
3. Build adapter + interface + fixtures; no third-party routing SDK in composer.json.
4. Only if a stable, maintained official SDK later appears, swap the implementation behind the interface.

Operational Impact

Maintenance. Fully in-house. There is no upstream to patch, so every PHP minor-version bump becomes our audit. A ~150-line adapter we wrote is cheap to maintain and legible in review; a forked 2017 SDK is neither. Budget the fork as a recurring tax, not a one-time cost.

Support. No vendor support for the package, no documentation beyond what we reverse-engineer. Routific supports its API; that is the channel that matters. Log a runbook: how to rotate the API token, how to reproduce a failed optimization, how to read the vendor's job IDs.

Scaling. Scaling is governed by Routific's API, not by this package: per-account quotas, rate limits, and the async job model. Route optimization is a long-running operation — plan for job submission, persisted job ID, and polling or webhook completion, never a synchronous call inside a web request. Our adapter should push optimization onto a queued job with backoff and a hard timeout.

Failure modes to instrument:

• Submission succeeds, polling never resolves → orphaned job, no delivery plan at dispatch time.
• Timeout between request send and response receipt → duplicate job creation; needs an idempotency key or a reconciliation sweep.
• Vendor contract drift (versioned endpoints retired) → hard 4xx at submit, catchable and alertable.
• Stale SDK assumptions (if the bundle is used) → malformed payloads returning 200 with empty routes, the worst case because it looks successful.
• Token expiry / quota exhaustion → distinguish 401/403 from 429 in the adapter and alert differently.

Ramp-up. Low for the recommended path — any mid-level Laravel engineer can read Routific's docs and write the client in a day; the learning cost is domain knowledge (VRP constraints, time windows, capacity), not library knowledge. That domain learning is the same regardless of whether we use this package, which is precisely why the package adds no durable value.

Bottom line: the score of 0 is accurate. The correct disposition is to archive this evaluation with a note — "reference only; vendor API is the integration surface" — and to spend the effort on a thin, owned adapter behind a stable interface.