Bootstrapi Laravel Package

Getting Started

Treat this as a project template, not a dependency. You do not composer require it — you clone/copy it and own the code from that moment on:

git clone https://github.com/kot13/bootstrapi.git my-api
cd my-api && composer install
cp .env.example .env   # set DB creds, APP_ENV, JWT secret if present

It is a Slim 3 + stand-alone Eloquent (illuminate/database) + Zend-ACL skeleton. That means the Laravel muscle memory you have (Artisan, facades, service providers, Blade, app/Http/Kernel.php) is absent. What transfers is Eloquent, PSR-7 middleware concepts, and the general "route → middleware → controller → JSON response" flow.

Read these five things in this order before writing any code:

1. composer.json — pin the PHP version and see exactly which Illuminate/Slim/Zend versions you're inheriting.
2. public/index.php — the entire bootstrap: container wiring, middleware stack, error handler.
3. The settings/config directory — how DB, ACL, and error-detail flags are injected into the container.
4. The routes file(s) — how endpoints are declared and grouped (usually versioned /v1/...).
5. The ACL definition — where roles, resources, and allow rules live.

A good first task is a single end-to-end vertical slice: one migration, one Eloquent model, one controller, one route, one ACL rule, one PHPUnit test hitting the endpoint with a PSR-7 request. That exercises every layer at once, and if it works you know the skeleton is wired correctly.

Implementation Patterns

Container wiring is manual. Slim 3 uses Pimple. There's no autowiring by default — every controller, repository, and ACL instance needs an entry in the container or a factory closure. Establish a convention early (e.g. a dependencies.php with one factory line per class) or the container file will become the worst file in the repo.

Controllers should be thin and return JSON through a single helper. Keep one response factory (e.g. $this->json($data, $status)), and wrap all handlers so exceptions become consistent { "error": ..., "message": ... } bodies. Without that, Slim's default error renderer will happily emit HTML for a NotFound exception, which breaks every client.

Eloquent works, but you boot it yourself. The connection resolver, event dispatcher, and (if you want them) global scopes are set up in the bootstrap, not by Laravel. $model->toArray(), $hidden, $appends, accessors, relationships, and query scopes all behave as you expect. What you lose: Model::preventLazyLoading(), RefreshDatabase without work, factories/seeders, observers registration, and artisan make:model.

Migrations are your responsibility. Stand-alone Eloquent gives you Capsule/Schema but not the migration runner. Most skeletons in this family use Phinx or a hand-rolled runner; confirm which before you add tables. Keep migrations DB-agnostic and avoid enum if you ever want SQLite in tests.

ACL as middleware, keyed by route name. The Zend-ACL layer is typically a middleware that resolves the current role (from a JWT claim, session, or header), maps the request to an ACL resource (usually the route name), and throws a 403 on deny. Keep the resource names identical to your route names — that single convention prevents most ACL drift bugs.

Laravel-pattern translation table worth internalizing:

Integration pattern with a Laravel app. The pragmatic split is: this service owns its tables, and the Laravel app talks to it over HTTP with Http:: (or a signed internal client). Resist the temptation to point both apps at the same DB and share models — dual writers to one schema is how you get divergent domain rules and races.

Gotchas and Tips

• Version risk is the headline. Slim 3 and Zend-ACL are both EOL (Zend became Laminas; Slim 3 does not play nicely with PHP 8.1+). Check composer.json constraints against your target PHP before committing. Budget a fork-and-upgrade if you adopt it.
• displayErrorDetails leaks. It's a config flag in the settings array; leaving it true in production dumps stack traces and SQL into your JSON error responses. Gate it on APP_ENV on day one.
• You inherit maintenance. 86 stars and zero dependents means no upstream support community. Upstream fixes will never arrive via composer update; you must diff manually. Pin the commit you forked from in the README.
• CORS preflight often never reaches a route. If you add CORS middleware late in the stack, OPTIONS requests return 404/405. Put CORS first and short-circuit preflight there.
• ACL lookups on every request are a hidden cost. Don't build the ACL graph from the database per request — construct it once at boot or cache it, and only resolve the role per request.
• Validation is the biggest gap versus Laravel. Decide early between respect/validation, symfony/validator, or stand-alone illuminate/validation, and wrap it in one validate() helper so validation errors share a single JSON shape.
• Debugging: since there's no dd()/dump() and no log facade, set up a PSR-3 logger (Monolog) in the container early and use psysh for interactive inspection. A stack trace + the exact SQL being emitted (enable query logging on the connection in local) answers most questions faster than breakpoints.
• Extension points that pay off: swap the response serializer for Fractal once you have more than a handful of endpoints; add a league/oauth2-server or JWT middleware rather than rolling auth; keep transformers separate from models so you can change the wire format without touching persistence.
• Test harness is on you. Instantiate the Slim app from the container in PHPUnit with a mocked PSR-7 request rather than spinning up php -S per test — the skeleton usually has one example to copy.