Sde Laravel Package

Technical Evaluation

Architecture fit. SDE is a Laravel package that imports EVE Online's Static Data Export into a relational schema, exposing it through Eloquent models, DTOs, and artisan seeding commands. It fits naturally only if the product domain is EVE-adjacent (wormhole mapping, industry planning, killboard analytics, market tools). For a generic Laravel SaaS, it brings ~hundreds of MB of domain data and a large migration surface for no benefit. Fit must be validated against a concrete EVE data requirement before adoption.

Integration feasibility. Standard Composer install, service provider auto-discovery, publishable config/migrations, and artisan commands. v0.6.1 is a routine minor release: additive DTOs (type effects, dogma, entity DTOs), two new position2D fields on solar systems, a flags concept, plus fixes for Jove system data, download timeout, PHPStan level-max, and nullable Effect/EffectModifier DTO fields. No removals or deprecations announced, but pre-1.0 semver means additive-looking changes (nullable DTO fields, new columns) can still break typed consumers.

Technical risk.

• Pre-1.0 churn. Six minor releases to date; DTO shape and schema are still settling. The v0.6.1 nullable-field change on EffectDto/EffectModifierDto is a concrete example of a silent contract change.
• Single-maintainer bus factor. One author, one repo. No vendor SLA.
• Data-volume and seed reliability. The download-timeout fix confirms SDE fetches are slow/flaky; seeding is resource-intensive enough that the release notes call out "improved resource usage" across two commits.
• External schema drift. CCP changes the SDE format and content (the Jove-system corrections are exactly this); the package must chase upstream, and consumers inherit that lag.
• Positive signals. PHPStan level-max clean, strict types added, DTO layer maturing — engineering discipline is above average for a hobby-scale package.

Key questions.

1. Which SDE build/expansion are we pinned to, and how often must we refresh?
2. What is the resulting DB footprint (rows and disk) for the tables we actually need?
3. Does the package support incremental/delta imports, or is every refresh a full re-seed?
4. Which Laravel and PHP versions are supported, and is that matrix tested in CI?
5. Are the new DTOs and position2D fields stable enough to build on, or should we code against our own adapter types?
6. Is there a documented upgrade path between minor versions, and any changelog policy?

Integration Approach

Stack fit. Requires Laravel with artisan command and migration support; verify composer.json constraints against our Laravel/PHP versions before committing. The package is data-layer only — it does not dictate application architecture, so it can sit behind a repository/facade boundary cleanly.

Migration path. Install into a dedicated database connection (not the primary app schema) to contain the large tables and to allow drop-and-reseed without touching transactional data. Publish config and migrations, run the seed commands inside a queued/isolated job, and expose only the models we need via our own read layer.

Compatibility. Pin the version exactly (0.6.1), not a caret range, given pre-1.0 semver. Wrap all DTO consumption in an anti-corruption layer so nullable-field changes like those in v0.6.1 are absorbed in one place. Assert the SDE build identifier at boot and fail fast if the seeded data version does not match what the application expects.

Sequencing.

1. Spike: install in a scratch Laravel app, run full seed, measure duration and DB size.
2. Validate the specific entities (solar systems with new position2D, types, effects/dogma) against a hand-checked sample.
3. Build the adapter layer and version-assertion guard.
4. Add a scheduled refresh job with retry/timeout policy mirroring the upstream timeout fix.
5. Only then wire into feature work.

Operational Impact

Maintenance. Expect to track upstream closely; a v0.7 or v1.0 will likely carry breaking changes. Budget recurring effort for version bumps and re-seeds, and treat the adapter layer as the containment boundary. The PHPStan/strict-types discipline lowers the cost of reading the source when debugging, which partially offsets the bus-factor risk.

Support. GitHub issues only, single maintainer, no commercial backing. Escalation path is "fork and patch." For anything business-critical, plan for the ability to vendor the fork — the codebase is small and static-analysis-clean, so this is realistic.

Scaling. The dominant cost is the seed job, not query load: large download, large insert volume, long transaction. Run seeds out-of-band on a worker with generous timeouts, never on web request or in a deploy hook. Read queries against indexed static tables scale fine. Full re-seed per SDE release is acceptable if refresh cadence is low (expansion-level), painful if we need daily deltas.

Failure modes.

• Download timeout / truncated SDE archive → partial or corrupt seed (mitigated upstream in v0.6.1, but not eliminated).
• Upstream SDE schema change → seeder crashes or silently skips fields.
• Nullable DTO fields returning null into non-nullable consumer code → runtime type errors.
• Version skew between seeded data and application expectations → wrong system/type data surfaced to users.
• Full re-seed during peak usage → DB contention and lock waits.

Ramp-up. Low framework ramp-up, moderate domain ramp-up. Engineers need working knowledge of EVE's data model (systems, types, dogma effects, flags) to use the DTOs correctly, and must understand the seed/refresh lifecycle. Estimate a few days for a Laravel developer to be productive, plus a half-day of EVE-domain orientation. Pair the spike with a written runbook covering install, seed, refresh, and rollback.