andrey900/flight-skeleton
andrey900/flight-skeleton provides a clean starter skeleton for the Flight PHP microframework, with a minimal project structure and sensible defaults for lightweight apps, APIs, and prototypes. It helps you bootstrap routing, views, and basic organization without extra setup.
Architecture fit. This is not a Laravel package — it is a standalone application skeleton for the Flight micro-framework, pre-wired with Twig (templating), Monolog (logging), and Eloquent (illuminate/database) as the persistence layer. For a Laravel-centric organisation the honest framing is "adjacent but not Laravel": you get the ORM you already know, and lose nearly everything else (service container conventions, Artisan, migrations/seeders, queues, events, auth scaffolding, Blade, HTTP kernel middleware pipeline). Architecturally it targets a different class of workload — single-purpose HTTP services, webhook receivers, internal admin panels, scheduled/cron-fronted tasks — where a full Laravel boot is disproportionate overhead. If the requirement is "small PHP service that talks to the same MySQL schema as our Laravel apps," the fit is credible. If the requirement is "extend our Laravel product," the fit is poor and the effort is mostly re-implementation.
Integration feasibility. Because it is a skeleton rather than a library, there is no composer require into an existing codebase. Integration is composer create-project into a greenfield directory, or copy-paste-and-own. That means it lives beside your Laravel estate, not inside it: separate deploy pipeline entry point, separate .env/config conventions, separate route file, separate error handling. Shared code becomes a deliberate concern — you would likely extract domain models into a private Composer package consumed by both, or accept duplication. That is achievable but it is a design decision to make up front, not a detail.
Technical risk. High, concentrated in provenance rather than in the code pattern. Eighteen stars and a 0.19 composite score signal essentially zero community vetting: no meaningful issue history, no third-party production references, single-maintainer bus factor. There is no evident security policy, no visible CI/test matrix, and no versioned release discipline to rely on. The dependency surface is also unpinned in practice — Flight, Twig, Monolog, and illuminate/database each move independently, and a skeleton with loose constraints will drift out of compatibility with whichever PHP minor you standardise on. Eloquent-without-Laravel additionally means no migration runner: you inherit the query builder and schema builder but must bring your own migration tooling (Phinx, a hand-rolled runner, or raw SQL in CI), which is a real gap teams routinely underestimate.
Key questions.
Stack fit. Strong on the data tier (Eloquent → same MySQL/Postgres, same model idioms, same relationships), weak on the presentation and application tiers (Twig ≠ Blade, Flight routing ≠ Laravel routing, no container autowiring conventions to lean on). Monolog is neutral — Laravel uses it under the hood, so log shipping and formatting largely carry over. Net: reuse the models, rewrite the edges.
Migration path. Two directions matter. Inbound — adopt the skeleton for a narrowly scoped new service, keep Eloquent models in a shared private package so schema truth stays single-sourced. Outbound — treat this as a ramp, not a destination; when the service grows past a handful of routes and needs auth, queues, or a UI, the exit is either Laravel (rewrite routes/controllers, convert Twig to Blade, keep models and migrations intact) or Slim (less churn on the HTTP layer, same Twig/Eloquent story). Budget the rewrite explicitly at adoption time so growth is a planned step change rather than an incident.
Compatibility. Verify before committing: PHP version support across Flight 3.x, Twig 3.x, Monolog 3.x, and the illuminate/database major you standardise on; PSR-7/PSR-15 middleware compatibility if you need to reuse existing middleware; whether your observability stack (OpenTelemetry, Sentry) has first-class Flight support or needs a hand-written hook. Twig extensions you rely on in other projects may not have Flight-side wiring. Pin every major explicitly in composer.json and lock the file in the repo — do not inherit the skeleton's loose constraints.
Sequencing. (1) Two-to-three day spike: stand up the skeleton against a real non-production schema, implement one read endpoint and one write endpoint with auth and logging, measure what had to be hand-built. (2) Side-by-side compare against Slim + Eloquent and a minimal Laravel install on the same two endpoints; pick on total cost of ownership, not on lines of code. (3) If Flight wins, harden first — pin dependencies, add CI with a test matrix, add static analysis (PHPStan/Psalm), add a migration runner, write the ADR recording why this is not Laravel. (4) Only then take a second, production-facing service. Do not adopt it for anything on a customer-critical path until the hardening step is complete and one service has run a full quarter.
Maintenance. You own it from the moment you copy it. Upstream is a template, not a maintained library with a changelog and security releases, so "upgrade" means manually diffing your divergence against the skeleton — which decays fast. Realistic ongoing cost: dependency bumps you must validate yourself (no ecosystem doing it for you), a hand-built migration workflow, and bespoke wiring for anything Laravel would have given free. Estimate this as a permanent 10–20% engineering tax on the service, not a one-off setup cost.
Support. No vendor, no commercial backing, no community to escalate to. Internal support requires at least two engineers fluent in Flight — single-owner knowledge here is the dominant operational risk, more than the code itself. Document the Flight-specific idioms (routing, DI, error handling) internally, because onboarding material does not exist externally at any depth.
Scaling. Technically unremarkable: it is a stateless PHP-FPM/CLI process, so it scales horizontally exactly like any PHP service, and Eloquent scales as far as your database does. The scaling limits are organisational, not architectural — the moment you need background workers, a cache abstraction, rate limiting, or a real queue, you are building it. Plan the ceiling: this pattern comfortably serves low-to-moderate traffic single-purpose endpoints; it is the wrong shape for a service expected to accrete features for years.
Failure modes. (a) Silent dependency drift breaking a deploy on an unattended PHP minor bump. (b) Abandonment — upstream goes quiet and you are on a de facto fork with no upstream security patches. (c) Migration drift between this service and the Laravel apps sharing a schema, because there is no shared migration authority. (d) Observability blind spots — Monolog gives you logs, not traces or metrics, so incident diagnosis is slower than on an instrumented Laravel app. (e) Bus factor of one on the Flight-specific knowledge. (f) Scope creep — the service grows into a de facto application and you pay the Laravel rewrite anyway, later and under pressure.
Ramp-up. Low for anyone with Slim, Lumen, or raw PHP-FPM experience — Flight is deliberately small and readable. Moderate friction for Blade-only developers on Twig, and for Laravel-only developers who will reach for Artisan, facades, and the container and find nothing there; that muscle-memory gap is the main productivity dip and lasts roughly the first sprint. Budget a day of pairing to establish conventions before parallel work starts.
Recommendation. Treat as a spike candidate, not an adoption. The pattern (micro-framework + Eloquent + Twig + Monolog) is sound and the Eloquent overlap with your Laravel estate is genuine leverage, but an 18-star single-maintainer skeleton with a 0.19 score is not a foundation — it is a starting example. If the spike validates the shape, scaffold from it, immediately pin and harden, and hold it to services that are genuinely small and genuinely peripheral.
How can I help you explore Laravel packages today?