Sanjab Laravel Package

Technical Evaluation

Architecture fit

Sanjab is an opinionated, monolithic admin layer that mounts inside a host Laravel application rather than beside it. Its service provider registers routes, middleware, a menu tree, a widget/dashboard registry, and a model registry that generates CRUD screens from Eloquent metadata (columns, relations, translatable fields). That shape determines the fit:

• Fits: a conventional Laravel monolith, single primary database, Eloquent-first domain model, Blade/Vue 2-era frontend, internal back-office users, and a team willing to own a fork.
• Does not fit: API-first or headless backends, multi-tenant SaaS requiring per-tenant admin isolation or theming, polyglot persistence, event-driven services where the admin surface must live outside the domain app, or any environment needing an SPA admin deployed independently of the app.
• Coupling is high and bidirectional. Sanjab reaches into the app (models, policies/permissions via a Spatie-style role-permission layer, auth guard config, uploaded file storage) and the app reaches back into Sanjab (menu/widget registration in service providers). Extraction later is not a clean unplug.

Integration feasibility

• Installation is the easy part: composer require, publish config/assets, run install/migration commands. A competent Laravel developer can get a screening environment up in under a day.
• The binding constraint is version compatibility. An archived package pins constraints against the Laravel/PHP versions current at archive time; a host on Laravel 10/11/12 will almost certainly fail dependency resolution and require a fork that relaxes constraints, refreshes transitive dependencies, and re-tests. Budget that as the real integration cost, not the composer require.
• Frontend assets ship pre-compiled. Any UI change beyond config/CSS overrides requires reconstructing the original Vue/Node toolchain, which may be non-reproducible. Treat the UI as frozen unless you commit to a frontend rebuild.

Technical risk

• High, and concentrated at the highest-value attack surface. An admin panel is the most attractive target in the estate. An unmaintained one receives no security patches and no disclosure channel. Expect findings in generic CRUD controllers (IDOR on record routes, missing per-field authorization), file-upload handling, rich-text/markdown rendering, and mass assignment through the form builder.
• Dependency rot is the dominant risk, not the package code itself. Sanjab pulls in a web of permission, translation, slugging, image, and utility libraries from the same era; each is an independent abandonment and CVE vector. A software composition analysis (SCA) run is a gate, not a formality.
• Model-introspection CRUD is authorization-fragile. Generated screens trust fillable/guarded and field registration; a single misconfigured model silently exposes columns or accepts over-posted attributes.
• Bus factor of one, with documentation largely in Persian and a small (87-star) community. There is no commercial support path and no realistic expectation of upstream fixes.
• License is MIT — permissive and fork-friendly, which is the one favorable structural fact here: you can own it, if you choose to.

Key questions

1. Which exact Laravel/PHP version matrix does the last release support, and what does a composer update on our target version actually resolve to?
2. Can we reproduce the frontend build from source, or are we accepting a frozen UI?
3. What does SCA report across the full transitive tree — count of abandoned packages and known CVEs?
4. Is there an internal owner (named engineer + team) prepared to fork, patch, and carry this for the product's lifetime?
5. Do our authorization model and tenancy requirements map onto Sanjab's guard/permission assumptions, or will we fight them?
6. What is the data-exit story if we abandon it — are admin-side artifacts (menus, widget config, uploads) portable or package-shaped?
7. Have we benchmarked against a maintained alternative (e.g., Filament) on the actual requirement set, not on familiarity?
8. Is the admin surface internet-exposed or network-restricted? (This alone can shift the risk verdict.)

Integration Approach

Stack fit

Only pursue where the host is a Laravel monolith on a supported version, with a small internal user base and network-restricted admin access. If the host is on a modern Laravel release, the honest framing is: this is a fork-and-own decision, not a package adoption. If it is a greenfield build, the fit is poor — the maintenance burden is known and a maintained alternative is available.

Migration path

There is no meaningful "migrate onto Sanjab" path for an existing admin; it is a greenfield overlay on existing models. The realistic paths are:

1. Time-boxed evaluation — stand it up against a copy of staging, register two representative models, exercise permissions and file upload. Kill or continue at a fixed date.
2. Scaffold-and-strangle — use it to stand up internal back-office screens quickly, with the explicit expectation that screens migrate to an owned admin as they mature. Only sane if screens are genuinely disposable.
3. Fork-and-own — vendor the repo, relax constraints, pin every transitive dependency, rebuild assets, add a CI security gate. Treat as an internal product with a roadmap, not a dependency.

Path 1 is the default; Path 3 must be a deliberate, funded decision by an accountable owner.

Compatibility

• Hard gates: PHP and Laravel version resolution; database driver support; auth guard/middleware coexistence with the host's existing login and session handling; storage disk compatibility; the host's existing permission package version (two permission systems coexisting is a common and painful failure).
• Soft gates: Persian-first localization and RTL defaults — verify against our actual UI language requirements; theme/asset pipeline conflicts with any existing frontend build.

Sequencing

1. Constraint spike (1–2 days): resolve dependencies in a throwaway branch on our exact Laravel/PHP version. If it fails, stop — everything downstream is a fork decision.
2. Security and license review (SCA + manual auth probe): gate on CVE count, abandoned transitive packages, and a documented authorization test on generated CRUD.
3. Scoped POC (1–2 weeks): two models end-to-end, one widget, one upload, role-restricted access, behind VPN. Measure developer time to add a screen — that number drives the whole business case.
4. Decision gate: adopt / fork-and-own / reject. Written, with owner named.
5. Only then: production integration, with a documented exit plan and an inventory of every package-shaped artifact we would have to reimplement.

Operational Impact

Maintenance

• Effectively frozen upstream. Our maintenance load is whatever we choose to take on: dependency patches, PHP/Laravel upgrade compatibility, security fixes, and any UI change. Assume zero hours from upstream and budget accordingly — realistically a recurring fraction of an engineer, spiking at every major framework upgrade.
• Framework upgrades become coupled: we cannot move to a new Laravel major until someone patches Sanjab's constraints and verifies the admin still works. This is the single largest long-term cost and should be presented as such.

Support

• No vendor, no SLA, no CVE feed, no disclosure process. Internal support means an internal owner with context, and a runbook that exists before the first incident.
• Community support is essentially nil at 87 stars and archived status; the practical support channel is reading the source.

Scaling

• Adequate for tens of concurrent internal admin users on typical CRUD workloads; it is a server-rendered/admin-panel pattern, not a hot path.
• Known pressure points: generic CRUD listing endpoints degrade with large tables unless pagination and query scoping are audited; N+1 queries from relation columns in list views; synchronous file handling for large uploads; and translatable-field joins multiplying query cost. All are fixable in a fork, none are fixable upstream.
• Admin traffic should never share a scaling budget with customer-facing traffic; isolate it.

Failure modes

• Security incident via unpatched admin — highest severity, highest likelihood over a multi-year horizon.
• Upgrade deadlock — host framework upgrade blocked by package constraints, forcing an emergency rewrite under deadline.
• Silent authorization gap — a newly registered model exposes data because no one audited its field registration; discovered late, typically during an audit.
• Asset/toolchain loss — a UI change becomes impossible because the build cannot be reproduced.
• Key-person loss — the one engineer who understands the fork leaves; institutional knowledge goes with them.

Ramp-up

• Fast for the basics: a Laravel developer ships a CRUD screen in hours, which is exactly the temptation this package presents and exactly why it gets adopted in shadow IT.
• Slow for the parts that matter: authorization semantics, the widget/menu registry, translatable fields, and asset rebuilding take a few weeks to a month to reach real fluency.
• Documentation is thin and Persian-language, so ramp-up is source-reading. Plan for one engineer to become the designated owner and write the internal docs; without that, the ramp-up cost is paid repeatedly and invisibly.

Bottom line for the decision record: this is a low-cost, high-tail-risk scaffolding tool with no upstream future. It is defensible only as a network-restricted internal back-office on a legacy-but-supported Laravel version, with a named owner, a fork budget, an SCA gate, and a written exit plan. It is not defensible for anything customer-facing, regulated, internet-exposed, or on a framework version we intend to upgrade — where a maintained alternative is available and the only thing Sanjab saves is a few weeks we will pay back with interest.