WordPress, Laravel en SaaS – Software as a Service

Wat is Software as a Service?

Hoewel je wellicht niet bekend bent met de term ‘Software as a Service’ durf ik de wedden, dat je na het lezen van deze eerste sectie van dit artikel exact weet wat ik bedoel. Want waarschijnlijk gebruik jij -als ondernemer- diverse SaaS toepassingen.

Om het even kort en bondig te zeggen: ‘Software as a Service’ (afgekort tot SaaS) is het idee, dat je een computertoepassing ergens op het Internet kan gebruiken alsof het jouw eigen toepassing (lokaal of op het Internet) zou zijn.

Een prachtig voorbeeld, omdat we hier allemaal WordPress spreken als universele taal, is… WordPress.

Wanneer je WordPress wilt gebruiken heb je twee mogelijkheden. Je neemt ergens een hosting account en laat WordPress voor je installeren, of je doet het zelf, en gaat vervolgens aan de slag met je WordPress website.

Een andere mogelijkheid is dat je gaat naar de WordPress.com website, daar een account aanmaakt, en daar begint te bloggen.

Beide alternatieven bieden je dezelfde basismogelijkheden. En wanneer je een enthousiaste reiziger bent, die graag een travel blog wil bijhouden, dan is WordPress.com net zo goed voor jou als een WordPress website die je zelf installeert of laat installeren.

Ben je echter een ondernemer, dan zal je al snel merken, dat WordPress.com te beperkend voor je is. Je wilt meer plugins kunnen gebruiken, dan mogelijk binnen deze oplossing.

Software as a Service is exact wat de naam doet vermoeden: Een online product, waarbij de gebruiker niets hoeft te installeren, weinig te configureren om direct aan de slag te gaan.

WordPress MultiSite – Software as a Service ‘out of the box’

Wanneer je het idee hebt, om ‘iets als WordPress.com’ te kopiëren dan hoef je daar niet veel voor te doen. Want WordPress heeft al enkele jaren de ingebouwde mogelijkheid om met een paar kleine ingrepen WordPress om te toveren tot een ‘multisite toepassing’.

Het idee van een multisite toepassing van WordPress is dat met één WordPress installatie iedereen met een beheerders inlog toegang heeft tot een eigen website.

Hoe je WordPress moet installeren om dit mogelijk te maken is gedurende de laatste jaren nogal eens veranderd, dus in plaats van dit allemaal uit te leggen, en daarmee mijzelf op te moeten schepen met de verplichting dit te onderhouden, verwijs ik je liever naar de WordPress pagina, die bij iedere verandering wordt bijgewerkt.

Vanuit mijn gezichtspunt hoef je dus maar drie dingen te doen, om jouw eigen WordPress.com in de lucht te krijgen.

1. Installeer WordPress
2. Volg deze instructies.
3. En bouw een overtuigende website, die mensen motiveert om via jouw app te gaan bloggen.

Gefeliciteerd. Je hebt zojuist je eigen Software as a Service gecreëerd zonder een woord te programmeren.

Geloof je niet meer zo in blogsites? Installeer WooCommerce en je hebt zojuist je eigen e-Commerce SaaS platform gemaakt. Nog even een paar klanten krijgen en je kan naar Ibiza (of Antarctica, wanneer je niet van warmte houdt) verhuizen en vandaar uit cashen. Toch? Of niet?

Nee. Niet helemaal. Je hebt namelijk zo juist een aantal kapitale fouten gemaakt. Zowel op marketing gebied als op technisch gebied.

Sta mij toe dit nader toe te lichten.

Schaalbaarheid

Wat schaalbaarheid is, heb ik een tijdje terug al prima uitgelegd in een artikel over ‘hoe je WooCommerce sneller kunt maken‘ En wat ik hier schrijf is vele malen sterker van toepassing wanneer je WordPress MultiSite als een SaaS platform probeert te gebruiken.

Met een beetje pech, is jouw ‘SaaS oplossing’ zo succesvol, dat de server waarop het draait uit zijn voegen barst.

Veiligheid

Ook de veiligheid van de gegevens is hier een issue. WordPress MultiSite is namelijk niet in de eerste plaats ontworpen om het mensen mogelijk te maken om een eigen ‘SaaS oplossing voor WordPress’ aan te bieden, maar om makkelijk vanuit één gebruikersinterface meerdere websites of webshops te onderhouden.

Alle websites, die binnen één WordPress MultiSite installatie voorkomen, delen namelijk samen dezelfde database. Wanneer een onveilige plugin toegang zou geven tot de database, dan heeft een gebruiker ook toegang tot alle tabellen in die database, niet alleen zijn eigen tabellen.

In het geval van een webshop, zou je het zeker niet leuk vinden, wanneer jouw concurrent zomaar bij jouw klantenbestand kan komen, nietwaar?

Multi-Tenancy

Binnen een Software as a Service oplossing worden de hoofdgebruikers van de software instance vaak ’tenants’ genoemd. Wanneer ik bijvoorbeeld naar een e-commerce SaaS toepassing kijk, dan is de ‘winkeleigenaar’ één tenant. Zijn klanten en zijn medewerkers zijn met data en configuraties gescheiden en geïsoleerd van de andere tenants, ondanks dat ze dezelfde software gebruiken.

Binnen WordPress MultiSite – en dus ook WooCommerce- is dit opgelost door de tabellen andere prefixes, voorvoegsels- te geven.

De gebruikerstabel van tenant nummer 1 is bijvoorbeeld wp_1_users, de gebruikerstabel van tenant nummer 2 wp_2_users etc.

Zoals hierboven bij de bespreking van de veiligheid al is aangegeven, is dit niet de meest optimale oplossing. Want vind je door een onveilige plugin een ‘gaatje in de beveiliging’, heb je direct toegang tot alle gegevens van alle tenants. Er zijn betere manieren om dit op te lossen. Deze bespreken we later in dit artikel.

Performance

Bij Software as a Service oplossingen telt het nadeel wat ik eerder heb besproken in mijn artikel over de vergelijking tussen Laravel en WordPress vele malen zwaarder. De hoeveelheid verkeer die je mag verwachten is namelijk vele malen groter.

Enkele design principes voor Software as a Service

Bij de twee voorbeelden die ik hierboven genoemd heb, wordt het principe van Software as a Service ingebouwd in een bestaand platform (WordPress). WordPress is nimmer ontworpen om in principe een SaaS oplossing te zijn. Het is een feature die later pas is geïmplementeerd.

Wanneer je van meet af aan je toepassing als een SaaS platform wilt laten functioneren, dan moet je eigenlijk ook vanaf het begin dit als een SaaS omgeving opzetten. En om dat mogelijk te maken, moet je aan een aantal belangrijke ontwerpprincipes voldoen.

In de bespreking van WordPress als een SaaS platform hierboven hebben we al aangegeven waar het bij WordPress MultiSite fout gaat. De drie belangrijkste punten waarop het fout gaat, Schaalbaarheid, veiligheid en multi-tenancy, zijn ook precies de drie belangrijkste punten waar je goed stil bij moet staan bij het ontwerp van een SaaS platform. Performance is een afgeleide van (het gebrek aan) schaalbaarheid. Toch zullen we ook bij dit punt apart nader stilstaan.

Schaalbaarheid

De schaalbaarheid is een cruciaal kenmerk voor een Software as a Service toepassing, aangezien het bepaalt hoe goed de applicatie kan groeien en presteren, naarmate het aantal gebruikers en de hoeveelheid data toeneemt. Voor een optimale schaalbaarheid is de enige werkelijk haalbare oplossing gebruik te maken van cloudhosting.

1. Schaalbaarheid

Wanneer we over schaalbaarheid spreken, dan zijn er twee vormen van schaling:

• Horizontale Schaling (Scale Out):
  Horizontale schaling wil zeggen, dat je meer servers of instances toevoegt wanneer het verkeer naar je Software as a Service platform te groot wordt. Je laat het werk dus als het ware door meerdere servers verrichten.
• Verticale Schaling (Scale up):
  Verticale schaling wil zeggen, dat je de capaciteit van een bestaande server of instance vergroot. Dit doe je door meer CPU, geheugen of opslagruimte toe te voegen.

In mijn artikel over WooCommerce in de cloud wordt dit verder in detail uitgelegd.

2. Load Balancing

Ook dit wordt verder in detail uitgelegd in mijn artikel over WooCommerce in de cloud. Load Balancing verdeelt inkomende netwerkverzoeken gelijkmatig over meerdere servers. Dit voorkomt dat een enkele server overbelast raakt en zorgt, dat de applicatie responsief blijft. Load balancing is een randvoorwaarde voor horizontale schaling. Jouw extra servers of instances moeten immers bereikbaar zijn en zonder extra voorzieningen (zoals Load Balancing) zijn de extra toegevoegde servers onbereikbaar.

Hoe werkt Load Balancing ongeveer?
In werkelijkheid is het iets complexer als de manier waarop ik het beschrijf, maar het komt toch aardig in de buurt. Zoals je waarschijnlijk weet, wordt een webhost niet gevonden op een domeinnaam als mijnwebserver.nl, maar op basis van het IP adres, wat er uit ziet als bijvoorbeeld 123.123.123.123. De DNS, een soort ’telefoonboek voor IP adressen’ staat dan aangegeven, dat bij mijnwebserver.nl het IP adres 123.123.123.123 hoort.

Bij Load Balancing plaats je een stuk hardware voor de daadwerkelijke server (of in het geval van een cloud toepassing, is het een stuk software) en geef je die load balancer het IP adres 123.123.123.123.

In een besloten netwerk, sluit je jouw webservers aan op dit load balancer en geef je -in het voorbeeld van drie servers, deze bijvoorbeeld de adressen 192.168.1.1, 192.168.1.2 en 192.168.1.3. (Even terzijde, IP adressen in de range 192.168.0.0 tot en met 192.168.254.254 zijn altijd bedoeld voor intern gebruik in een persoonlijk netwerk. Deze kan je dus veilig gebruiken.)

En volgens door jou in te stellen regels, zal voortaan het verkeer wat naar 123.123.123.123 gaat worden doorgestuurd naar één van de internet IP adressen.

3. Microservice architectuur

Tot nu toe zijn we ervan uitgegaan, dat alle instances binnen onze Software as a Service toepassing eenzelfde rol spelen. Ze hebben allemaal onze SaaS applicatie geïnstalleerd staan. Maar laten we eens kijken naar een praktisch voorbeeld. En omdat we het toch al de hele tijd over WooCommerce hebben, laten we eens kijken naar een e-commerce applicatie.

Je kan een e-commerce applicatie bouwen met alles erop en eraan. En wanneer je een succesvolle Software as a Service e-commerce app zou bouwen, dan krijg je misschien miljoenen hits per uur naar jouw SaaS toepassing. Maar niet ieder onderdeel van die toepassing wordt even druk gebruikt. Wanneer je ervan uitgaat, dat de conversie van een gemiddelde webshop ongeveer 3% is, dan kan je op je vingers natellen, dat de ‘checkout’ van je website heel wat minder bezocht gaat worden dan je productpagina’s. Maar voor wat de rekencapaciteit betreft, is jouw checkout heel wat CPU intensiever.

Die twee functionaliteiten zou je eigenlijk op kunnen splitsen, één functionaliteit is de productcatelogus, de andere functionaliteit de checkout.

Bij een microservices-architectuur wordt de SaaS-applicatie opgedeeld in kleinere, onafhankelijke services. Elk van deze services kan afzonderlijk worden geschaald en geoptimaliseerd, wat flexibiliteit en efficiëntie biedt bij het beheren van groeiende gebruikersaantallen en complexe functionaliteiten.

4. Elasticiteit

De eerste drie genoemde aspecten van schaalbaarheid zoals hierboven benoemd laten nog in het midden of je ervoor kiest om zelf complete servers te kopen of te huren, of dat je gebruik maakt van de cloud. Zodra we over elasticiteit beginnen, dan blijft er maar één hostingmogelijkheid over: De cloud.

Weer terug naar een Software as a Service oplossing voor e-commerce. Jij hebt een populair e-commerce SaaS platform gebouwd en dankzij alle voorgaande tips is het allemaal nog retesnel ook. Jouw klanten zijn supertevreden. Jij beheert je eigen serverpark in een colocatiecentrum en iedere maand kan je er een servertje bijzetten, omdat je klantenbestand maar blijft groeien.

En dan komen Sinterklaas en de Kerstman. Ineens explodeert je verkeer. Omdat iedereen op zoek is naar sinterklaaas- en kerst kadootjes, groeit je verkeer ineens een factor 100. Dat had je niet voorzien. Gelukkig heb je als vaste klant van je hardware leverancier een stapje voor bij hem, en hij levert je met spoed de servers die je nodig hebt. Met veel overwerk en extra inhuurkrachten heb je alles goed draaiend gekregen en ga je met een goed gevoel het nieuwe jaar in.

Maar -je ziet het al aankomen- nadat de laatste vuurpijl de lucht in is geschoten, daalt het verkeer weer. En wanneer je alles op een rijtje zet, merk je dat je ineens een 99% overcapaciteit in je serverpark hebt.

En dat is de reden, dat je eigenlijk met een Software as a Service toepassing altijd in een cloud omgeving zou moeten hosten. Want in een cloudomgeving kan je instances per dag, en vaak zelfs per uur inzetten. De rest van de tijd betaal je er bijna niets voor (alleen de opslag die een instance gebruikt).

Elasticiteit verwijst naar het vermogen van de SaaS-oplossing om automatisch op- en af te schalen in reactie op veranderende belasting. Cloudproviders zoals AWS, Google Cloud en Azure bieden vaak automatische schaalopties die elastisch kunnen reageren op variërende vraag.

Veiligheid

Ook de veiligheid van je SaaS toepassing verdient de nodige aandacht. En mocht je na mijn verhaaltje over de schaalbaarheid nog niet overtuigd zijn, dat je eigenlijk alleen met een SaaS applicatie moet beginnen binnen een cloud omgeving, dan is een goede tweede overweging, dat je op het gebied van veiligheid jouw cloudprovider al een enorme hoeveelheid zorgen uit handen neemt op het niveau van het netwerk en de hardware. Voor de veiligheid van de applicatie zelf ben en blijf jij zelf verantwoordelijk.

Laten we eens kijken naar de onderdelen die dus wel jouw verantwoordelijkheid zijn.

1. Authenticatie en authorisatie

Natuurlijk, niet iedereen mag alles. En om ervoor te zorgen, dat iedereen alleen maar kan doen, wat de persoon ook mag doen, zijn er drie belangrijke punten, waaraan jouw SaaS zou moeten voldoen.

• Sterke Wachtwoordvereisten: Zorg ervoor dat gebruikers sterke wachtwoorden gebruiken die moeilijk te raden zijn.
• Multi-Factor Authenticatie (MFA): Voeg een extra beveiligingslaag toe door gebruikers te verplichten een tweede vorm van identificatie te gebruiken, zoals een SMS-code of een authenticator-app.
  Hierbij een kleine voetnoot. Afhankelijk van het type platform, wordt MFA nogal eens hinderlijk ervaren door consumenten. Wanneer je een SaaS platform aanbiedt, wat zich voornamelijk richt op consumenten (denk aan e-commerce bijvoorbeeld), dan kan het gebuikersvriendelijker zijn om MFA alleen verplicht te maken voor gebruikers met een beheerdersrol.
• Role-Based Access Control (RBAC): Beperk de toegang tot gegevens en functies binnen de SaaS-omgeving op basis van de rol van de gebruiker. Dit zorgt ervoor dat gebruikers alleen toegang hebben tot de gegevens en functies die zij nodig hebben voor hun werk. Een niveau gedetailleerder is toegangscontrole op basis van ‘roles and permissions’. Hierbij is het mogelijk om aan een enkele gebruiker een extra toegangsmogelijkheid te geven, op basis van specifieke rechten.

2. Een veilig ontwikkelingsproces

• Secure Coding Practices: Volg veilige coderingspraktijken om veelvoorkomende beveiligingsfouten zoals SQL-injecties, XSS-aanvallen en CSRF-aanvallen te voorkomen.
  Het gebruik van een ontwikkelframework met abstractielagen en middleware, waarbij directe toegang tot een database wordt voorkomen (SQL injecties) of XXS en CSRF aanvallen worden bemoeilijkt (door middleware) is hier te prefereren.
• Code Reviews en Penetratietesten: Voer regelmatige code reviews en penetratietesten uit om beveiligingslekken in de software te identificeren en op te lossen.

3. Backup en herstel procedures

• Regelmatige Backups: Voer regelmatig back-ups uit van alle belangrijke gegevens om verlies van gegevens te voorkomen in geval van een incident.
• Disaster Recovery Plan: Ontwikkel en test een uitgebreid rampenherstelplan om ervoor te zorgen dat de SaaS-omgeving snel kan herstellen na een storing of beveiligingsincident.

Multi-tenancy

Multi-tenancy is een belangrijke architectuurconcept in SaaS omgevingen. Het verwijst naar een enkel exemplaar van een softwaretoepassing die meerdere, fysiek gescheiden gebruikers of “tenants” tegelijk bedient. In sommige toepassingen, kan de tenant ook weer zijn eigen gebruikers aanmaken.

Voor dit laatste is -opnieuw- een e-Commerce SaaS platform een goed voorbeeld. De eigenaar van een webshop zal mogelijk meerdere winkelmedewerkers toe willen voegen met ieder eigen bevoegdheden binnen de shop. Ook klanten zullen moeten worden toegevoegd. Al deze gebruikers behoren specifiek bij die éne tenant, en mogen geen rechten hebben binnen de instantie van andere tenants.

Architectuur

In principe zijn er drie mogelijkheden om multi-tenancy te implementeren. De volgorde waarin ik deze mogelijkheden bespreek zijn van minst wenselijk tot meest wenselijk.

1. Eén database, tenant wordt op tabelniveau geïdentificeerd
   Hier wordt in iedere relevante tabel een ’tenant_id’ (naam van het veld kan anders zijn) toegevoegd aan een tabel in de app. Dit maakt het nodig om op ieder niveau van the app er rekening mee te houden in alle database queries de resultaten te filteren op deze ID en in de praktijk is dit een onwerkbare situatie, tenzij je gebruik maakt van database schemas (indien de database het ondersteunt) of een ORM waarbij de filtering op ORM niveau wordt uitgevoerd. Een ‘ORM’ is een ‘Object Relations Mapping’, een laag die tussen applicatie en de database kan liggen.
2. Eén database, iedere tenant heeft zijn eigen set tabellen
   Dat is de situatie die bijvoorbeeld bij WordPress MultiSite is geïmplementeerd. Iedere tenant heeft een eigen set tabellen met een voor de tenant unieke prefix. Deze oplossing is veiliger dan de voorgaande, maar omdat alle tabellen in dezelfde database voorkomen,
3. Iedere tenant een eigen database
   Indien ondersteund door het software platform, is dit de ideale situatie. In de code zelf hoeft er alleen rekening mee worden gehouden, dat de juiste tenant inlogt op de juiste database. Naast een database per tenant is er een ‘globale database’, die gebruikt wordt voor de meta-informatie (zoals wie de tenants zijn, informatie over hun abonnement) en tabellen die door alle tenants gedeeld moeten / mogen worden. Hierbij kan je denken aan bijvoorbeeld tabellen met landen, provincies en steden. Deze informatie hoeft niet door de tenant onderhouden te worden, en dit soort tabellen zijn over het algemeen zeer groot. Door deze in de ‘globale database’ te plaatsen voorkom je dat deze tabellen iedere keer naar een nieuwe tenant gekopieerd hoeven te worden.

De Laravel methode voor Software as a Service

In de laatste sectie van dit artikel leg ik je uit, hoe en waarom Laravel goed geschikt is om voor te kiezen, wanneer je zou besluiten een SaaS toepassing te (laten) bouwen. Maar om uit te leggen, waarom Laravel hier zo goed geschikt voor is, moet ik eerst iets meer over Laravel vertellen. Ik heb natuurlijk al het één en ander gezegd in mijn eerdere artikel over Laravel en WordPress, maar daar ben ik toch wat aan de oppervlakte gebleven. In dit artikel wil ik toch ook iets meer op de techniek van Laravel zelf ingaan.

MVC model

Laravel is gebouwd rond een in de software ontwikkeling algemeent toegepast model, het ‘Model – View – Controller’ model. Hierbij worden de gegevens, de acties op de gegevens en de presentatie van gegevens van elkaar gescheiden en ondergebracht in aparte ‘applicatie lagen’. De communicatie tussen de lagen onderling gaat door middel van een ‘Data Transfer Object’, een gegevensstructuur die in alle lagen van de applicatie wordt begrepen.

In onderstaande tekening zie je dit heel simpel uitgelegd.

De basis van het hele proces is het model. De model-laag is de laag van de gegevens. Wat die gegevens zijn en waar deze gegevens vandaan komen is voor de totale applicatie niet interessant. Het Model is verantwoordelijk voor de complete afhandeling hiervan. Dus het maakt niet uit, of we het hier hebben over een database, de resultaten van een API call of informatie die wordt uitgelezen uit een CSV of XML bestand.

Het model is ook verantwoordelijk voor de bedrijfslogica en de toegangsregels met betrekking tot die data, de onderliggende relaties en validatie van de gegevens.

Gegevens worden aan de gebruiker gepresenteerd door de view. In een webapp is de webpagina een voorbeeld van zo’n view. Maar alleen maar een voorbeeld. Een email bericht of een SMS vanuit de applicatie is ook gebaseerd op een view.

Wanneer de gebruiker gegevens aan wil passen of op wil vragen, gebruikt hij de controller. De controller zorgt ervoor, dat de gegevens worden bijgewerkt en de view wordt geupdate met de laatste aanpassing.

Het voordeel van dit MVC model is dat iedere laag in de applicatie zijn eigen geïsoleerde taak heeft. In een ‘ouderwets’ model, moesten acties en controles op verschillende locaties in de applicatie worden geïmplementeerd om de integriteit van de database te behouden.

Waarom is WordPress niet volgens het MVC model gebouwd?

Wanneer je dit leest, dan denk je misschien… als dit zo is, waarom is WordPress dan niet volgens dit MVC model gebouwd. Het antwoord is simpel. Hoewel in 2003, toen WordPress 0.7 de wereld zag, het MVC model al bestond, was het in de onderliggende programmeertaal PHP nog onmogelijk te implementeren. Pas met de introductie van een nieuwe manier van object georiënteerd programmeren in PHP 5 in juli 2004 werd programmeren volgens het MVC model haalbaar. Het zou nog tot 2009 duren voor, toen in PHP 5.3 ‘namespaces’ werden geïmplementeerd, voor het mogelijk zou zijn iets te bouwen wat ook maar een beetje lijkt op wat we nu met Laravel hebben. Het ‘niet volgen’ van de MVC richtlijnen heeft niets te maken met onkunde of gemakzucht van de WordPress ontwikkelaars, maar de tijd was gewoon niet rijp voor. En WordPress massaal converteren naar MVC is ook geen optie, omdat daarmee iedere bestaande plugin helemaal herschreven zou moeten worden.

Object Relational Mapping

Een belangrijk onderdeel van een MVC model is de ‘Object Relational Mapping’ (ORM). De ORM van Laravel heet Eloquent. Een ORM zorgt voor de mapping tussen het Model en de onderliggende database.

Het ORM maakt het makkelijk voor het model om de juiste gerelateerde gegevens samen te brengen.

Stel je voor, je hebt gegevens die afkomstig zijn uit een database, en daaraan gerelateerde gegevens die afkomstig zijn uit een REST API. In een situatie zonder ORM moet de programmeur aparte code schrijven om de verschillende gegevens aan elkaar te relateren. Gebaseerd op een gedefinieerde relatie, doet een ORM dit ‘vanzelf’ (je moet natuurlijk wel eenmalig die relaties definiëren).

Veiligheid van data

Veiligheid heb je op verschillende niveaus, maar nu we gekeken hebben naar hoe Laravel omgaat met data, is het goed om even stil te staan bij de veiligheid van die data. Verderop ga ik wat dieper in op andere aspecten van veiligheid, maar de veiligheid van data is een verhaal apart.

Er zijn drie manieren waarop data beveiligd dient te worden:

1. Bescherming tegen gebruikersfouten
   Waar gewerkt wordt, maakt men fouten. En veel fouten kunnen worden voorkomen, door de juiste controles op de invoer te plaatsen. Omdat in een MVC model alle controles gecentraliseerd zijn in het model, bestaat er geen of weinig kans dat -uitgaande van de integriteit van de programmeurs- op twee verschillende plaatsen verschillende invoercontroles zijn.
2. Bescherming tegen fouten van programmeurs
   Omdat de toegang tot de gegevens via het model verloopt, en het ORM de relaties al ‘weet’, kunnen er geen fouten gemaakt worden door gegevens verkeerd weg te schrijven, of verkeerde relaties tussen objecten te gebruiken.
3. Bescherming tegen fraude en hackers
   Ook de toegang tot de data wordt direct binnen het Model geregeld. Omdat binnen de hele app -als het goed is- geen directe SQL gebruikt wordt, is SQL injection niet mogelijk. Het is dus sterk afgeraden om directe SQL statements te gebruiken, maar de krachtige implementatie van Eloquent maakt het gebruik van directe SQL statements ook helemaal onnodig.

Laravel heeft verschillende ‘performance boosters’

Laravel is om een aantal redenen een heel populair platform om SaaS oplossingen te realiseren. Eén belangrijke reden is dat Laravel uitstekend schaalbaar is. Laravel voldoet aan alle eerdergenoemd mogelijkheden van ‘schaalbaarheid’. Dat ga ik niet nog een keer herhalen.

Een tweede reden is dat Laravel een uitgebreid caching systeem heeft. En dat beperkt zich niet tot het cachen van pagina’s, maar tot het cachen van vrijwel alle soorten informatie. Wanneer -bijvoorbeeld- gegevens het resultaat zijn van een complexe berekening, of een complexe query, en de gegevens op zich niet vaak veranderen, is het mogelijk om deze gegevens in de cache op te slaan.
Bovendien is het met betrekking tot de caching mogelijk om

Een derde reden is dat Laravel ingebouwde mogelijkheden voor Queues en asynchrone gegevensverwerking. Asynchrone gegevensverwerking gebeurt in de applicatie zelf. Je kan in een Laravel app binnen de code een functie opstarten (bijvoorbeeld gegevens binnenhalen via een trage interface) en aangeven, dat zodra het afgelopen is, een bepaalde functie uitgevoerd moet worden, maar ondertussen het programma door kan gaan met de rest van de taken. In het geval van een queue wordt een taak echt uitbesteed aan een compleet apart proces. Dit proces heeft daarna -behalve dan in de logging- geen verdere terugkoppeling naar het aanroepende programma. Een goed voorbeeld van een queue is het versturen van een mailing. Om één email te versturen, kan een app in communicatie met de mailserver enkele seconden nodig hebben. Wanneer je er 10.000 zou willen versturen, ben je enkele uren naar je scherm aan het staren. Door dit uit te besteden in een queue, kan je direct doorgaan met je werk.

Snelle applicatieontwikkeling

Het ontwikkelen van Laravel applicaties gaat snel. Ten eerste, omdat Laravel veel functies bevat, die je dus niet zelf meer hoeft te ontwikkelen. Denk bijvoorbeeld aan het MVC model en de ORM implementatie. Normaal is een ontwikkelaar van een midden grote app enkele weken bezig met de invoer, opvraag en aanpassingen van data. In Laravel enkele uren.

Dit wordt ook nog enorm versneld door de ‘scaffolding’ mogelijkheden van Laravel. Omdat Laravel gebruik maakt van bepaalde programmeer patronen is het makkelijk om de ‘steigers’ (scaffolds) voor de code alvast op te zetten.

Daartoe heeft Laravel een handige commandline tool. Artisan. Door deze tool met bepaalde parameters aan te roepen, kan ik honderden regels code genereren, die ik vervolgens alleen maar aan hoef te vullen.

Om eens een aardig voorbeeld te geven :

php artisan make:model BlogPost --mfsc

Met bovenstaand commando maak ik de code aan voor een aantal ‘classes’ die ik verder alleen maar hoef in te vullen.

In totaal worden 5 bestanden aangemaakt, met een inhoud waaraan ik alleen de namen van de tabelkolommen en de onderlinge relaties aan toe hoef te voegen om al een werkende situatie te hebben.

Op deze manier kan ik de complete database, met alle bijbehorende controllers, testdata en modellen maken. In de praktijk kost mij dit ongeveer -afhankelijk van de grootte van een tabel en de complexiteit van de validatie regels- tien tot dertig minuten per tabel. In een ‘klassieke’ situatie had mij dit enkele dagen gekost.

Maar nu komt het echt wonderbaarlijk mooie. Wanneer ik gebruik maak van het filament package voor Laravel, dan kan ik vanuit deze database definitie direct de formulieren voor het bijhouden van deze gegevens genereren.

php artisan make:filament-resource Product

Deze code kan ik dan eventueel aanpassen voor een iets meer geoptimaliseerde weergave en in een uurtje tijd kan ik een pagina voor het onderhouden van een product in een webshop krijgen die er bijvoorbeeld uitziet als hieronder. (Screenprint is gebaseerd op het Filament Demo project)

Alle benodigde code voor lijstoverzichten, het zoeken in de lijst en het beheren van de individuele gegevens wordt direct vanuit de datadefinitie in het model en het ORM gegenereerd.

Op deze manier zijn er letterlijk tientallen commando’s die het voorbereiden van standaardcode faciliteren, waardoor snelle applicatieontwikkeling mogelijk is.

Dit zorgt ook weer voor een eenduidige stijl van coderen, waardoor de code later ook makkelijker door andere programmeurs te onderhouden is.

Samenvatting

Met WordPress is het relatief eenvoudig om via de WordPress MultiSite functie een SaaS platform te beginnen. Omdat WordPress echter nooit ontwikkeld is als een SaaS platform loop je al snel tegen de grenzen van het systeem aan.

Laravel, wat ongeveer 10 jaar jonger is dan WordPress is ontwikkeld vanuit een andere optiek. Door de modulaire opzet, de MVC architectuur en een andere wijze van programmeren, waardoor er per aanroep van een pagina alleen dat deel van de informatie wordt geladen die nodig is, is Laravel beter geschikt voor applicaties die veel verkeer genereren, iets wat bij een SaaS toepassing zeker het geval is.

Het nadeel van Laravel is, dat het geheel code-based is. Zonder programmeren is er geen Laravel app mogelijk.

Binnenkort

Binnenkort verschijnt er op deze site een artikel, waarin we bekijken hoe Laravel en WordPress samen kunnen werken, waardoor je van beide platforms optimaal gebruik maakt.