Fastapi Laravel Package

Getting Started

Install as a dev dependency. This is a code generator — it has no runtime role in production, so keep it out of your deploy image:

composer require --dev larafast/fastapi

Before you write a single line, verify the version constraints in the package's composer.json (illuminate/support, php). The last tagged release is from March 2023, which predates Laravel 11's slim skeleton and the casts() method convention. If you are on Laravel 11/12, run composer why-not larafast/fastapi and expect to either loosen constraints or accept that it works but generates dated code. If it refuses to install, stop here and use php artisan make:model -mcr plus your own stubs instead.

Find the actual command name first. The package registers one or more Artisan commands in its service provider. Don't guess from the README alone:

php artisan list | grep -i fast
php artisan help fastapi:generate   # or whatever the signature turns out to be

Publish the stubs immediately. The whole value of a generator is the templates. If there is a publishable tag, publish it on day one and commit the result:

php artisan vendor:publish --provider="Larafast\FastApi\FastApiServiceProvider"

First use case: pick your simplest, most conventional resource — a Post with title, body, published_at. Generate it end to end, read every generated file, then wire the route manually in routes/api.php:

Route::apiResource('posts', PostController::class);

Confirm GET /api/posts returns a 200 with a JSON collection before you try anything with relationships or auth. That single round trip tells you whether the generated Resource, Controller, and Model actually agree with each other.

Implementation Patterns

Generate once, then own the code. Treat this as a one-shot scaffold, not a live dependency. The moment you hand-edit a generated controller, re-running the command becomes a merge problem. Commit the generated output as its own commit (git commit -m "scaffold Post CRUD") so a regeneration diff is readable rather than a wall of noise.

Generate into a clean tree, then move files. If your app uses domain folders (app/Domain/Blog/...) rather than the default app/Http/Controllers, generate into the default location, then move and fix namespaces. Fighting the generator's path conventions inside its own templates is slower than a mv and a find-and-replace.

Layer validation on top rather than expecting it. Most 2023-era CRUD generators emit a controller that accepts $request->all() and a model with $fillable set. That is not validation. Immediately pair each generated store/update method with a FormRequest:

php artisan make:request StorePostRequest

and change the signature to store(StorePostRequest $request). Do this per resource as you generate — retrofitting validation across twenty controllers later is the tax you pay for skipping it now.

Use the generated Resource as the API contract boundary. The output resource is where you decide what leaves the building. Add whenLoaded() for relationships and whenHas()/whenNotNull() for optional fields so your list endpoint doesn't accidentally serialize a nested graph:

'author' => new UserResource($this->whenLoaded('author')),

Workflow for a batch of models. When bootstrapping a greenfield API with several related models, the order matters: User → Post → Comment. Generate each, then go back and hand-wire the relations and foreign keys in the migrations. The generator does not know your graph; it only knows your column names.

Pair with Sanctum for anything non-public. The generated controllers have no auth middleware. Apply it at the route group level rather than per controller, so a newly generated resource is protected by default:

Route::middleware('auth:sanctum')->group(function () {
    Route::apiResource('posts', PostController::class);
});

Keep a "post-generate checklist" in the repo. Something like: routes registered, FormRequest wired, policy created and authorize() called, resource relationships guarded, factory added, feature test written. The generator handles roughly the first item on that list; the checklist is what makes it a net time saver rather than a source of half-finished endpoints.

Gotchas and Tips

The maintenance risk is the headline, not a footnote. 123 stars, zero dependents, and no release since March 2023 is a strong signal that this is a solo project on ice. Budget for the possibility that you adopt the stubs and drop the package. Because it's a generator, that's actually an easy exit — which is the main argument for using it at all.

Check what Laravel version the stubs target before generating en masse. A 2023 stub may produce protected $casts = [...] (fine, still supported) or may omit HasFactory, $guarded, or typed properties entirely. Generate one model and diff it against php artisan make:model --help output in your Laravel version. If the shape is wrong, edit the published stubs once instead of editing twenty generated files.

Regeneration will clobber your work. Look for --force in the command signature and simply never use it on a file you've touched. If there's no guard against overwriting, treat the command as destructive and only run it against paths you know are clean (git status first).

Route model binding and soft deletes are usually missing. Generated show/update/destroy often do Model::findOrFail($id). Switch to typed route-model-binding parameters (Post $post) — it is less code and gives you 404s for free. If the model uses SoftDeletes, remember destroy should call delete() and you likely want a separate forceDelete route.

Pagination is a config decision, not a code decision. If the generated index calls paginate(), the page size is hardcoded or defaults to 15. Decide early whether clients control per_page (validate it, cap it at ~100) and centralize that, otherwise every generated controller drifts.

Debugging generation failures: run the command with -v to see the underlying exception. The two most common causes are (a) the target directory doesn't exist and the package doesn't create it, and (b) the model namespace is misconfigured in config/fastapi.php (if one is published). If output lands in the wrong place, check that config file before assuming the package is broken.

Extension point: the stubs, not the code. If you find yourself editing the same three things in every generated controller, that's a signal to edit the published stub instead. That is the only durable customization surface this package offers — it almost certainly has no plugin or macro API.

Test the generator's output, not the generator. One feature test per generated resource (index returns 200, store validates, show 404s on a missing id) catches the majority of scaffolding bugs and takes about ten minutes with RefreshDatabase. This is cheap insurance given you can't rely on upstream fixes.

Have the fallback ready. If install or generation goes sideways, php artisan make:model Post -mfrc --api gets you most of the same output from core Laravel, and it tracks the framework version you're actually running. The honest assessment: this package's value is a small head start on a fresh API, and it should be evaluated as a disposable scaffold rather than infrastructure.