Headless als lesmateriaal

*Uitgelichte afbeelding van: https://nystudio107.com/blog/headless-preview-in-craft-cms*

Headless

Headless is een woord wat we in webdevelopment vaak horen langskomen. Het belooft goede performance en een dynamische manier van content tonen. Allemaal leuk en aardig, maar is dit ook interessant om te introduceren op MBO scholen, bij een opleiding zoals Software Developer? Met oog op de markt en het kwalificatiedossier heb ik (voor mijn opleiding, maar ook uit eigen interesse) lesmateriaal in projectmatige lesvorm ontwikkeld om vrij te gebruiken.

Maar wat is dan precies Headless?

Headless betekent hoofdloos, ofwel zonder hoofd. Wat wij hiermee bedoelen in een webapplicatie, is dat de zogenaamde front- en backend los van elkaar staan. In traditionele websites werd er data opgeslagen via een backend in de database. Deze data werd vervolgens bijvoorbeeld via PHP getoond op de front-end. De backend en frontend zitten dus in elkaar verweven en de frontend is bijna het hoofd van de applicatie in deze. Aan de hand van deze afbeelding van J. Koenig’s blogpost over Headless webapplicaties zal ik uitleggen wat Headless precies is. ![cms.png](https://mwolfsen.nl/storage/app/uploads/public/5fd/b4b/f8b/5fdb4bf8b644e180057151.png) *Bron: https://pantheon.io/blog/headless-websites-whats-big-deal-decoupled-architecture* Links staat een heel simpele, statische, website. De HTML die je invult wordt getoond in de browser. Dit is het meest simpele voorbeeld van een website. Het volgende voorbeeld is een CMS, een Content Management System. Hierbij heb je te maken met data (bijvoorbeeld blogposts of producten) wat is opgeslagen in een database. De data wat moet worden getoond in de browser wordt uit de database gehaald en direct via PHP getoond op de frontend. Dit is hoe voor heel lang websites werden getoond. De nieuwe techniek is Headless. Dit houdt in dat de backend functionaliteit wordt losgetrokken van de frontend en hierdoor “hoofdloos” wordt. In een database hebben we weer blogposts of producten. Deze worden met PHP weer uit de database gehaald, maar nu niet getoond op de frontend maar beschikbaar gesteld via een API. Dit zorgt ervoor dat de data via een URL beschikbaar is (eventueel met de nodige beveiliging). Vervolgens kan deze data, los van de backend, worden opgehaald met een frontend (JavaScript) framework en worden getoond op de frontend. Omdat JavaScript Client-sided (en niet Server-sided zoals PHP) is, wordt de data dynamisch ingeladen in plaats van dat de hele website in 1x wordt ingeladen. Het voordeel is een enorme verbetering in snelheid. In het kort, database gegevens worden via een API getoond in (beveiligde) URL’s en vervolgens worden deze gegevens getoond op de frontend via een JavaScript framework (in dit geval Vue). Het voordeel is dan, dat de data zowel aan webapplicaties kan worden gegeven, maar vervolgens ook kan worden gebruikt in mobiele of andere applicaties.

Een REST API

In dit geval wordt er heel simpel gebruik gemaakt van een eigen gebouwde API. Eerst wordt er een PHP file gemaakt die kan worden bereikt via een url (bijvoorbeeld api/read.php kan worden gelezen via https://www.website.com/api/read.php). In deze PHP file worden vervolgens producten uit de database opgehaald en teruggegeven in JSON formaat. JSON is een bepaald formaat om veel data in een soort array structuur om te zetten. Hier een voorbeeld van JSON code: ``` { name: "John", age: 31, city: "New York" } ``` Dus, wanneer je in dit geval naar de pagina https://www.website.com/api/read.php zou gaan, krijg je een lijst met alle producten terug, in het JSON formaat zoals hierboven staat. Ook kan er data worden gestuurd, bijvoorbeeld naar https://www.website.com/api/create.php, die een product aanmaakt. Het verschil is dan dat er een POST request moet worden gedaan (je POST iets naar de website) met een body. De body is data dat je wil meesturen, wat overigens ook in JSON formaat is. Je kunt dan zoiets terugsturen: ``` { id: "1", name: "Seiko Horloge", categories: "Horloges, Herenhorloges", description: "Mooi horloge!", price: 123.49 } ```

Het Vue.js Project

Nu de data beschikbaar is via de API, kunnen we de frontend bouwen en deze data ophalen en tonen. Voor deze frontend heb ik een Vue project gestart. Deze pagina laat dit mooi zien hoe een Vue project kan worden opgezet. Ik ga hier niet zozeer uitleggen hoe Vue helemaal werkt, maar wel wat er wordt verwacht. Nadat het Vue project is opgezet kan er doormiddel van Components verschillende HTML componenten worden toegevoegd. Deze componenten werken vrijwel hetzelfde als HTML, met een paar kleine verschillen. In de HTML kunnen er bijvoorbeeld heel makkelijk Vue variabelen worden gebruikt, maar ook for loops met elementen (dus een x aantal elementen maken terwijl je maar 1 hoeft te bouwen. x is dan bijvoorbeeld een aantal producten die je wilt tonen). Daarnaast kun je per component werken met JavaScript, waar wij in ons geval de data van de API ophalen met een GET of FETCH request (GET en FETCH betekenen dus krijgen, ophalen). Om alle producten te tonen op de frontend, halen we de productdata op, slaan we dit op in een variabele en tonen we het via die variabele in de frontend met een loop (omdat er sprake is van meerdere producten). Het component hiervoor in Vue ziet er als volgt uit: ``` ``` In dit voorbeeld is te zien hoe ik in het HTML gedeelte de data gebruik die ik onderin in het component ophaal van de API url.

Lesmateriaal

Lesvorm

We zijn nu kort door de technische onderdelen van een Headless applicatie heengelopen, maar hoe realiseer en praktiseer je dat nu in een les? Om te beginnen wil ik graag mijn keuze voor het gebruik van een projectmatige lesvorm verantwoorden. 1 van de belangrijkste redenen dat ik dit lesmateriaal projectmatig wil uitvoeren wordt mooi samengevat door deze quote van Vernieuwend Onderwijs: > “Een goed project gaat daarnaast de diepte in. Leerlingen worden uitgedaagd om een onderwerp echt te snappen en hebben deze nieuwe kennis nodig.” Ik vind het belangrijk dat studenten de geleerde kennis kunnen toepassen in een uitdagend project. Omdat dit project vlak voor de stage van de studenten wordt uitgevoerd blijft de kennis vers liggen om te gebruiken op de stageplek. Projectmatig werken vereist ook een stukje zelfstandigheid en verantwoordelijkheid van de student. De student moet zelfstandig de onderdelen plannen in het plan van aanpak en moet het product zelfstandig opleveren. Het project zal dus ook individueel worden uitgevoerd. Om de kennis over te brengen wil ik ook graag de bekwaamheidseisen van Stevens gebruiken: autonomie, competentie en relatie. Deze drie bekwaamheidseisen zijn ook goed toe te passen op het praktische MBO-ICT, waar er met lesgeven wordt gelet op deze drie onderdelen. Bij “competentie” wil ik aangeven dat er echt wat wordt gevraagd van studenten, aangezien het een redelijk complex project is. Er komt namelijk meer bij kijken dan enkel het programmeren. De studenten zullen moeten kunnen documenteren, kritisch nadenken over functionaliteiten, werkonderdelen inplannen, daadwerkelijk programmeren, het instellen en maken van een lokale werkomgeving, nadenken over het uitvoeren van tests en het gebruik van een VCS. Bij autonomie wil ik de studenten graag de ruimte geven zelf het project te ontwikkelen, met zo weinig mogelijk grenzen. Ze moeten zelf keuzes en een voorstel maken (welke uiteraard wel moet worden goedgekeurd door een docent) en de opdracht maken. Voor vragen mogen de studenten altijd bij de docent komen, maar er wordt geen gebruik gemaakt van lessen waarin de studenten alvast onderdelen maken. Bij relatie is het aan mij (de docent) om te fungeren als coach. Van de docent wordt verwacht dat hij of zij regelmatig door de klas loopt om de voortgang in de gaten te houden en te waarborgen. Studenten kunnen vragen stellen aan de docent, maar de docent moet ook vastlopende studenten kunnen signaleren, ook wanneer zij er niks van willen laten merken. Ook bij de feedbackrondes is het belangrijk dat de docent correct feedback levert op de studenten.

Lesindeling

Bij de studenten die dit project zullen uitvoeren zijn de basisprincipes al bekend. Hierbij heb ik het over het programmeren in JavaScript en PHP, het projectmatig werken, het schrijven van de benodigde documenten en het ontwerpen van een webapplicatie. De projecten zullen individueel worden uitgevoerd en elke leerling moet een aantal documenten en een eindproduct opleveren. De volgende onderdelen worden van de student verwacht (deze worden later in dit PvA uitgewerkt) bij de oplevering: * Een plan van aanpak. (Fase 1) * Een functioneel ontwerp. (Fase 2) * Een testplan. (Fase 3) * Een werkend eindproduct. (Fase 3) * Een reflectie. (Fase 3) * Een presentatie (Fase 3) Het project is opgedeeld in 3 fases. Fase 1 en 2 zullen in de eerste periode worden uitgevoerd en de uitwerking van het eindproduct met de reflectie (fase 3) zal in de tweede periode worden uitgevoerd. Hierna zal er een oplevering volgen waarin de student LVF - Project: Headless Webapplicatie - Les 4 presenteert wat hij of zij heeft gedaan. Deze presentatie zal een verkorte versie zijn van de reflectie. Uiteindelijk zullen er tussendoor ook een paar korte theorielessen worden gegeven. Helemaal in het begin is er een les die het project uitlegt, waarna de studenten aan de slag kunnen met de documenten en bijvoorbeeld versiebeheer. Hierna zijn er, aan het begin van fase 3, 3 lessen. 1 les in API en headless en 2 lessen in front-end frameworks. Daarna is er aan het eind van fase 3 nog een les in oplevering.

Tussen- en eindproducten

Er worden in totaal zes producten verwacht van de student. Deze producten zal ik hier beschrijven en uitwerken.

Plan van aanpak

De student moet een plan van aanpak inleveren voor de student begint aan het project. Hierin beschrijft de student de opdracht, wat hij wil uitvoeren en hoe hij dit wil uitvoeren. De belangrijkste punten van het plan van aanpak zijn als volgt: * Een omslag met daarin verplichte onderdelen zoals de naam, het studentnummer en de opdracht. * Een inhoudsopgave. * Een opdrachtomschrijving en voorstel waarin de student binnen het kader van het project een voorstel doet voor een eindproduct. Dit eindproduct moet een headless webapplicatie zijn, waar de functionaliteit los staat van de front-end. De data uit de functionaliteit moet worden aangeboden via een API. Vervolgens wordt deze data opgehaald uit de API en via Vue getoond op de front-end. Het voorstel is globaal en gaat nog niet te diep in op de technische onderdelen van het product. Wel wordt er in het voorstel aangegeven of er wordt gewerkt met een framework of dat er vanilla PHP wordt gebruikt voor de backend. Dit moet vervolgens worden goedgekeurd. * Een planning waarin de student de verschillende tussen- en eindproducten inplant binnen de aangegeven periodes. De student geeft hierin ook aan hoe hij of zij de producten wil ontwikkelen. De student levert vervolgens dit plan van aanpak in en wacht op een goedkeuring van de docent. Als het goed is valt het plan van aanpak al redelijk binnen de opdracht, dus ondertussen kan de leerling alvast een opzet maken voor het functionele ontwerp.

Functioneel ontwerp

Wanneer de student een goedkeuring heeft gekregen op het plan van aanpak kan de student verder met het functioneel ontwerp. Hierin beschrijft de student het eindproduct en gaat de student de functionaliteiten langs. Ook gaat de student qua techniek de diepte in en beschrijft in detail wat er van de functionaliteiten wordt verwacht en hoe deze zullen worden ontwikkeld. Ook worden er doelen voor de webapplicatie opgesteld en worden de functionaliteiten opgedeeld in “Must haves”, “Should haves” en “Could haves” (MoSCoW). Het opstellen van het functioneel ontwerp wordt gedaan aan de hand van de volgende internetbron. Er worden geen wireframes gemaakt.

Testplan

Het testplan die de leerlingen zullen opzetten zal uit twee delen bestaan: het uitwerken en gebruiken van een automatische teststraat en het beschrijven van de functionele tests. Het uitwerken en begrijpen van tests kan ook worden gezien als een subskill van dit project.
Automatische teststraat
De studenten zullen hun code plaatsen in het versiebeheer platform Bitbucket (Gitlab mag ook in overleg, of een alternatief VCS met een pipeline. In deze systemen zitten pipelines (of hoe dit voor het desbetreffende systeem wordt genoemd) waarin een heel simpele automatische teststraat kan worden gebouwd. Dit script kan op verschillende manieren worden ontwikkeld, waarbij het niet zozeer gaat om de techniek die wordt gebruikt, maar meer het begrijpen van tests uitvoeren. Het script (vaak een Yaml file) wordt opgeleverd samen met de uitwerking van de functionele tests.
Functionele tests
De studenten zullen waarschijnlijk niet alle functionaliteiten of onderdelen kunnen uitwerken in hun automatische teststraat, sommige onderdelen moeten handmatig worden getest. Of er wel of niet handmatig moet worden getest, de studenten zullen een kort document moeten schrijven (het testplan) met hierin de functionele tests beschreven. Er wordt beschreven welke functies op welke manier worden getest.

Eindproduct

Het eindproduct wordt opgeleverd via het VCS. De docent wordt dan uitgenodigd om deel uit te maken van de repository, zodat hij of zij de code naar zijn of haar lokale omgeving kan halen om te testen. In de README markdown worden de project-specifieke instellingen aangegeven (bijvoorbeeld hoe de database moet worden geïmporteerd en of het project op een bepaalde PHP versie draait) en eventuele bijlagen (zoals een dummy database export) worden gestuurd via een veilige methode. Het eindproduct mag live worden gezet op een domein, maar dit is niet verplicht. De voorwaarden van het eindproduct is dat deze geen functionaliteit brekende fouten bevat en dat de functionaliteiten die zijn beschreven in het functioneel ontwerp werken. Ook moet het een headless applicatie zijn, waar de backend data wordt aangeboden via een API en deze vanuit deze API wordt getoond in de front-end. Wanneer er gebruik wordt gemaakt van composer / node / etc. packages, moet dit worden vermeld in de README met een installatie instructie. Het liefst wordt hiervoor een install script gemaakt waar alle dependencies worden geïnstalleerd, maar dit is geen must. Het product is standalone, wat betekent dat het niet op een bestaand CMS of E-commerce platform mag worden geschreven.

Reflectie

De studenten maken een korte reflectie waarin zij in retroperspectief schrijven over het project. Hierin schrijven ze over de fouten die zijn gemaakt en hoe deze zijn opgelost. Ook schrijven ze over de onderdelen die beter hadden gekund en hoe deze beter konden. Er wordt hier aangeraden om gebruik te maken van een reflectiemodel (reflectiemodel van Korthagen zal als voorbeeld worden gegeven). Het gebruik van een reflectiemodel is niet verplicht maar is wel een garantie.

Presentatie

De student maakt een korte presentatie waarin hij of zij de voortgang en afronding van het project presenteert en de werking van de webapplicatie laat zien. De reflectie wordt hierin ook kort behandeld.

Lessen

Er zullen in totaal 4 lessen worden gegeven. Er zal 1 introductieles worden gegeven, waarin het project zal worden uitgelegd en het project zal worden langsgelopen. In de vorm van een presentatie en een briefing zullen de deelproducten worden beschreven en wordt er verteld wat er van de studenten wordt verwacht. Ik zal in dit dossier de LVF’s voor deze lessen, samen met de briefing opleveren. Ook zal het concept van een Headless webapplicatie worden uitgelegd. Daarnaast worden er twee inhoudelijke lessen gegeven, waarin de drie delen van de verwachte webapplicatie worden behandeld. Hierbij heb ik het over het ontwikkelen van een REST API en het ontwikkelen van een front-end applicatie met Vue. Aan het eind volgt er nog een les met informatie over het opleveren en waarop de studenten worden getoetst. De eerste les zal vrijwel meteen worden gegeven, wanneer de studenten van start gaan. De twee inhoudelijke lessen worden gegeven aan het eind van Fase 1, voordat de studenten bezig gaan met ontwikkelen. Studenten die hier al veel ervaring mee hebben zijn ondertussen waarschijnlijk al begonnen. Bij de een-na-laatste bijeenkomst wordt de laatste les gehouden, in voorbereiding van het opleveren. De lesvoorbereidingsformulieren zijn te vinden in de bijlagen.

Uitwerking lessen

Natuurlijk zijn er geen regels aan deze lessen verbonden. Maar wel wil ik wat handvaten geven, door te delen hoe ik de lessen zelf zou geven:

Didactisch

> Met name ga ik mij tijdens de theoretische lessen focussen op een instructievorm, namelijk doceren. Aangezien de studenten veel vrije werkruimte krijgen en er weinig lessen zijn, zal het concept van de theorie eerst worden uitgelegd. Hierbij leg ik op basis van eigen vakkunde de concepten achter Headless, API, Front-end Frameworks en opleveringen uit. Later in dit kopje zal ik terugkomen op de punten die ik ga uitleggen. Hierna ik met de studenten een klein onderdeel van de code of een voorbeeld van deze concepten langslopen, waarbij de student zelf ook meedoet. Dit deel valt onder een opdrachtvorm onder de didactische werkvormen.

Uitwerking

> Bij de eerste les, Headless, ga ik dus beginnen met de theorie over Headless. Ik leg aan de hand van de afbeelding van J. Koenigs’ blogpost (die ik hierboven ook heb gebruikt) uit wat een Headless website precies is. Hierna ga ik met studenten, aan de hand van een CMS voorbeeld zoals Wordpress, Drupal of Laravel (de studenten hebben sowieso al eerder gewerkt met Laravel) uitleggen hoe een Headless applicatie binnen dit CMS eruit zou zien. Ook maak ik gebruik van een bord die aanwezig is om voorbeelden uit te tekenen. > > In deze les praat ik ook over de voordelen die Headless met zich meebrengt en waarom dit zo’n relevant onderwerp is (met name op gebied van performance en scheiding van data). > > Bij les twee, API’s, ga ik met studenten kort een API langslopen. Ik ga beginnen met een instructievorm, waar ik de theorie achter een API uitleg. Hierbij gebruik ik het programma “postman” om API requests te sturen en kijk ik met de studenten samen naar de data die we terugkrijgen. In mijn eigen gebouwde API krijg ik bijvoorbeeld productdata terug als ik een API request doe naar de product/read_single.php file en hierbij een product ID meelever. > > Daarna maken we een heel simpele API, die niet is verbonden aan een database, waarbij we puur dummy-data beschikbaar stellen op een URL. Dit wordt klassikaal uitgevoerd. > > Bij de derde les in Front-end Frameworks loop ik met de studenten langs de verschillende Front-end Frameworks die er beschikbaar zijn (enkel oppervlakkige informatie zoals voordelen nadelen en het gebruik van templates) zoals Vue, React, Angular etc.. Hierna focussen wij ons op Vue en gaan we in de les een Vue project opzetten (wat ongeveer hetzelfde werkt als Laravel). Het project opzetten wordt dus klassikaal uitgevoerd, waarna de studenten zelfstandig aan de slag gaan met het maken van templates. In de les wordt verwacht dat ze in ieder geval een zinnetje of een afbeelding online kunnen krijgen, wat een goed startpunt geeft om de rest uit te voeren. > > De laatste les is puur informatief. Er wordt kort uitgelegd wat er wordt verwacht van de oplevering, welke onderdelen waar en hoe moeten worden ingeleverd en de presentaties worden met de studenten ingepland.

Opdrachtomschrijving

Hierbij ook een voorbeeld van hoe ik de opdrachtomschrijving zou formuleren: > In dit project zal je een webapplicatie maken die gebruik maakt van 2 onderdelen: > > Een API die data vanuit een database beschikbaar stelt. > Een Front-end middels Vue. > > Je mag zelf verzinnen wat voor een webapplicatie jij ontwikkelt, zolang deze maar een API en een front-end in Vue bevat. De webapplicatie moet dan vervolgens door de docent worden goedgekeurd. > > Het project bestaat uit 3 fases, waarvan fase 1 en 2 in de eerste periode zijn en fase 3 in de tweede periode. In de eerste periode zal de focus met name op documentatie liggen en het ontwerpen van de applicatie en in de tweede periode zal er met name ontwikkeld en gereflecteerd worden. > > De volgende producten worden van jou verwacht: > > Een plan van aanpak. (Fase 1) > Een functioneel ontwerp. (Fase 2) > Een testplan. (Fase 3) > Een werkend eindproduct. (Fase 3) > Een reflectie. (Fase 3) > Een presentatie (Fase 3) > > Er zullen ook een viertal lessen worden gegeven. 1 les ter introductie, die verder ingaat op de planning, 2 vakinhoudelijke lessen net voor de tweede periode en 1 eindles vlak voor de oplevering. > > Zorg dat je elk product laat goedkeuren door de docent voor je verder gaat! Elk product is gebouwd op de vorige. > > Veel succes!

Nawoord

Ik heb zelf met ontzettend veel plezier dit moderne concept omgetoverd in lesmateriaal voor mijn opleiding. Ik hoop hiermee andere te kunnen helpen of inspireren! Stuur gerust een berichtje via het contactformulier op de contactpagina als je vragen of opmerkingen hebt!

LVF's

De LVF's vindt je hier.