Symfony Framework, de inzichten van een senior developer.

Tijdens het bouwen van een website of app wordt het programmeerwerk nog steeds verdeeld in de voor- en achterkant. De voorkant is wat je in de browser of op je telefoon te zien krijgt en de achterkant houdt zich voornamelijk bezig met data; het opvangen en verwerken van data vanuit bijvoorbeeld de voorkant dan wel de voorkant voorzien van data. Bij Oberon gebruiken we al sinds lange tijd onder andere de programmeertaal PHP om de code voor de achterkant te schrijven.

Best Practices

In de loop van de jaren merk je dat je vaak dezelfde code aan het schrijven bent om dezelfde problemen op te lossen. En met probleem bedoel ik dan niet een tegenslag, maar meer overeenkomstig met een wiskundesom. Je wilt iets bereiken en hoe los je dat op?

Een inlogformulier bijvoorbeeld en het bijbehorende inlogproces. Of: de manier waarop je de data in een database opslaat, hoe je een verzoek van de voorkant afhandelt, etc. Deze onderdelen verschillen niet heel veel van elkaar tussen verschillende projecten. Het is dus handig om dit soort code te kunnen hergebruiken.

Daar kun je - iets wat wij en vele andere bedrijven ook deden - zelf een mooie bibliotheek voor opbouwen. Zo kun je makkelijk de code die je al eens hebt geschreven voor verschillende projecten inzetten. Maar de tijd staat niet stil. Programmeertalen veranderen, de op te lossen problemen veranderen en ook de ideeën over wat de beste manier is om ze op te lossen veranderen door de jaren heen. Daar kun je je eigen codebibliotheek op blijven aanpassen, maar heel efficiënt is dat niet. Zeker niet als je bedenkt dat ditzelfde proces bij heel veel bedrijven gebeurt. En naarmate de code complexer wordt - en door de steeds veranderende technische eisen gebeurt dat ook - wordt het steeds lastiger om 'de beste manier om iets te doen' bij te houden.

Dit is waarom er zo’n 15 jaar geleden steeds meer projecten werden opgezet door derden met als doel een raamwerk op te zetten waar alle developers hun code op kunnen baseren. Deze ‘frameworks’ bevatten dan al de best practices voor de problemen die je bij elk project weer tegenkomt en als individuele ontwikkelaar kun je je dan focussen op die code die elk project uniek maakt. Als ontwikkelaar werk je meestal niet alleen aan een project. Je deelt je code met andere ontwikkelaars en ook in de toekomst, wanneer het project in een onderhoudsfase zit, werken er weer andere mensen aan. Een framework biedt dan de structuur waardoor je weet waar je de code kunt vinden. Je kunt tegen je collega’s zeggen dat je een bepaald onderdeel hebt gebruikt en die zal begrijpen waar je het over hebt. Een framework helpt dus bij de samenwerking en de communicatie over de code en daardoor ook bij de onderhoudbaarheid ervan.

Symfony

15 jaar is een lange tijd en in die tijd zijn er verschillende frameworks ontwikkeld. Ieder met een eigen filosofie en een eigen aanhang van fans die dat het beste framework vinden, maar ook met redelijk wat overlap in functionaliteit. Namen als Zend, Codeigniter, Kohana of CakePHP vormde in de eerste jaren een paar van de eerste grote communities. Het duurde nog een aantal jaren voordat deze projecten volwassen waren en in die tijd leunden wij bij Oberon nog op ons eigen Oberon framework. Maar rond 2012 gingen ook wij een keuze maken voor een van de bekende externe frameworks. Na een rondvraag bij de developers over hun persoonlijke favoriet, kwam Kohana als duidelijke winnaar uit de bus. En dus kozen we als Oberon voor... Symfony. Wacht, wat gebeurt daar? In dat jaar was Symfony nog een van de frameworks waarvan versie 1 aardig was, maar niet veel beter dan de bij ons bekendere frameworks.

Echter, rond de tijd dat wij een keuze gingen maken kwam ook Symfony versie 2 uit. En die had wel een aantal grote veranderingen die interessant waren. Zo was Symfony opgebouwd uit verschillende componenten. De meeste frameworks installeerde je als één groot pakket en dat was het dan. Maar bij Symfony had je de keuze om of het hele framework te gebruiken, of alleen enkele onderdelen ervan. Alleen het component om webverzoeken af te handelen, of alleen het component om sjablonen te maken voor webpagina’s. Sterker nog, je kon gewoon nog je eigen framework gebruiken, maar bijvoorbeeld wel los het component dat het verwerken van formulieren afhandelt toevoegen. En deze opzet heeft Symfony in de jaren erna steeds verder verfijnd.

Daarnaast was de opzet van Symfony gebaseerd op bestaande frameworks in andere programmeertalen, die vaak al een stuk volwassener waren. Tenslotte was het internet en daarmee ook PHP nog allemaal redelijk jong en nieuw. Maar andere programmeertalen bestonden al veel langer. Dit zorgde voor een duidelijke opzet van de structuur en daardoor was Symfony fijner om mee te werken. Het was ook een heel compleet framework, en omdat het zo nieuw was werden ook de ‘best practices’ gevolgd van dat moment.

Doctrine

Als laatste maakte Symfony zelf ook weer gebruik van een aantal al bestaande projecten in de PHP wereld. Wederom een goede manier om het wiel niet opnieuw uit te vinden. Een van die projecten is doctrine. Hier wordt het enigszins complex, maar wat Doctrine doet is een laag vormen tussen de code en de database. Van oudsher werk je bij relationele databases met SQL. Dat is een taal waarmee je query's kunt uitvoeren op de database om de data te ontsluiten. Als developer moet je die taal dus ook beheersen. En om het lastig te maken heeft die taal ook nog eens verschillende dialecten. Er bestaan meerdere bedrijven die databasesoftware maken en hoewel ze allemaal wel SQL gebruiken zit er toch genoeg verschil tussen.

Daarnaast is dit een van de punten waarbij de afgelopen jaren nogal eens wat beveiligingsproblemen zijn geweest. Hoe vaak hoor je niet verhalen over databases die op straat liggen? Een van de redenen is dat de code die met de database praat niet goed is opgezet en beveiligingsrisico's met zich meebrengt. Je bent als programmeur zelf verantwoordelijk om dit goed te controleren voor iedere SQL query die je uitvoert. En zeker in het geval van PHP (ook omdat dit een van de populairste talen op het web is) lieten de programmeurs dat nog wel eens na.

Voor al deze punten biedt Doctrine een oplossing. Zoals gezegd zit Doctrine tussen de database en de code. Je voert niet meer rechtstreeks een query uit op de database, maar zegt tegen Doctrine ‘Geef mij alle producten in de database en maak er ook nog even een model van dat ik in mijn code direct kan gebruiken’. Dit laatste noemen we een ORM. Informatie uit de database wordt omgezet naar een object dat leeft in de taal van de code, in het geval van Symfony dus PHP. Daarnaast zorgt Doctrine ervoor dat alles wat jij aan de database vraagt, of er naartoe stuurt om opgeslagen te worden, gecontroleerd wordt. Je hoeft dus niet meer per se SQL in alle dialecten te beheersen, je hoeft niet meer voor elk verzoek alle data te controleren en je kunt gelijk aan de slag met de data in je code zonder deze zelf te hoeven omzetten.

Nu is het niet alleen maar rozengeur en maneschijn. Deze laag, omdat het je als ontwikkelaar afschermt, is niet altijd het meest efficiënt. En omdat het database-agnostisch is, kan het ook niet altijd gebruik maken van juist die specifieke functies die de ene database onderscheidt van de andere. In ieder geval niet zonder het agnostische gedeelte op te geven. Maar alsnog vormt dit een belangrijk gereedschap in de gereedschapskist die je als ontwikkelaar kunt gebruiken.

En dat geldt eigenlijk voor het hele Symfony framework. Zeker omdat het is opgebouwd uit losse onderdelen, kun je die allemaal zien als stukken gereedschap om een specifiek probleem op te lossen. Een probleem dat meerdere mensen hebben gehad, over hebben nagedacht en de juiste oplossing hebben gevonden.

Symfony nu en de concurrent Laravel

Op het moment van schrijven is het 2020, Symfony is inmiddels bij versie 5 en er zit een bedrijf achter dat er fulltime mee bezig is. Er zijn nog een aantal andere grote frameworks bij gekomen en een aantal is ook weer verdwenen. Een van de bekendste frameworks die de afgelopen jaren enorm is gegroeid is Laravel. Als je deze whitepaper leest is dat wellicht omdat je ook die naam voorbij hebt horen komen. Laravel heeft tegenwoordig een stuk meer gebruikers dan Symfony, globaal gezien. Toch blijven we bij Oberon nog altijd trouw aan Symfony. Dat heeft een aantal redenen. Laravel is inderdaad groter, maar vooral in de Verenigde Staten. In Europa - Symfony is een Frans product - is het aantal gebruikers van Symfony al een stuk dichter bij dat van Laravel.

Een van de redenen dat Laravel meer gebruikers heeft is omdat het in beginsel makkelijker is om te leren. Dus voor nieuwe PHP programmeurs is het een aantrekkelijke keuze. Symfony daarentegen heeft van oudsher de naam vrij complex te zijn een steile leercurve te kennen. Daar zijn in de afgelopen versies al een aantal verbeteringen in geweest, maar van zo’n naam kom je niet makkelijk af. En voor een deel is het ook gewoon waar. Maar dat is ook een van de dingen die Symfony in onze ogen wat fijner maakt. Juist die ietwat complexere opzet zorgt ervoor dat het ook makkelijker is om wat complexere projecten op te zetten. En dat is precies de markt waar wij ons bij Oberon op begeven; Platformen met een complexere opzet. En dit is waar Laravel het soms laat afweten. Laravel kent een opzet waar veel al voor je is geconfigureerd. Maar zodra je van die standaardconfiguratie wilt afwijken wordt het lastiger.

Daarnaast is het niet onbelangrijk om op te merken dat Laravel uitgebreid gebruik maakt van de componenten die Symfony biedt. Het is ontwikkeld bovenop die componenten. En niet alleen Laravel, maar ook bijvoorbeeld de CMS-en Drupal en Joomla en de e-commercepakketten Magento, Sylius en Shopware maken allemaal gebruik van de componenten die Symfony biedt. Andersom kun je in je eigen Symfony project ook gebruik maken van ontwikkelingen die voor Laravel worden gedaan. Ook voor de ontwikkelaars is het omschakelen tussen de verschillende frameworks niet heel lastig. Als iemand bij Oberon solliciteert en vooral met Laravel heeft gewerkt, dan zijn wij er van overtuigd dat die persoon zonder problemen kan instromen. Ook door de uitgebreide documentatie die er beschikbaar is.

Bij Oberon

Bij Oberon gebruiken we de meest recente versie van Symfony voor een nieuw project. Het framework kent een vaste release-cyclus wat het heel voorspelbaar maakt. Op dit moment is versie 5.1 de nieuwste versie. Versie 5.4 wordt daarbij de eerstvolgende LTS versie. Dat wil zeggen dat deze versie door de makers van Symfony extra lang wordt ondersteund. Wij werken gedurende het project altijd toe naar de eerstvolgende LTS versie. Daar blijft het project dan op zitten, tot er in overleg met de klant wordt besloten dat het project geupgrade moet worden naar de nieuwste versie. Bijvoorbeeld omdat zelfs voor de LTS versie de support aan het verstrijken is.

Dus zoals het er nu uitziet blijft Symfony voorlopig het PHP Framework waar we bij Oberon de voorkeur aan geven als basis voor onze projecten. Al houden we ook altijd een oog op de ontwikkelingen die er plaatsvinden en zijn wij nergens met handen en voeten aan gebonden. We staan altijd open voor andere frameworks en zelfs andere programmeertalen.