Registry Bridge Laravel Package

Technical Evaluation

Architecture fit. fleetbase/registry-bridge is not a standalone Laravel package in the conventional sense — it is the integration layer between a Fleetbase host application (Laravel/PHP backend + Ember front-end) and the Fleetbase registry service. It ships three coupled surfaces in one release: (1) Laravel-side registry models and API endpoints under ~registry/v1/ (engines, registry-extensions, installed, purchased, categories), (2) console/engine wiring, and (3) Ember UI components (ExtensionCard) consumed by the host app's extension marketplace pages. The v0.1.11 highlights confirm this coupling directly: two of the three changes are PHP/Eloquent connection routing, and one is an Ember template/component argument mismatch. A TPM should treat this as an application extension with a front-end contract, not an installable library — the version pins on fleetbase/ember-ui v0.4.6 and fleetbase/ember-core v0.3.26 mean the package cannot be upgraded independently of the Fleetbase UI build.

Integration feasibility. Feasible only inside a Fleetbase deployment. There are no migrations, no artisan commands, and no config publish step in this release, so the upgrade surface is a composer update plus an Ember asset rebuild. The risk is version lockstep: the dependency bump to ember-ui 0.4.6 / ember-core 0.3.26 implies the host app must already be on (or move to) those versions, and the changelog does not state a minimum Fleetbase core version. That is the single biggest unknown to resolve before committing to an upgrade window.

Technical risk. Moderate, and mostly version-velocity risk rather than design risk. The package is pre-1.0 (v0.1.11), meaning semver gives you nothing — patch releases have already contained behavioural environment changes. The connection-pinning fix (#41) is the notable one: registry models and category queries now always use the live connection, even in sandbox mode. That is the correct fix for the 500s, but it hard-codes a split-brain data topology — sandbox for operational data, live for registry metadata — which future contributors will trip over, and which means sandbox environments now make real outbound calls to the registry.

Key questions.

• What is the minimum supported Fleetbase core version for v0.1.11, and does the ember-ui 0.4.6 pin force a host-app front-end upgrade?
• Does "always use the live connection" mean sandbox/test installations will make unauthenticated or credentialed calls to the production registry, and is there a documented override?
• Is registry-bridge intended for third-party consumption at all, or is it an internal Fleetbase monorepo component merely published for install convenience?
• What is the support contract pre-1.0 — is there a deprecation policy, or is it "read the changelog"?

Integration Approach

Stack fit. Requires: PHP/Laravel host (Fleetbase), the Fleetbase API surface, and an Ember build pipeline capable of consuming fleetbase/ember-ui and fleetbase/ember-core. If your platform team is Laravel-only, half this package is out of scope and the ExtensionCard fix is irrelevant to you. Confirm the split before scoping.

Migration path. Low-ceremony from v0.1.10: no migrations, no commands, no schema changes. The practical migration is (a) bump fleetbase/registry-bridge to v0.1.11, (b) ensure ember-ui >= 0.4.6 and ember-core >= 0.3.26 resolve, (c) rebuild and re-deploy front-end assets, (d) re-verify registry endpoints in the target environment. Treat the front-end rebuild as a required step, not optional — the @resource vs @extension fix only lands after the asset build.

Compatibility. Three gates: Fleetbase core version, Ember UI/core versions, and the registry service API version. The release notes are silent on the first and third. Do not deploy to a shared production environment until the Fleetbase core baseline is confirmed against the ember-ui 0.4.6 requirement.

Sequencing. Recommended order for a TPM-run upgrade:

1. Inventory which registry endpoints your deployment actually calls, and from which contexts (web, console, queue, test).
2. Confirm current Fleetbase core and Ember UI/core versions against the new pins.
3. Upgrade in a staging environment first, specifically loading /purchased and any extension listing page — that is where the silent-rendering bug lived, and where a regression would be least visible in logs.
4. Exercise the console/test path explicitly, since that is the behaviour that changed: registry endpoints should now return data rather than 500 in console test mode.
5. Only then promote to production, paired with the front-end asset deploy in the same window.

Operational Impact

Maintenance. Ongoing composer + Ember dependency hygiene is unavoidable: this package moves in lockstep with ember-ui and ember-core, so every Fleetbase front-end release is a potential forced upgrade. Budget a recurring cadence rather than one-off effort. No database or command maintenance is introduced by this release.

Support. Upstream support is community-only — GitHub Discussions and Discord, no stated SLA. For a business-critical marketplace flow, that means your team owns triage. The good news is that both fixes in this release are narrow, well-described, and traceable to PRs (#40, #41), and #41 in particular is the kind of bug that would otherwise burn days of "why is this 500ing only in console tests" investigation. This release is a net reduction in support burden.

Scaling. Scaling concerns are not in this package; they live in the registry service and in how often your deployment fans out purchased/installed/categories queries. Note that pinning those queries to the live connection removes any sandbox caching or isolation you may have been relying on — under load, registry table reads now hit the primary. If the marketplace pages are high-traffic, check for N+1 behaviour on the extensions listing before a launch.

Failure modes to watch.

• Silent UI degradation. The ExtensionCard bug rendered cards with no name, icon, price, or date and produced no error — for an unknown number of releases. Any front-end change here needs a visual smoke test, not just a green API suite.
• Environment leakage. Registry reads now bypass sandbox by design. A test suite or staging job can reach the live registry; audit credentials on non-production environments accordingly.
• Version drift. A host app pinned to an older ember-ui will fail resolution or, worse, resolve to a mismatched UI build with the card bug still present.
• Console-mode regressions. The console engine now depends on specific ember-ui/ember-core versions; console-only workflows are the least-exercised path in most deployments and deserve explicit CI coverage.

Ramp-up. A contributor needs Laravel/Eloquent fluency for the backend half (models, connection routing, API endpoints) and Ember/component-argument familiarity for the front-end half. The @extension vs @resource class of bug is exactly what a competent Ember developer catches immediately and a Laravel-only developer does not — so plan for two skill sets on the team, or accept that UI regressions in this package will go undetected.

Verdict. Adopt. v0.1.11 is a genuine quality improvement — it fixes a test-environment 500 that blocked console/CI coverage and a silent rendering bug affecting the purchased-extensions surface. The costs are the pre-1.0 version lockstep and the live-connection pinning behaviour, both of which are manageable with a documented upgrade runbook. Hold adoption only if your Fleetbase core cannot move to the ember-ui 0.4.6 baseline within your current release train.