DEV Community: Loic Aron Mbassi Ewolo

Your Mermaid diagram is a valid input for a Laravel API generator

Loic Aron Mbassi Ewolo — Sat, 25 Jul 2026 14:45:40 +0000

Data models get designed in diagrams and implemented in code, and the two drift apart from day one. The diagram in your README says Post belongsTo Category; the code says otherwise; nobody notices until a migration fails.

The fix I landed on for laravel-api-generator: make the diagram the input. Two formats work, YAML and Mermaid.

YAML

# api-schema.yaml
options:
  pest: true
  postman: true

entities:
  Category:
    fields:
      name: string unique
    relations:
      posts: hasMany Post

  Post:
    fields:
      title: string
      content: text
      status: enum(draft,published) default=draft
      published_at: datetime nullable

php artisan make:fullapi --schema=api-schema.yaml

Look at what's missing: Post never declares belongsTo Category, and there's no category_id field anywhere. The generator synthesizes the inverse relation and its foreign key column. You declare one side, like you would explain it to a colleague, and both sides exist in the code.

The enum line generates the backed enum class, the model cast, Rule::enum validation and a factory that picks random cases. I wrote about that chain in more detail in part 1.

This is the one I use most, because GitHub renders it in the PR:

Mermaid

php artisan make:fullapi --mermaid=docs/erd.mmd

Both erDiagram and classDiagram work. Cardinalities map to the right Eloquent relations, UK markers become unique fields, a deleted_at column enables soft deletes. Markdown fences and comments are stripped, so a diagram pasted straight from an AI chat works as-is. Review the diagram in the pull request, merge, generate. No drift, because there's nothing to drift from.

The VS Code extension takes the same Mermaid input without the terminal, and it draws the reverse view too: an interactive diagram of your entities (zoom, pan) inside the editor. The diagram goes in, the API comes out, and the canvas shows you what actually exists.

[VISUEL 15 (fichier 13) : vraie capture du diagramme interactif de l'extension, habillée]

[VISUEL 10 (fichier 13) : split-screen diagramme Mermaid rendu / arborescence générée]

Custom primary keys propagate

Country:
  fields:
    code: string primary
    name: string
  relations:
    cities: hasMany City

This was the request that took me the longest in v3.6. City gets a country_code column typed like the key, ->references('code') in the migration, exists:countries,code in validation, and the model declares $primaryKey, $incrementing and $keyType. The generated tests use getKey() so the same suite passes with either key style. Polymorphic relations (morphTo, morphOne, morphMany) are supported in schemas too.

Day 30

Every scaffolder demos well on day 1 and gets deleted on day 30, because regenerating would wipe your manual work. So regeneration isn't the evolution path here. Patching is:

php artisan make:fullapi Post --add-fields="excerpt:text,seo_title:string"

This writes an incremental Schema::table migration with a down(), and patches $fillable, the casts, the PHPDoc, the validation rules, the factory and the resource in place. Your custom methods are not touched. Fields that already exist are skipped. The DTO and the tests are deliberately left alone and reported as manual follow-ups, because guessing there felt more dangerous than useful.

Practical notes

Dev dependency, MIT, generated code has no reference to the package. Works in CI and with AI coding agents; one YAML file describing the whole API turns out to be a much better target for an agent than "create twelve files". The extension mentioned above also adds a form builder with live preview, imports from a database or an OpenAPI spec, and one-click migrate, seed and docs.

Docs: https://nameless0l.github.io/laravel-api-generator/
GitHub: https://github.com/Nameless0l/laravel-api-generator
Part 1 (architecture): link · Part 2 (--from-database): link

If you have opinions about what a schema format should support, the issues are open. Mine changed three times while building this.

Turning an existing database into a documented Laravel API

Loic Aron Mbassi Ewolo — Wed, 22 Jul 2026 11:04:16 +0000

The projects I dread are the ones where the database is the only documentation. Twenty tables, foreign keys, years of production data, and either no API layer at all or a pile of copy-pasted controllers nobody wants to touch.

Writing models, controllers, validation and tests for twenty existing tables by hand takes days. This is the problem that made me add --from-database to laravel-api-generator:

composer require --dev nameless/laravel-api-generator
php artisan make:fullapi --from-database

The generator reads your live schema and produces, for each table, the same stack it builds in normal mode: model with full PHPDoc, thin controller, service, DTO, form requests with real validation rules, resource, factory, seeder, policy, and written tests (PHPUnit, or Pest with --pest).

[GIF demo-from-database.gif (voir fichier 12) : vraie exécution en terminal, pas Claude Design]

What the introspection actually reads

I spent a lot of time making this more than a column dump.

A VARCHAR(255) NOT NULL UNIQUE column doesn't just become a string field. It becomes required|string|max:255|unique:users,email in the form request and fake()->unique()->safeEmail() in the factory.

Foreign keys turn into relations on both sides: posts.user_id gives you Post::user(): BelongsTo and User::posts(): HasMany, both typed in the PHPDoc. On Laravel 11+ the generator reads the real constraints; it also falls back to the <table>_id naming convention for older schemas without them.

Pivot tables are detected (two foreign keys and nothing else) and become belongsToMany on both models, instead of generating a useless PostTag entity. Column pairs like commentable_type + commentable_id become a proper morphTo. Enum columns become native PHP backed enums with casts and Rule::enum validation. A deleted_at column switches the whole entity to soft deletes, restore endpoint included.

You rarely want all tables

php artisan make:fullapi --from-database --tables=posts,categories,comments

Two defaults exist to save you from yourself: migrations are not regenerated (the tables already exist; pass --with-migrations if you want them as code-of-record), and the users table is skipped so your customized User.php survives. --tables=users overrides that explicitly.

The payoff

The generated controllers are Scramble-friendly, so if you have Scramble installed, /docs/api serves browsable OpenAPI docs immediately. Add --postman and you can hand a collection to the frontend team the same morning.

If the team lives in VS Code, the extension runs the same import from a table picker, and its Open API Docs button closes the loop: it checks Scramble, starts the server if none is running, detects the port and opens the docs in the browser. It even offers to create .env from .env.example on a fresh checkout.

Legacy database at 9:00, documented and tested API at 9:15. The business logic still needs a human. The plumbing doesn't.

Notes

The package is a --dev dependency and the generated code doesn't depend on it, so you can treat it as a one-shot migration tool if that's all you need.

Docs: https://nameless0l.github.io/laravel-api-generator/
Part 1, on the architecture it generates: part1

If you have a schema that you think would break it, I want to see it. Weird databases are how this feature got better.

A complete Laravel API with clean architecture in 30 seconds, tests included

Loic Aron Mbassi Ewolo — Sat, 18 Jul 2026 20:23:24 +0000

I counted the files I create every time I add a resource to a Laravel API. Model, migration, controller, a form request, a resource, a factory, a seeder, a policy. If the project cares about architecture, add a DTO and a service class. Then the tests.

Twelve files before the first line of actual business logic. I got tired of typing them, so I wrote a generator. It's MIT, I maintain it solo, and v3.6 shipped this week.

One command

composer require --dev nameless/laravel-api-generator

php artisan make:fullapi Post --fields="title:string,content:text,status:enum(draft,published),published_at:datetime"

Output:

app/
├── DTO/PostDTO.php
├── Enums/Status.php
├── Http/
│   ├── Controllers/PostController.php
│   ├── Requests/PostRequest.php
│   └── Resources/PostResource.php
├── Models/Post.php
├── Policies/PostPolicy.php
└── Services/PostService.php
database/
├── factories/PostFactory.php
├── migrations/xxxx_create_posts_table.php
└── seeders/PostSeeder.php
tests/
├── Feature/PostControllerTest.php
└── Unit/PostServiceTest.php
routes/api.php  ← apiResource registered

[GIF demo.gif (voir fichier 12) : vraie exécution en terminal, pas Claude Design]

The VS Code extension: same engine, no terminal needed

[VISUEL 11 (fichier 13) : VRAI screenshot de l'extension VS Code, habillé ensuite dans Claude Design]

If you'd rather click than type, the free VS Code extension drives the same make:fullapi command, so the files are identical. You describe the entity in a form (fields, enums, relations, options) and a live preview shows the exact code before anything is written. Or you skip the form and import from your existing database, a YAML schema, a Mermaid diagram, or an OpenAPI/Swagger spec.

The button I always demo first is Open API Docs: it checks that Scramble is installed (and offers to install it if not), finds a running Laravel server or starts php artisan serve itself, detects the port, and opens the interactive docs of your new API in the browser. Migrations and seeding are one-click too, and if .env is missing the extension offers to create it from .env.example. You can go from an empty Laravel project to a browsable, documented, tested API without opening a terminal once.

The part I actually care about: the architecture

Plenty of tools can spit out a model and a migration. What I wanted was the layering I end up building by hand on every serious project. The generated controller is thin:

public function store(PostRequest $request)
{
    $dto = PostDTO::fromRequest($request);
    $post = $this->service->create($dto);

    return new PostResource($post);
}

Validation lives in the form request, business logic in PostService, and data crosses layers as a typed readonly PostDTO. When the project grows, the place where new logic should go already exists. That's the whole point.

Models your IDE can read

Each generated model comes with a real PHPDoc block:

/**
 * @property int $id
 * @property string $title
 * @property string $content
 * @property Status $status
 * @property \Illuminate\Support\Carbon|null $published_at
 * @property-read \Illuminate\Database\Eloquent\Collection<int, Comment> $comments
 */
class Post extends Model

So $post->title autocompletes in VS Code and PhpStorm without installing ide-helper. The generator already knows every field and relation at generation time; writing the docblock costs it nothing.

What `enum(draft,published)` produced

That one field definition created five coherent pieces:

App\Enums\Status, a native backed enum
the cast on the model
Rule::enum(Status::class) in both form requests
fake()->randomElement(Status::cases()) in the factory
$table->enum('status', [...]) in the migration

Before v3.6 the package just mapped enums to strings. Wiring the whole chain took longer than I expected, mostly because of the factory.

The tests are written, not scaffolded

This was my line in the sand. Most generators leave you empty test classes. Here php artisan test is green right after generation: index, store, validation errors, update, delete are all covered with real assertions.

it('creates a post', function () {
    $payload = Post::factory()->raw();

    $this->postJson('/api/posts', $payload)
        ->assertCreated();

    $this->assertDatabaseHas('posts', ['title' => $payload['title']]);
});

That's the Pest style, from the --pest flag. Without it you get PHPUnit classes with the same coverage.

Docs, Postman, auth

--postman writes a ready-to-import collection at the project root. The controllers are written so Scramble can build OpenAPI docs from them without annotations. --auth scaffolds Sanctum (register, login, logout, middleware on your resources).

There is also a --from-database mode that reverse-engineers an existing database into full APIs, but that deserves its own article.

Zero lock-in

The package installs with --dev and the generated code has no dependency on it. No base classes, no runtime helpers, nothing to use. You can remove the generator after generating and the app doesn't notice. If you don't like the generated style, publish the 24 stubs (php artisan vendor:publish --tag=api-generator-stubs) and edit whichever ones you want.

Where it stops

It scaffolds a clean REST baseline and then it's out of the picture. Your domain logic, your weird queries, your edge cases: still your job. The difference is that you write them inside a service layer that already exists, with baseline tests already passing.

Links

composer require --dev nameless/laravel-api-generator
php artisan make:fullapi Product --fields="name:string,price:decimal,stock:integer" --pest
php artisan test

Docs: https://nameless0l.github.io/laravel-api-generator/
GitHub: https://github.com/Nameless0l/laravel-api-generator
VS Code extension: https://marketplace.visualstudio.com/items?itemName=Nameless0l.laravel-api-generator

If you try it and something breaks, open an issue. Schema edge cases reported by users have driven most of the recent releases, and I'd rather hear about yours than guess.