Eerst de logica, dan de vormgeving: dat was ons uitgangspunt. (dit was een misstap in retrospectief, daar meer over in de conclusie). Dit maakte wel dat we sneller konden doorontwikkelen op die logica. We zijn zo snel mogelijk in het opzetten van een goede basis betreft workflow gedoken zodat we daar de rest van het project profijt van zouden hebben (bevordert de samenwerking, vermindert merge conflicts, etc).
Wij hebben hetzelfde gedaan met het opzetten van de server; wat er benodigd was voor het serveren van een nieuwe, snelle site, kon al opgezet worden voordat er verdere case-specifieke keuzes moesten worden gemaakt. Zoals; static site generator, deployment, etc.
In de briefing werd al de suggestie opgeworpen om te migreren van het nu gebruikte WordPress naar een zogenoemde headless CMS. Hierbij kun je gebruik maken van losse externe modules die makkelijk inwisselbaar zijn. Dit is makkelijker voor studenten en docenten om code te schrijven voor alleen de front-end zonder iets van een CMS af te weten.
Headless (of serverless / JAMStack) houdt in dat je front-end van een website theoretisch loskoppelt van bijvoorbeeld het CMS en communiceert met zo'n CMS middels een API in plaats van dat de website direct gekoppeld is aan het CMS en het CMS (de server) zelf de pagina's serveert.
Als je meer informatie wilt over wat Headless precies inhoudt kan je kijken naar de Headless CMS-pagina.
We hebben voor een headless opzet gekozen om de volgende redenen: (ook te vinden op JAMStack.org).
Niets is sneller dan het serveren van statische bestanden vanaf een CDN (Content Delivery Network) zoals ook de website JAMStack.org zelf zegt. Daarnaast is dit ook iets wat Declan tijdens de minor aankaartte. Aangezien CMD ons inziens staat voor performant, accessible en progressively enhanced websites is dit iets wat heel zwaar woog in onze beslissing.
Het hosten van een headless website kan vaak gratis, het enige wat je hoeft aan te schaffen is een domeinnaam, vervolgens kan je de website (aangezien het uiteindelijk allemaal statische bestanden zijn) via een CDN als Netlify of Vercel hosten in plaats van dit te moeten doen op een dedicated server.
Iedereen die aan het project werkt kan zich grotendeels focussen op puur de front-end code. Er is namelijk geen server die we zelf hoeven te onderhouden, ook hoeven we vrijwel geen server-side code te schrijven. Het enige dat we hoeven te schrijven zijn HTML, JavaScript en CSS bestanden. Dit maakt de drempel om aan de CMD-website te werken ook lager.
Er zal een migratie van de content nodig zijn. Hierbij zou theoretisch gezien een koppeling gemaakt kunnen worden met WordPress, of de content geheel geëxporteerd kunnen worden en vervolgens geïmporteerd in het nieuwe CMS.
Bij de bespreking van onze debriefing werd daarentegen duidelijk dat de benodigde content op de (nieuwe) site, vrijwel parralel staat aan wat er nu op de live website te zien is. What you see is what you get. Het leek ons hierna eigenlijk niet een groot probleem om de content simpelweg handmatig over te nemen van de huidige site.