Eseye Laravel Package

Technical Evaluation

Architecture fit. eveseat/eseye is a Laravel-native wrapper around EVE Online's ESI REST API, shipped as a Composer package with a service provider, facade, and publishable config. That makes it a good architectural fit for any Laravel monolith or modular app that already talks to ESI — it hides Guzzle plumbing, OAuth refresh cycles, retry/backoff, and pagination behind fluent calls. The tighter coupling to SeAT is both the value proposition and the constraint: if we are not on SeAT (or a SeAT-compatible plugin surface), we inherit SeAT-shaped assumptions (token storage, user model, config keys) that may not match our domain.

Integration feasibility. High for a greenfield Laravel/SeAT build; medium for an existing service. Realistic effort is low if we accept the package's opinions on token storage and caching; it grows if we need to bridge our own identity store, queue strategy, or cache backend. Key feasibility gates are Laravel/PHP version support (auto-discovery, illuminate/* constraints), ESI compatibility (endpoint coverage and versioning vs. current ESI), and whether it bundles its own OAuth flow or delegates to SeAT's SSO. The GPL-2.0 license is a first-class feasibility question, not a footnote: copyleft distribution obligations can block proprietary redistribution or SaaS-adjacent bundling depending on legal read.

Technical risk.

• Provenance/supply chain: "repository: unknown" with 53 stars means no canonical upstream to audit, patch, or pin. That is a material risk for anything touching auth tokens.
• Maintainer bus factor: small community package, single-vendor gravity toward SeAT; abandonment or ESI drift is plausible.
• Secrets handling: OAuth refresh tokens are high-value; we must verify encryption-at-rest, scoping, and storage model rather than assume.
• ESI volatility: CCP deprecates endpoints and adjusts rate limits on their cadence; the package's own release history (metadata shows a future-dated release, itself a red flag on release hygiene) does not prove it tracks ESI changes promptly.
• License and metadata hygiene: GPL-2.0 plus an unknown repo and suspicious date means dependency review must precede any pilot.

Key questions.

• Which Laravel, PHP, and SeAT versions are supported, and is SeAT a hard or soft dependency?
• Does it own the OAuth refresh/token store, or delegate to SeAT's SSO? How are refresh tokens encrypted and scoped?
• How does it model ESI rate limits and error budgets — retries, backoff, circuit-breaking?
• What is the endpoint coverage vs. our required ESI surface, and the deprecation policy?
• Who maintains it, and can we legally fork/vendor under GPL-2.0 without distribution obligations?
• Can we pin to a commit/tag and get a reproducible build (given no visible repo)?

Integration Approach

Stack fit. Best fit is a Laravel application (9–11 era) running SeAT 4/5 or an equivalent Laravel service, PHP 8.1+, with a cache backend (Redis preferred) and a queue worker for token refresh and paginated sync jobs. It is a natural drop-in for the "EVE tooling" layer — character auth, asset/industry/market pulls — and a poor fit for non-Laravel services or polyglot environments, where a thin HTTP adapter is cleaner.

Migration path. Treat the package as an implementation detail behind our own EsiClient interface:

1. Define a narrow internal port (public endpoints, authenticated calls, pagination, token lifecycle).
2. Wrap eseye in an adapter; run it alongside the existing raw-Guzzle or hand-rolled client.
3. Migrate read-only public endpoints first, then authenticated endpoints, then token ownership last.
4. Keep a feature flag per endpoint family so rollback is a config change, not a deploy.
5. For existing refresh tokens, verify the package accepts pre-provisioned tokens (or import via a one-off SeAT-compatible store) before cutover.

Compatibility. Pin exact Composer constraints; test against the Laravel/PHP matrix in CI; verify ESI base URL and version handling; confirm cache and queue driver abstraction; validate SeAT plugin/event compatibility if we run SeAT plugins. Treat Last release: 2026-02-23 as unverified until we reproduce the build.

Sequencing. (1) Legal/license review and provenance audit; (2) spike one public and one authenticated endpoint; (3) adapter + feature flags; (4) token store and refresh-path validation under load; (5) pilot a single low-risk feature; (6) expand endpoint families; (7) retire the legacy client. Budget one discovery sprint plus one to two delivery increments for the pilot.

Operational Impact

Maintenance. Ownership shifts to us the moment we adopt: we must track ESI changes, PHP/Laravel upgrades, and security patches in a package with an unclear upstream. GPL-2.0 gives us the right to fork and vendor, which is the realistic mitigation — but only if we accept the obligation to publish modifications when distributing. Plan for a maintained internal fork or a hard version pin with a scheduled review cadence.

Support. No vendor SLA; support is community/upstream-issue shaped. We need a named internal owner, a documented "what to do when ESI breaks" runbook, and an escalation path for auth outages. SeAT coupling means SeAT upgrades become coordinated change windows.

Scaling. ESI rate limits are the real scalability wall, not PHP throughput. The package's caching and pagination helpers reduce call volume, but we must set cache TTLs deliberately, use queue workers for bulk syncs, and monitor ESI error budgets per token and per app. Token refresh at fleet scale (many characters) needs a shared store and concurrency-safe refresh to avoid stampedes.

Failure modes. Token refresh failure or revoked scopes (silent auth loss); ESI downtime or breaking changes (hard errors mid-sync); rate-limit storms from unbounded pagination; cache stampede on cold keys; stale cache serving wrong market/asset data; GPL contamination discovered late; upstream abandonment leaving us on an unpatched auth path.

Ramp-up. Engineers need Laravel service-provider literacy plus EVE/ESI domain knowledge (OAuth scopes, character/corporation tokens, ESI versioning) and SeAT familiarity. Realistic onboarding is roughly one to two weeks for a Laravel-fluent engineer, longer for the OAuth/token-store internals. Document the adapter boundary early so new hires interface with our port, not the third-party package.