Slimmer werken met Eloquent: van N+1 naar voorspelbare queries in Laravel

Eloquent maakt het makkelijk om snel iets werkends te bouwen.
Relaties aanspreken, collections itereren, klaar.

Maar zodra je applicatie groeit, wordt datzelfde gemak een nadeel. Je raakt het overzicht kwijt over wat er daadwerkelijk gebeurt in je database.

En dan wordt “het werkt” ineens “waarom is mijn Laravel applicatie traag”.

Het N+1 probleem is vaak niet het echte probleem

Het N+1 probleem in Laravel is bekend, maar meestal niet de enige oorzaak van performance issues.

Wat we vaker zien:

• impliciete lazy loading
• nested eager loading met grote datasets
• select * op brede tabellen
• geen inzicht in query gedrag

Bijvoorbeeld:

Project::query()

    ->with('tasks.comments.user')

    ->get();

Geen N+1, maar wel:

• veel data
• veel objecten in memory
• onvoorspelbare performance

Eloquent abstraheert, maar de database niet

Deze code:

Project::query()

    ->with('client')

    ->get();

Betekent nog steeds:

• een query op projects
• een query op clients
• mapping in PHP

Zodra je dat blijft beseffen, maak je betere keuzes.

Expliciet selecteren maakt verschil

Standaard:

Project::query()

    ->with('client')

    ->get();

Beter:

Project::query()
    ->select(['id', 'name', 'client_id'])
    ->with(['client:id,name'])
    ->get();

Waarom:

• minder data
• minder geheugen
• snellere responses

Bij grotere datasets maakt dit direct verschil.

Nested eager loading escaleert snel

Bijvoorbeeld:

Project::query()

    ->with([
        'tasks.user',
        'tasks.comments.user',
    ])

    ->get();

Dit zorgt voor:

• veel queries
• veel data
• veel hydration

Hier ontstaan vaak de echte performance problemen.

Zonder inzicht optimaliseer je blind

Veel issues zie je pas als je gaat meten.

Daarom gebruiken we tooling zoals:

• Laravel Debugbar
• Clockwork
• Laravel Telescope

Daarmee zie je:

• aantal queries per request
• query tijd
• duplicate queries
• herkomst van queries

Een endpoint dat “prima voelt” kan ineens 100+ queries doen.

Lazy loading zichtbaar maken

In development zetten we vaak:

Model::preventLazyLoading();

Dat voorkomt:

• verborgen queries
• onverwachte N+1 problemen

En dwingt expliciete data loading af.

Hydration en dataset grootte

Niet alleen queries zijn een probleem. Ook hydration.

Project::query()

   ->with('tasks')

   ->get();

Bij grote datasets:

• veel models
• veel geheugen
• tragere verwerking

Alternatieven:

DB::table('projects')->get();

of:

Project::cursor()->each(function ($project) {
    // ...
});

Conclusie

Laravel Eloquent performance verbeteren draait niet om één truc.

Het gaat om:

• weten wat je queries doen
• inzicht hebben in query gedrag
• bewust omgaan met data en relaties

Het probleem is meestal niet één query.
Het probleem is dat je niet ziet wat er gebeurt.

En precies daar zit de winst.