Toen ik serieuze projecten begon te maken bijna 10 jaar geleden waren er niet al te veel PHP-frameworks in omloop. Toen was CodeIgniter een van de meest bekende, meest doorontwikkelde en meest actieve frameworks die er bestonden (en vergeet ook niet de goede specs voor die tijd). Er waren toen ook verschillende forks in omloop (zoals Kohana) maar die waren minder ‘mature’ en dus niet interessant voor de serieuze projecten waar ik aan werkte. De keuze om CodeIgniter te gaan gebruiken voor al onze maatwerkapplicaties was dus niet moeilijk.
Waarom we overgestapt zijn van CodeIgniter naar Symfony
Door de jaren heen hebben we natuurlijk onze eigen sausje aan het framework gegeven om bijvoorbeeld:
- Meerdere talen te ondersteunen
- Authenticatie en rechten vanuit de core te regelen
- Geavanceerde caching mechanismen te kunnen gebruiken
- Automatisch gegenereerde beheeromgeving op basis van database tabelstructuur te kunnen maken
- Automatisch endpoints te genereren op basis van database tabelstructuur
- Developer widget te gebruiken om eenvoudig configuraties van schermen en rechten in te stellen
- Profiling mechanismen te koppelen om realtime de performance van de applicatie in de gaten te kunnen houden
- en nog veel meer
Op gegeven moment werd CodeIgniter niet meer doorontwikkeld (later weer wel maar een stuk minder actief dan voorheen), waardoor we ons af gingen vragen of het verstandig zou zijn om misschien een ander framework te gaan gebruiken bij El Niño.
De beslissing om over te stappen naar een ander framework was niet eenvoudig omdat natuurlijk a) we heel veel systemen hebben ontwikkeld op basis van CodeIgniter en b) alle extra functionaliteit die we hebben ontwikkeld bovenop het framework eigenlijk opnieuw gemaakt zouden moeten worden (iets wat heel veel tijd zou kosten).
Daar tegenover staat de grootste beperking van CodeIgniter, namelijk dat het eigenlijk niet volledig OOP is opgebouwd, waardoor je heel veel leuke en slimme toepassingen die bijvoorbeeld bij PHP7 zijn geïntroduceerd niet kunt gebruiken (denk bijvoorbeeld aan namespaces, strict types, enz) zonder dat het het framework in de weg zit. Dit is natuurlijk jammer als je state-of-the-art applicaties wilt ontwikkelen.
Na een tijdje hebben we toch besloten om ons framework op CodeIgniter niet meer door te ontwikkelen en ook niet meer te gebruiken bij nieuwe applicaties. Welk framework het dan wel zou moeten worden? We kwamen als snel uit op 3 frameworks: Laravel, Symfony en Zend Framework.
Zend framework
Zend Framework hadden we al ervaring meer door een aantal projecten die we hadden overgenomen van andere partijen. Onze ervaringen met het framework waren niet al te positief. Het geheel was groot, uitgebreid en daardoor ook heel erg lomp. Je moest hemel en aarde bewegen om de performance van de applicatie omhoog te kunnen krikken. Ook de integratie met Doctrine blijkt al snel meer tegen te werken dan mee te werken. Ja, het concept is goed bedacht, alleen de uitvoering vonden wij veel te omslachtig en dus tijdrovend.
Laravel
Laravel is ook een interessant framework met een grote community en heel veel zogenaamde Laracasts om snel te kunnen begrijpen en leren hoe je applicaties zou moeten ontwikkelen en wat de standaarden zijn. Mocht je er zelf niet uitkomen dan kan de grote community jou een handje helpen. Het gebrek aan voorgedefinieerde structuren en richtlijnen zal voor veel programmeurs een bevrijding zijn en ik denk ook dat je wanneer je als de enige programmeur werkt aan een systeem dat gebouwd is op basis van Laravel dit prima werkt. In teamverband zie ik echter wel veel problemen, zoals dat je heel snel een wildgroei aan programmeerstijlen kunt krijgen binnen een project (dat heb je normaal ook wel, is lastig tegen te houden, maar het moet niet te makkelijk worden om zonder structuur een applicatie op te zetten). Dit is niet bevorderlijk voor het onderhoud en helemaal niet goed voor interne verhoudingen tussen programmeurs ;)
Symfony
Onze laatste keuze, maar uiteindelijk ook de voor ons juiste keuze is Symfony. Symfony is vaker ingezet bij serieuze applicaties en heeft een enorme community om zich heen. Documentatie is prima (niet zo uitgebreid als die van Laravel, maar voldoende om mee uit de voeten te kunnen) en de basisperformance van het framework voldoet in eerste instantie prima. In tegenstelling tot Laravel, is er bij Symfony meer een structuur aanwezig waar programmeurs zich aan moeten houden. In principe kan je een Symfonyproject nog steeds op duizend manieren inrichten, maar overal zijn er duidelijke (on)geschreven richtlijnen te vinden over hoe een Symfonyproject ingericht dient te worden. Dit geeft ons team voldoende houvast om ervoor te zorgen dat er zo min mogelijk verschillende programmeerstijlen binnen een project ontstaan.
Voordeel van Symfony en Laravel is dat je eigenlijk packages / libraries van elkaar kunt gebruiken door middel van Composer. Het installeren van de packages is eenvoudig en daardoor kan je heel snel een basissysteem in de lucht krijgen. Zo zit er bijvoorbeeld standaard Doctrine in Symfony. Na een paar dagen frustratie en gevloek hebben we toch besloten om Doctrine niet meer te gebruiken maar Eloquent van Laravel. Een composer require commando verder en we konden aan de slag! Wat een verschil!
Voor nu zullen we de reeds ontwikkelde maatwerkapplicaties nog steeds blijven (door)ontwikkelen in CodeIgniter. Een aantal nieuwe applicaties hebben we al met Symfony ontwikkeld en de eerste ervaringen zijn positief! Er is wel een lichtelijke leercurve, maar dit heb je snel overwonnen dankzij de grote community.
Een intern besluit dat we genomen hebben is ook dat we het frontend gedeelte los willen trekken van het backend gedeelte. Dit doen we door gebruik te maken van Javascript framework(s) zoals ReactJS, en BackboneJS voor de voorkant en Symfony als API backend. Alle communicatie verloopt dus via een API wat ervoor zorgt dat het gehele systeem heel schaalbaar is en ook makkelijk in te zetten is voor verschillende toepassingen (bijvoorbeeld een website en een losse app, danwel native danwel webbased).
Kortom, de keuze om een andere framework te gaan gebruiken was lastig, maar het was een beslissing die vroeg of laat plaats moest vinden en ik ben blij dat we die beslissing hebben genomen om nog mooiere en geavanceerdere systemen te kunnen maken!
