Gebruik van Laravel in de praktijk

[DimitryK]

Goedemiddag mede-tweakers,

Momenteel staan wij op het werk op het punt te gaan migreren van een verouderde PHP code omgeving naar een gestructureerd framework. De keuze hiervoor is gevallen op Laravel, met Doctrine2 (ipv Eloquent) als ORM en Twig (ipv Blade) als templating system. Symfony2 was tweede keuze, maar de snelheid van Laravel, de zeer actieve community en goede beschikbaarheid resources en packages hebben de doorslag gegeven.

In principe voldoet Laravel dus aan al onze eisen en wensen, maar toch zitten we nog met een vraag in ons achterhoofd. Zijn er bedrijven met applicaties van vergelijkbare grootte die ervaring hebben met het gebruik van Laravel als framework?

Om een idee te geven van de grootte van onze applicatie:

• Ruim 3 miljoen gebruikers
• Ruim 240 tabellen
• 200+ miljoen records (ongeveer 60GB)

Graag horen we het van jullie als er mensen zijn die ervaring hebben met het gebruik van Laravel voor vergelijkbare applicaties. Welke problemen jullie tegengekomen zijn, hoe de performance is en of je eventueel iets anders aanbeveelt.

Bij voorbaat dank

[TJVB]

Ik heb geen ervaring met applicaties van deze grote, merk wel dat het lazy loading van Eloquent wel handig werkt. En de caching was ook uit te leggen aan collega's die amper ervaring hebben met frameworks.

Ik ben eigenlijk nieuwsgierig wat de reden is om doctrine2 en twig te gebruiken. In eerste instantie lijkt de grote van de community een punt maar door het afwijken van de basis (wat in principe geen enkel probleem hoort te zijn) maak je juist de community die er gebruik van maakt een stuk kleiner

[DimitryK]

Doctrine biedt meer vrijheid wat betreft de database interactie. Hier gaat het dan ook niet alleen om performance van queries (waar eloquent in sommige gevallen wat tegen man vallen), maar ook om het principe. Eloquent is een activerecord ORM, waarbij ieder object een database row voorstelt. Doctrine is een datamapper ORM, waarbij de database logica en storage objects gescheiden zijn. Dit biedt in ons geval meer flexibiliteit en een stukje veiligheid.

De keuze voor Twig is dat het veel lijkt op het template systeem dat nu gebruikt wordt en wat makkelijker is dan Blade. Twig sprak het team ook meer aan dan Blade qua syntax.

[Antrax]

Ik gebruik voor een van mijn klanten Symfony2. Deze had legacy code + 430~ tabellen en 349TB aan data.
De reden waarom ik Laravel heb laten varen is dat de perfomance voor de applicatie in symfony toch een aantal seconden sneller was.

Het is dus aan de applicatie zelf en hoe het bedrijf zich daarbij voelt.

[kwaakvaak_v2]

Ik sluit mij aan bij wat meer mensen zeggen, bijzondere keuze om juist één van de speer punten van Laravel, Eloquent te vervangen voor Doctrine2. Ik kan het verkeerd hebben, maar ik was juist onder de indruk dat veel Laravel packages juist leunen op Eloquent voor DB dingen. Die moet je dan allemaal gaan ombouwen voor zover je die wilt gebruiken.

Ben ook wel nieuwsgierig naar het snelheid aspect van Symfony2, hebben wij het hier over request tijd of over developer leer tijd? Want dat eerste is zeker wat aan te doen, bij S2 is het heel verstandig om je goed te verdiepen in de verschillende cache lagen. Uit de doos staan die verre van optiemaal voor productie. En qua developer tijd, is het vooral goede afspraken binnen het team. Wel/Geen annotaties, alle configuratie bestand in één formaat ipv een mix tussen yaml en xml.

Niet dat ik vind dat het een domme keuze is om Laravel te kiezen, alleen de redenen klinken mij persoonlijk wat bijzonder in de oren.

[DimitryK]

De keuze begint nu steeds meer te verschuiven naar Symfony gezien het wisselen van de database lagen in de toekomst tot problemen kan leiden en Doctrine toch standaard is voor Symfony.

De snelheid ging over de request tijd. Uit verschillende benchmarks bleek dat Symfony ruim 100% trager was dan laravel. Maar dat valt allemaal op te lossen natuurlijk.

[Amanush]

Caching is de key. Als iets sloom draait, draai het dan gewoon niet.. cache it!

[afraca]

Met Laravel kan je dat qua grootte wel aan denk ik, maar het blijft een framework met aardig wat abstracties. Ik denk eerlijk gezegd niet dat je veel verschil met Symfony zou merken. Gewoon goed inlezen over de verschillende cache-lagen. (Ligt ook beetje aan je server setup)
http://laravel.com/docs/5.1/cache (let op je cache provider)
https://github.com/barryvdh/laravel-httpcache

Al je queries loggen met
https://github.com/barryvdh/laravel-debugbar

En kijken wat je kan optimaliseren daar.

Maar als je inderdaad Eloquent met Doctrine wisselt ga je ongetwijfeld wel tegen wat vreemde dingen aanlopen. Het is ongetwijfeld vast mogelijk overigens, maar je gaat er flink wat ontwikkeltijd aan kwijt zijn.

Ook voor Laravel moet je wel wat tweaken om die performance te krijgen. Route caching, "compiled" classes e.d.

Overigens zie je wel wat vaker dat Twig Blade vervangt.

[krvabo]

Mijn ervaring met Symphony2 is beperkt tot 1 project wat gemaakt is door iemand anders, en ik onderhoud in moest doen (zonder kennis van S2), dus deze ervaring is mogelijk wat skewed:

Symphony2 heeft een erg grote leercurve als je nog nooit met een vergelijkbaar framework hebt gewerkt. Je gebruikt met name S2 omdat je een hoge mate van standaardisatie wilt hebben en mogelijk met een aantal heel standaard dingen wat winst in ontwikkeltijd.

Als je gaat kijken naar performancewinst van custom code naar een S2-project ga je dat gewoon niet vinden. De enige reden dat frameworks als S2 niet compleet traag als stront zijn, is caching. De caching in S2 is wel erg sterk en zal bij dingen die te cachen zijn er voor zorgen dat je website prima accesstijden heeft, maar zodra het complex wordt met veel verschillende datasources dan kun je het wel vergeten. Voor redelijk simpele CRUD-websites is het een prima tool.

De querybuilder van Doctrine is erg sterk en kan leuke queries opbouwen, maar je zult er wel goed voor in de documentatie moeten duiken omdat het gewoonweg veel verschillende mogelijkheden heeft. Het debuggen van (een complex) iets gemaakt door de query builder is overigens wel een ramp.


Doe met mijn ervaring wat je wil, maar begrijp wel dat een framework over het algemeen bedoeld is om standaardisatie in code te forceren en de developers een kortere ontwikkelingstijd te geven, niet om je website snel te krijgen. Mocht je dus grote websites hebben met specifiek geschreven code dan moet je heel goed gaan kijken welke code je wel, en welke code je niet in Symfony2 wil hebben.

Het project had 1+ miljoen users en had een exporteerfunctie die een (groot) aantal filters op de users gooide, waarbij extra tabellen werden gekoppeld. De query builder kon er wel prima mee overweg, maar de performance was _absurd_ slecht. Met een groot aantal verschillende filters duurde het exporteren van 100k gebruikers letterlijk uren, in een enkel geval zelfs 12+ uur.

Deze exportcode heb ik uiteindelijk helemaal herschreven zonder gebruik te maken van Doctrine, waarbij de duur terugliep naar onder de minuut.

[ Voor 14% gewijzigd door krvabo op 20-07-2015 00:16 ]

[Firesphere]

Amanush schreef op zaterdag 18 juli 2015 @ 22:28:
Caching is de key. Als iets sloom draait, draai het dan gewoon niet.. cache it!

Nee, absoluut niet.

Als je applicatie traag is, moet je profilen en verbeteren. Caching is een manier om de server te ontlasten, niet om snelheid te winnen in je applicatie. Als je caching gaat gebruiken als remedie tegen een trage applicatie, heb je het niet begrepen.

[kwaakvaak_v2]

krvabo schreef op maandag 20 juli 2015 @ 00:12:


Het project had 1+ miljoen users en had een exporteerfunctie die een (groot) aantal filters op de users gooide, waarbij extra tabellen werden gekoppeld. De query builder kon er wel prima mee overweg, maar de performance was _absurd_ slecht. Met een groot aantal verschillende filters duurde het exporteren van 100k gebruikers letterlijk uren, in een enkel geval zelfs 12+ uur.

Deze exportcode heb ik uiteindelijk helemaal herschreven zonder gebruik te maken van Doctrine, waarbij de duur terugliep naar onder de minuut.

Bij Doctrine kan het soms wel helpen om alleen de DBAL te gebruiken en de uitkomst naar een indexed array of desnoods objecten van stdClass() te laten castten ipv naar domain models.

En voor debuggen, is er gewoon een logger.

PHP:

$em->getConnection()
  ->getConfiguration()
  ->setSQLLogger(new \Doctrine\DBAL\Logging\EchoSQLLogger())
;

Of er voor zorgen dat ze in monolog komen en ze op dat niveau afsplitsen naar een losse log file.

[Tjolk]

Firesphere schreef op maandag 20 juli 2015 @ 00:16:
[...]

Nee, absoluut niet.

Als je applicatie traag is, moet je profilen en verbeteren. Caching is een manier om de server te ontlasten, niet om snelheid te winnen in je applicatie. Als je caching gaat gebruiken als remedie tegen een trage applicatie, heb je het niet begrepen.

Dit.

[krvabo]

kwaakvaak_v2 schreef op maandag 20 juli 2015 @ 09:11:
[...]

En voor debuggen, is er gewoon een logger.

PHP:

$em->getConnection()
  ->getConfiguration()
  ->setSQLLogger(new \Doctrine\DBAL\Logging\EchoSQLLogger())
;

Of er voor zorgen dat ze in monolog komen en ze op dat niveau afsplitsen naar een losse log file.

offtopic:
Dat heb ik ook gebruikt, maar dan krijg je een 'doctrine query language' te zien en niet de daadwerkelijk opgeleverde sql query. Als je de waarde die zijn meegegeven aan de DQL wil zien dan moet je een speciale functie schrijven die de parameterized query str_replaced. Ik heb uiteindelijk wel een 'soort van' query er uitgekregen, maar dat was niet bepaald netjes. (Maargoed, ik ben dan ook geen expert er in.)

Zoals ik al zei, de leercurve is groot.

[bartvb]

Voor een vergelijkbaar vraagstuk gestaan en uiteindelijk voor Symfony gekozen. Laravel heeft een wat lagere instap, idd erg vriendelijke community, goede documentatie, etc, etc. maar mijn conclusie was dat het meer gericht is op de wat meer overzichtelijke projecten. Symfony heeft zeker een stijlere leercurve, voor een heel groot deel omdat het erg abstract (maar daardoor flexibel) is. Laravel is meer 'opinionated':

http://www.reddit.com/r/P...mfony2_vs_laravel/c96ohf1

Binnen Laravel zijn meer keuzes gemaakt hoe bepaalde problemen moeten worden opgelost. Dat maakt beginnen een heel stuk makkelijker omdat veel al is geregeld, dat zorgt echter wel voor meer complexiteit/workarounds als je af wil/moet wijken van de aannames die Laravel doet.

Mijn conclusie was dat Symfony2 meer aan de abstracte/enterprise kant zit en Laravel meer in de gebruiksvriendelijk/niet mega complex hoek. Als je nog jaren vooruit wil kunnen met je nieuwe codebase en je wil nu investeren in een nieuwe basis zou ik voor Symfony gaan.

[Amanush]

Firesphere schreef op maandag 20 juli 2015 @ 00:16:
[...]

Nee, absoluut niet.

Als je applicatie traag is, moet je profilen en verbeteren. Caching is een manier om de server te ontlasten, niet om snelheid te winnen in je applicatie. Als je caching gaat gebruiken als remedie tegen een trage applicatie, heb je het niet begrepen.

Caching is een prima tool voor het versnellen van een trage applicatie.

[Firesphere]

Nee, nogmaals, caching is een methode om de server te ontlasten, het is geen "tool". En al helemaal niet om snelheid te verbeteren, omdat het totaal niet de applicatie versneld.

[orf]

bartvb schreef op maandag 20 juli 2015 @ 12:47:
. Laravel is meer 'opinionated':

http://www.reddit.com/r/P...mfony2_vs_laravel/c96ohf1

Hoewel het klopt dat Laravel meer opinionated is, is dit stukje al 2 jaar oud en gaat het over Laravel 4. Laravel 5 is een stuk flexibeler en maakt het ten opzichte van versie 4 een stuk makkelijker om individuele componenten te vervangen.

[Amanush]

Firesphere schreef op maandag 20 juli 2015 @ 15:23:
Nee, nogmaals, caching is een methode om de server te ontlasten, het is geen "tool". En al helemaal niet om snelheid te verbeteren, omdat het totaal niet de applicatie versneld.

Ik vind dat caching wel gereedschap is, en ik denk dat caching wel de applicatie (als in laadtijd) versneld.

[mithras]

Je moet goed bedenken dat je het php framework kan lostrekken van de DBAL tools. Laravel komt met Eloquent, maar het staat je vrij om Doctrine te gebruiken. Je kan ook van Laravel wisselen naar een ander framework, maar wel Doctrine blijven gebruiken, bijvoorbeeld. Persoonlijk heb ik een veel grotere voorkeur voor D2 dan Elo, maar daar moet je zelf maar over nadenken.

Hoewel Laravel 5 een stuk flexibeler is, is persoonlijk een framework als Symfony of Zend een heel stuk prettiger in gebruik: het biedt namelijk veel meer vrijheden. Daar moet je ook goed naar kijken: in hoeverre wissel je performance voor gemak? Hoe eenvoudig is het bepaalde onderdelen te swappen voor iets wat beter of sneller werkt?

Het aantal tabellen is leuk, maar het gaat wat betreft database met name om hoeveelheid data (60GB dus) en mate van toegankelijkheid. Wat je hier hebt gedaan in optimalisaties is ook afhankelijk van de tools die je mogelijk kan gebruiken! Met Doctrine ben ik niet (vaak) tegen beperkingen aangelopen trouwens.

Hetzelfde geldt voor 3 miljoen gebruikers: het is relevanter hoeveel pageviews het gaat en wat je laadtijden target is. Met 2 miljoen slapende leden waar de rest eenmaal daags kijkt heb je ineens een heel ander profiel dan 3 miljoen F5'ers

Tot slot: zelf kom ik van ZF1 / ZF2 en ben van de flexibiliteit gaan houden. Daarom doe ik nu veelal in Slim en recentelijk met teams een overstap gemaakt om zaken op te splitsen en onderdelen naar kleinere services te splitsen waar relevant. Het is helemaal leuk om de overgang naar PSR-7 en middleware te volgen (Slim3 bijv), je ziet dat daar echt de toekomst in ligt Het maakt je ook veel flexibeler dan dat je nu zo'n keuze moet maken als TS hier.

[Firesphere]

Amanush schreef op maandag 20 juli 2015 @ 15:42:
[...]

Ik vind dat caching wel gereedschap is, en ik denk dat caching wel de applicatie (als in laadtijd) versneld.

Dan heb je, dus duidelijk geen idee waar caching voor dient.

[ Voor 2% gewijzigd door Firesphere op 20-07-2015 16:20 . Reden: Omdat op slakken zout leggen makkelijk is. ]

[Amanush]

Firesphere schreef op maandag 20 juli 2015 @ 16:07:
[...]

Dan heb je, in mijn opinie, dus duidelijk geen idee waar caching voor dient.

Gelukkig ligt de nadruk op jouw opinie.

[Firesphere]

Amanush schreef op maandag 20 juli 2015 @ 16:11:
[...]

Gelukkig ligt de nadruk op jouw opinie.

Ik zal me maar verder van commentaar onthouden, want je weigert te reageren op wat ik zeg en blijft maar roepen dat het om een mening gaat.

[Amanush]

Firesphere schreef op maandag 20 juli 2015 @ 16:20:
[...]

Ik zal me maar verder van commentaar onthouden, want je weigert te reageren op wat ik zeg en blijft maar roepen dat het om een mening gaat.

Moeilijk he? Meningsverschillen.

[johnkeates]

Amanush schreef op maandag 20 juli 2015 @ 16:21:
[...]

Moeilijk he? Meningsverschillen.

Caching is niet een in-applicatie gereedschap als je dat bedoelt. Het is eerder onderdeel van je infrastructuur en configuratie dan dat het iets is waar je je code 'op bouwt'. Caching is wat je doet na dat je code performance geoptimaliseerd is, om dat het qua schaal een veel groter en directer effect heeft dan zomaar 'even wat cachen'.

Stel dat je in je code besloten hebt om afbeeldingen te genereren, maar dat de gegenereerde afbeeldingen statisch zijn en eigenlijk 1x per maand een keer ververst moeten worden. Dan ga je dat natuurlijk niet in de code lopen cachen, dat helpt niks en je hebt dan nog steeds statische data door je code lopen wat natuurlijk nergens op slaat. Dus dan zorg je dat je ergens aan je frontend een regel knoopt dat alle requests voor zo'n statisch stukje data via iets als varnish loopt, en dat varnish 1x per maand even je code op de applicatieserver aanroept voor een verse versie.

Je kan daar een 'mening' over hebben, maar dit zijn feiten. Feit is dat mensen graag een snelle applicatie hebben. Feit is dat meer requests per server kunnen afhandelen goedkoper is dan elke maand 10 nieuwe servers bijplaatsen. Feit is dat als je je request met een code optimalisatie 50% sneller af kan laten handelen je 50% meer tijd hebt qua resources om andere dingen te doen, zoals meer users bedienen.

Een mening zou zijn: "ik vind eloquent beter dan doctrine". En dat is dan dat.

[DimitryK]

Alvast bedankt voor de verschillende feedback en suggesties.

Toch jammer dat zulk soort vragen vaak uitlopen tot "welles-nietes" discussies.

[Amanush]

Ik heb nergens beweerd caching `in-applicatie gereedschap` is. Een claim als "caching versnelt je applicatie niet" is, naar mijn mening, een rare uitspraak en tevens onwaar.

[ Voor 9% gewijzigd door Amanush op 20-07-2015 16:38 ]

[kwaakvaak_v2]

Amanush schreef op maandag 20 juli 2015 @ 16:37:
Ik heb nergens beweerd caching `in-applicatie gereedschap` is. Een claim als "caching versnelt je applicatie niet" is, naar mijn mening, een rare uitspraak en tevens onwaar.

Het versnelt je applicatie code niet, wel de output van je applicatie. En dat is het subtiele verschil waar deze discussie omdraait. Je zware loops worden niet sneller als je caching toevoegt, maar een gevolg van cache kan zijn dat je loop niet elk request draait, maar één keer per xxxx requests, of als je gecachte output als 'oud' is gemarkeerd. En dat zorgt er weer voor dat je applicatie snel reageert voor de eind gebruiker.

[Firesphere]

orf schreef op maandag 20 juli 2015 @ 15:23:
[...]


Hoewel het klopt dat Laravel meer opinionated is, is dit stukje al 2 jaar oud en gaat het over Laravel 4. Laravel 5 is een stuk flexibeler en maakt het ten opzichte van versie 4 een stuk makkelijker om individuele componenten te vervangen.

Waar mijn eerste ervaring met Laravel in versie 4 was, waardoor ik er dus eigenlijk een flinke hekel aan had gekregen, heeft mijn ervaring met versie 5 die mening wel positief bijgesteld.

[Bartjuh_4]

Vorig jaar zijn we bij ons op het werk begonnen met laravel als php framework. Hierbij hebben we een platform van een grote voetbal club als eerste op ontwikkeld. Persoonlijk vond ik dit een behoorlijke gok maar deze is uiteindelijk goed uitgevallen.

We zijn begonnen met een rest api waar de backoffice en de website aan gekoppeld zijn. De zaken waar we bij L4 tegen aan liepen zijn met L5 opgelost.

mede dankzij efficiënte queries en caching is het platform supersnel.

Doctrine is voor mij nog onbekend gebied maar wil ik binnenkort uitproberen.

Mijn ervaring is dat laravel prima als framework is te gebruiken voor high volume sites en grote hoeveelheden data.

In combinatie met queue managers als beanstalk/redis kan je lange processen op de achtergrond uitvoeren en de gebruiker snel bedienen.

[console]

Wij bouwen al met Laravel sinds 4.x en voldoet prima voor zowel kleine als grotere projecten. Waarbij sinds 5.x echt een stuk op vooruit is gegaan qua features, stabiliteit en natuurlijk LTS. Momenteel werken wij hier intern aan twee grote projecten waarvan één al in productie is genomen. Dit is een whitelabel systeem die veel requests te verduren krijgt (klanten zijn o.a. d-reizen, vakantiexperts, vliegtickets.nl, cheap.nl, hoteldeal.nl) en heeft een gemiddelde response van 170ms en dit alles draait op een EC2 t2.Micro bij AWS.

Het tweede systeem is nog groter dan het eerste. In dit systeem beheer je de content van de whitelabel website's en zorgt ook o.a. voor de afhandeling van de orders (documenten, koppelingen met derden, betalingen enz). Dit alles draait ook op het AWS platform en we gebruiken ook echt bijna alles van wat ze aanbieden (Opswork, EC2, RDS, SQS, SES, Route 51, S3, Cloudfront).

Het is verder een prima framework met een enorme (en nog steeds groeiende) community. Daarbij zie je veel ontwikkelaars overstappen van b.v. Zend, SF, Yii, CakePHP naar dit framework, omdat het uiterst vriendelijk is én b.v. gemakkelijk aan te passen is (b.v. applicatie structuur). En dan is er nog eens een enorme vraag naar Laravel programmeurs zowel hier in Europa als in de VS.

Bartjuh_4 schreef op maandag 20 juli 2015 @ 21:06:
Vorig jaar zijn we bij ons op het werk begonnen met laravel als php framework. Hierbij hebben we een platform van een grote voetbal club als eerste op ontwikkeld. Persoonlijk vond ik dit een behoorlijke gok maar deze is uiteindelijk goed uitgevallen.

We zijn begonnen met een rest api waar de backoffice en de website aan gekoppeld zijn. De zaken waar we bij L4 tegen aan liepen zijn met L5 opgelost.

mede dankzij efficiënte queries en caching is het platform supersnel.

Doctrine is voor mij nog onbekend gebied maar wil ik binnenkort uitproberen.

Mijn ervaring is dat laravel prima als framework is te gebruiken voor high volume sites en grote hoeveelheden data.

In combinatie met queue managers als beanstalk/redis kan je lange processen op de achtergrond uitvoeren en de gebruiker snel bedienen.

Voetbalclub met geel en zwart . Maar mooi om te zien dat jullie de stap hebben gemaakt om van - het ter dood veroordeelde - CodeIgnitor over te stappen naar Laravel ;-).