Laravel-upgradecyclus

Waarom Laravel niet altijd meer leuk is vanwege de upgradecyclus

Vroeger ontwikkelde ik projecten alleen met PHP, zonder framework.

Verschillende klassen, functies, etc.

Totdat het een puinhoop werd en ik op zoek ging naar iets meer structuur.

Laravel kwam op mijn pad en ik vond het geweldig.

Eindelijk een gestructureerde manier om projecten te schrijven met Model-, View- en Controller-structuren met de Blade-engine en het elegante Eloquent Model.

Het probleem

Het probleem is: de projecten die ik voor 2015 bouwde met PHP4 en PHP5, draaien en werken in principe nog steeds (alleen na de overstap van mysql naar mysqli of PDO). Zelfs als ik ze upgrade naar PHP7 of PHP8.

Mijn Laravel-projecten zijn uitgegroeid tot monsters die elke zes maanden zelfzorg vereisen in de strakke updateschema's van Laravel en PHP.

  • Volgens Laravel duurt het updaten naar een nieuwe versie van Laravel 15 minuten tot 1-2 uur.
  • In werkelijkheid gaan dingen kapot. Vooral third-party pakketten kunnen het strakke upgradeschema van Laravel niet bijhouden.
  • Een voorbeeld is wanneer u van Laravel 6 naar Laravel 7 upgradet. Laravel 7 ondersteunt PHP8, terwijl sommige first-party pakketten zoals Telescope versie 3.* alleen met PHP7 werken. En sommige third-party pakketten werken alleen met Laravel 7 en met PHP8. Dit maakt het hoppen van versie naar versie erg lastig.
  • Zelfs first party-pakketten verdwijnen snel. De vereiste vervanger is niet altijd de beste. Bijvoorbeeld Laravel Breeze in plaats van het laravel/ui-pakket.

Voor een onafhankelijke ondernemer of een zelfstandige ondernemer is dit niet houdbaar.

Het is waarschijnlijk ook een van de redenen dat deze Laravel-ontwikkelaar schat dat meer dan 60% van de Laravel-sites een versie gebruiken die ouder is dan 2 jaar.

Alles draait om subfunctionaliteiten die veranderen.

Het compileren van je stylesheets moet bijvoorbeeld gebeuren met Gulp/Elixir in 2015, daarna met Mix en nu met Laravel Vite.

Wanneer u npm run uitvoert, verschijnt er meestal een foutmelding die u moet debuggen.

Ik snap het punt, Laravel is nog steeds leuk voor grote projecten en organisaties.

En ja, voor de meeste projecten is het waarschijnlijk nog steeds makkelijker om te bouwen op basis van een goede boilerplate, dan om helemaal vanaf nul te beginnen.

Maar voor kleine organisaties met weinig ontwikkelaars is het behoorlijk lastig om alles bij te werken.

Is Laravel Shift de oplossing?

Laravel-verschuiving zou kunnen helpen, maar met een prijs van $29 per upgrade is dit niet te duur als je de dure westerse zakelijke programmeringskosten in aanmerking neemt.

Voor minder ontwikkelde landen en mensen met minder financiële middelen kan het upgraden van een app naar de nieuwste Laravel-versie al snel een paar honderd dollar kosten.

De geweldigheid van Laravel

Ik wil niet dat dit artikel te negatief klinkt.

Het is slechts een wens van Laravel-gebruikers en -ontwikkelaars om misschien een brainstorm te starten over een manier om de kern minder variabel te houden of beter bestand te maken tegen toekomstige PHP-upgrades. Dat zou hopelijk resulteren in meer up-to-date sites met de nieuwste PHP- (en Laravel-)versie.

Hoe dan ook, ik zie niet de perfecte oplossing. Ik begrijp dat een web-app enige zorg vergt.

Misschien een eenvoudigere versie voor langetermijnondersteuning (LTS), die niet elk half jaar crasht en robuustere kernfunctionaliteiten biedt.

Om het nog even samen te vatten: Laravel heeft veel voordelen:

  • Minder spaghetti-code
  • Geweldige structuur
  • Zoveel opties en first party pakketten. Zoals Vapor voor serverless, Cashier voor facturering, etc.
  • Grote gemeenschap

Heb je nog andere suggesties? Aarzel niet om ze in de comments te plaatsen.

Laat een reactie achter

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

nl_NLNederlands
Scroll naar boven