Web Laravel Package

Technical Evaluation

Architecture fit — eveseat/web is not a reusable library; it is the presentation tier of the SeAT platform. It is a Laravel package that bootstraps service providers, routes, middleware, menu registrations, permissions, and Blade/Vue assets into a host SeAT application, and it assumes the sibling packages (eveseat/api, eveseat/services, eveseat/eveapi, eveseat/console) plus their schema, permission model, and ESI integration. Fit is effectively binary: excellent if the host is a SeAT instance or SeAT-compatible app, near-zero if it is a general Laravel product. Treat it as an application shell you adopt, not a component you compose.

Integration feasibility — Standard Composer install with service-provider auto-discovery, vendor:publish for assets/config, and a Node-based asset build (or prebuilt assets). Feasible, but with high coupling: adopting it means adopting the SeAT deployment model — database schema, queue workers, scheduler, SSO, and ESI token lifecycle. Effort is medium for installation, high for operating it responsibly.

Technical risk

• Licensing (highest risk): GPL-2.0 is copyleft. If the surrounding product is proprietary or distributed, modifications to this package create source-disclosure obligations. This is a product-boundary decision, not an engineering one.
• Maintainership: 26 stars indicates a narrow user base and small contributor pool; bus-factor and long-term maintenance are real concerns.
• Version skew: Tight coupling to SeAT core and sibling packages means partial upgrades break silently. You need a pinned, tested version matrix.
• External dependency: Functionality is gated on EVE ESI; scope changes and outages are outside your control.
• Fork burden: Any UI customization beyond config pushes you toward a maintained fork, which compounds the licensing and upgrade problems.

Key questions

1. Are we deploying a SeAT instance, or building a SeAT plugin, or neither? (If neither, stop here.)
2. Is our product license-compatible with GPL-2.0, and can we accept copyleft on modifications?
3. Which SeAT core version and Laravel major are we pinning to, and who owns upgrades?
4. Do we need to modify views/controllers, or is configuration sufficient?
5. What is our fallback if ESI changes or the maintainer goes inactive?
6. Who is the named internal owner of this dependency?

Integration Approach

Stack fit — PHP 8.x, Laravel (verify composer.json constraints against your version), MySQL/MariaDB, Redis for cache and queues, nginx. Mechanically it fits any Laravel shop; domain-wise it only fits EVE Online tooling. Outside that domain there is no reuse value.

Migration path — Greenfield SeAT deployment is cleanest: provision a dedicated service, run migrations, seed permissions, configure ESI SSO. For brownfield, do not embed it in-process inside an existing application. Run it as a bounded, separately deployed service and integrate over its HTTP/API surface. This isolates upgrade blast radius and keeps the GPL boundary clean.

Compatibility — Maintain an explicit version matrix across eveseat/web, eveseat/api, eveseat/services, and SeAT core. Lock Laravel within the supported range. Verify required PHP extensions, queue driver, cron/scheduler configuration, and ESI scope coverage before committing.

Sequencing

1. Resolve the license/product-boundary question first — it can invalidate the whole plan.
2. Stand up a disposable sandbox with pinned versions and validate SSO/ESI end-to-end.
3. Confirm the permission model maps to your intended user roles.
4. Decide extension strategy: config-only, plugin, or maintained fork.
5. Establish the asset pipeline and CI (build, migrate, smoke test).
6. Only then plan production cutover, with a rollback path.

Operational Impact

Maintenance — Recurring work: tracking SeAT core releases, rebuilding frontend assets on upgrade, running DB migrations, and satisfying GPL source-distribution obligations for any modifications. Assume an ongoing maintenance allocation, not a one-time install.

Support — Community-driven (GitHub issues, SeAT Discord); no vendor SLA. Budget for internal ownership and designate a primary maintainer with a documented secondary.

Scaling — The web tier is largely stateless and scales horizontally behind a load balancer. Real bottlenecks are the queue workers (ESI rate limits), the database, and ESI token refresh. Separate queue workers from web nodes, cache aggressively, and monitor ESI call budgets.

Failure modes

• ESI outage or scope change breaks features silently → add feature-level health checks and alerting.
• Version drift after partial upgrades → pin container images, upgrade all SeAT packages atomically.
• Asset publish/build failure yields a broken UI with a healthy backend → include asset verification in the deploy smoke test.
• Token expiry and SSO misconfiguration lock users out → monitor refresh jobs.
• Migration failure mid-deploy → require tested rollback and DB snapshots.

Ramp-up — A Laravel-fluent engineer reaches productivity in the sandbox in roughly 1–2 weeks; production-hardened operation takes 3–4 weeks. The real ramp is domain knowledge — EVE corporation structures, ESI scopes, and the SeAT permission model — not the PHP. Plan for domain onboarding explicitly, and do not start until the licensing decision is closed.