Laravel Jit Loader Laravel Package

Product Decisions This Supports

• Performance roadmap prioritization. N+1 queries are one of the most common causes of slow API endpoints and admin screens in Laravel apps. This package gives you a cheap, low-blast-radius lever to cut query counts on high-traffic models without a refactor — useful when deciding whether to spend a sprint on "performance" versus shipping features.
• Build vs buy vs do-nothing. The entire capability is one trait and one $jit property, roughly equivalent to Laravel's built-in protected $with. The real decision here is not "buy this package" but "do we standardize default eager-loading at the model layer (package, $with, or a base-model convention), or do we enforce explicit with() everywhere?" Framing it that way keeps the team honest about the tradeoff.
• Retrofit vs rewrite for legacy code. Its zero-config, per-model opt-in design makes it viable to drop into an existing codebase where with() calls are scattered across dozens of controllers, without touching call sites. This supports "incremental modernization" over "big-bang refactor" as a roadmap strategy.
• Developer-experience and onboarding decisions. Centralizing relationship declarations on the model lowers the cognitive load for new engineers and makes performance behavior self-documenting — a factor when deciding how much process (linters, review checklists, static analysis) to invest in enforcing query hygiene.
• Use cases it genuinely serves: read-heavy listing endpoints (feeds, admin tables, dashboards, exports), models where the same relations are needed in 90% of call sites, and small-to-mid teams where per-call-site discipline has repeatedly slipped.
• Explicit non-use case: write-heavy paths, or models where the "right" relations differ materially per endpoint — there the global model default is a blunt instrument and will over-fetch.

When to Consider This Package

Adopt when most of the following hold:

• You have measurably recurring N+1 problems on a small set of "hot" models, and the relations needed are consistent across call sites.
• You want the smallest possible change surface: no config files, no service provider ceremony, no controller edits — one trait and one property per model.
• You are on a Laravel version within its support window (last release 2020-11-11, Laravel 8 era) and can verify compatibility with your PHP/Laravel target before committing.
• You are comfortable vendoring or forking it. With 213 stars, a single maintainer, and no release in roughly five years, treat it as sample code you own rather than a dependency you track.
• It complements — rather than replaces — your existing use of explicit with() and Laravel's lazy-loading prevention.

Look elsewhere (or just use built-ins) when:

• Laravel's $with property already covers you. It does effectively the same job with zero third-party surface area. If the only differentiator you can articulate is "declared once," you may not need the package at all. This is the honest default answer for most teams.
• You need per-context control. If different endpoints need different relation sets, model-level defaults cause over-fetching and inflate payloads and memory.
• Maintenance risk is unacceptable. A stale package in a hot query path is a latent upgrade blocker. If nobody on the team will own a fork, prefer first-party mechanisms.
• The real problem isn't N+1. Missing indexes, unbounded result sets, un-paginated endpoints, or N+1s inside serializers/accessors won't be fixed by eager-loading declarations, and adopting this can create false confidence that "performance is handled."
• You need stronger guarantees. Consider Model::preventLazyLoading() in non-production plus CI query-count assertions; those catch regressions rather than papering over them.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that reduces database load and page latency by automatically pre-loading related records that would otherwise be fetched one-by-one. The cost is near zero — no licensing, no infrastructure, roughly an hour of engineering to trial on one or two models — and the downside is bounded because it's a one-line removal per model if it doesn't pay off. The caveat I'd flag up front: it's a 2020-era package with a single maintainer, so I'd position this as "adopt the pattern, own the code" rather than "add a dependency." I'd recommend a timeboxed pilot on our two slowest list endpoints and a measured query-count comparison before any broader rollout.

For engineering: One trait, one $jit property per model; relations are eager-loaded just in time, and it coexists cleanly with explicit with() and lazy-loading prevention. It removes the "remember to add with() here" failure mode that review process alone hasn't solved. Two things to settle together before we commit: (1) verify it works on our current Laravel/PHP versions, and (2) confirm the delta versus protected $with is worth carrying third-party code — if it isn't, we adopt the pattern in our base model instead and keep the dependency count flat. Either way, the decision is reversible per model, so the cost of being wrong is low and the cost of not measuring is higher.