Hvad et framework reelt giver dig
Tag det først der faktisk er stærkt ved Laravel. Du får en gennemtænkt
auth-flow ud af kassen. Validering og routing der bare virker. En ORM der
lader junior-udviklere komme i gang hurtigt. Mail, kø-system og testopsætning
er der også. Bag det hele ligger et stort community med pakker til næsten alt,
fra fakturering til admin-paneler.
Tag det først der faktisk er stærkt ved Laravel. Du får en gennemtænkt
auth-flow ud af kassen. Validering og routing der bare virker. En ORM der
lader junior-udviklere komme i gang hurtigt. Mail, kø-system og testopsætning
er der også. Bag det hele ligger et stort community med pakker til næsten alt,
fra fakturering til admin-paneler.
Det tæller. Hvis du skal levere et MVP på tre uger og har et team der allerede
kender stakken, sparer det dig reel tid. Laravel-projekter bliver leveret
hurtigt og virker fint. Det skal med, før jeg forklarer hvor jeg ser problemet.
Hvor regningen kommer
Regningen kommer ikke i uge ét. Den kommer i år to og frem.
Først er der versionsskiftene. PHP-frameworks udvikler sig hurtigt, og en
major-version hvert år er ikke usædvanligt. Hver gang skal man læse changelogs,
opdatere afhængigheder, teste de steder hvor frameworket har ændret adfærd, og
muligvis omskrive kode der byggede på en API der nu er deprecated. Det arbejde
producerer ikke værdi for klienten. Det holder bare lyset tændt.
Så er der det jeg kalder framework-magi. Service containere, facades, model
events, dynamiske metoder. Det er smart når man kender det. Det er svært at
debugge når man ikke gør. En junior eller en ny freelancer kan stå med en
linje kode der gør noget, og det fremgår ikke af koden hvad der faktisk sker.
Frameworket har gjort det for læsbarhedens skyld, og det fungerer indtil det
ikke gør.
ORM’er fortjener et eget afsnit. Eloquent er behageligt at skrive. Det er
også en hyppig kilde til N+1-overraskelser, queries der ser uskyldige ud men
trækker hundredvis af rækker, og en generel afstand til den SQL der reelt
rammer databasen. Når performance bliver et problem, og det bliver det på et
tidspunkt, står man tilbage med at skulle forstå både SQL og det lag der
genererer den.
Endelig er der udvikler-markedet. Når et projekt er bygget i Laravel, kan det
vedligeholdes af Laravel-udviklere. Det lyder fint indtil man kigger på prisen
og tilgængeligheden, eller indtil klienten vil have en intern medarbejder ind
over og opdager at den eneste vej ind er en ramme der skal læres først.
Hvad jeg bygger i stedet
Min stak er bevidst lille. PHP 8.x med de moderne features: typed properties,
enums, readonly, named arguments. PSR–4 autoload via Composer. En tynd MVC med
en router, controllers, models og views. PDO direkte mod PostgreSQL, så SQL’en
er synlig og styrbar. Det er omkring 1500 til 2500 linjer kerne, og det er kode
jeg kan forklare på en eftermiddag.
Når noget er for stort til at hånd-rulle, henter jeg en fokuseret
composer-pakke ind. JWT-håndtering, PDF-generering, billedbehandling, Guzzle
til HTTP-kald, MailGun-SDK til mail. Pakker der gør én ting og som kan skiftes
ud uden at hele projektet falder sammen.
Resultatet er en kodebase hvor man kan læse en controller og se præcis hvad
der sker. Ingen skjulte hooks. Ingen magisk binding der får tingene til at
virke uden at det fremgår af koden. Hvis en query er langsom, kan man se
queryen. Hvis auth fejler, kan man følge den i tre filer.
Hvornår jeg alligevel ville vælge et framework
Det her er ikke et korstog. Der findes situationer hvor jeg ville pege på
Laravel selv.
Hvis klienten allerede har et internt Laravel-team, er det dumt at lægge et
fremmedlegeme ind ved siden af. Brug det de kan. Hvis projektet er en stor
admin-tung backoffice-applikation, kan et værktøj som Filament eller Nova
spare måneder, fordi det er præcis det de er bygget til. Hvis kravet eksplicit
er “vi vil have noget der matcher vores eksisterende stack”, giver det heller
ingen mening at trække i den anden retning.
Frameworks har deres plads. Jeg vælger dem bare ikke som default når
overheadet kan undgås.
Hvad det betyder for dig som klient
Konkret: den næste udvikler der skal røre din kode, behøver ikke have læst en
bog om et bestemt framework. Vedkommende skal kunne PHP og SQL. Det er en
større pulje af mennesker, til lavere timepris.
Du betaler ikke for at holde framework-versionen i live. Du betaler for
forretningslogik. Hvis projektet skal flytte hostingmodel om tre år, eller
hvis en del af det skal udtrækkes til en separat service, så sidder du ikke
fast i et økosystem der tager beslutninger på dine vegne.
Til gengæld får du ikke samme tempo i uge ét som et Laravel-team kunne
levere. Det er fair. Jeg arbejder lidt langsommere i starten, og giver dig
kode der er hurtigere at vedligeholde efter levering. Det er et bytte, og
det er bevidst.
Slut
Hvis du er ved at vælge leverandør og det her giver mening for dit projekt,
så tag en kort snak med mig. Jeg er ikke svær at få fat i, og jeg siger åbent
fra hvis Laravel passer bedre til det du skal bygge. Skriv til
[email protected] eller find kontaktformularen i menuen.
så tag en kort snak med mig. Jeg er ikke svær at få fat i, og jeg siger åbent
fra hvis Laravel passer bedre til det du skal bygge. Skriv til
[email protected] eller find kontaktformularen i menuen.