Techstack

Storyblok (CMS)

We gebruiken Storyblok als headless CMS. Na ons onderzoek hebben we besloten dat van de drie geteste CMS'en Storyblok beschikt over de meest gebruiksvriendelijke interface.

Daarnaast was het hebben van een live preview een grote must vanuit de opdrachtgever dus dat woog zwaar mee in onze beslissing om uiteindelijk te kiezen voor Storyblok. Voor de developers scheelt het dat integratie met Storyblok eenvoudig is op te zetten zoals eerder te lezen is in het Headless CMS hoofdstuk.

Eleventy (static site generator)

We gebruiken Eleventy als static site generator. Eleventy zorgt er dus voor dat we vanuit HTML (Nunjucks) templates pagina's kunnen opbouwen. De reden dat we Eleventy gebruiken is omdat we enerzijds niet de tijd hadden om zelf een static site generator te bouwen en anderzijds dat we zo dicht als mogelijk wilde blijven bij vanilla JavaScript, HTML en CSS en dit biedt Eleventy dan ook.

De reden dat we 't dichtst bij vanilla wilde blijven is dat dit het eenvoudiger maakt voor andere CMD studenten / docenten om verder te werken aan dit project door bijvoorbeeld componenten te kunnen bouwen.

Als we gebruik zouden maken van bijvoorbeeld Nuxt (Vue) of Next (React) dan zouden nieuwe collaborators eerst specifiek dat framework moeten leren voordat ze aan de slag kunnen met het verder bouwen aan de playground.

Ook forceert dit de developers een beetje om meer progressively enhanced te werken waar je anders eerder naar een JavaScript oplossing zou grijpen omdat dat een simpelere oplossing is binnen een JavaScript framework als Nuxt of Next.

Nunjucks (templating)

We gebruiken Nunjucks vooralsnog als templating language. Met name omdat dit zit ingebakken met Eleventy en het daar heel lekker mee werkt. Natuurlijk kan dit later nog omgezet worden naar iets als EJS bijvoorbeeld wat veel studenten tijdens de tech-track gebruiken.

Vercel (deployment)

De keuze voor Vercel in plaats van iets als Netlify is met name vanwege de integratie van serverless functions. De serverless functions van Vercel liggen wat dat betreft dichter bij een Express JS route (again, iets wat de studenten in de tech-track leren) in tegenstelling tot die van Netlify (zie onderstaande code snippets).

// Vercel serverless function
module.exports = (request, response) => {
  response.status(200)
  response.json({
    message: "Dit is een Vercel serverless function"
  })
}

// Netlify serverless function
exports.handler = async (event, context) => {
  return {
    statusCode: 200,
    body: {
      message: "Dit is een Netlify serverless function"
    }
  }
}

Ook is het gebruik van Vercel serverless functions ons inziens eenvoudiger qua mappenstructuur. Door simpelweg een `api` folder te plaatsen in de root van het project pakt Vercel dat direct op alszijnde serverless functions waar je met Netlify in de config file een pad moet aangeven naar die serverless functions en altijd moet fetchen naar /.netlify/functions/my-serverless-function waar je bij Vercel simpelweg een request kan sturen naar /api/my-serverless-function.

Verder delen Vercel en Netlify veel functionaliteiten zoals Continiuous Integration / Development en deploy previews (waardoor het eenvoudiger is te zien welke wijzigingen zijn aangebracht in een pull request).

Storybook (pattern library)

Als we uiteindelijk helemaal voluit willen gaan kunnen we er ook voor kiezen om alle gebruikte componenten beschikbaar te maken in Storybook. Storybook is een pattern library tool waar alle componenten geïsoleerd van elkaar ontwikkeld en getest kunnen worden.

Idealiter schrijven we voor nu een script waarmee onze nu geschreven component-templates post-build omgezet worden naar plain HTML, weggeschreven naar de Storybook-folder en er vervolgens met die data een Storybook-Pattern Library wordt gegenereerd. Dan fungeert Storybook als style guide en component library.

Wat nog beter zou zijn, is dit proces omdraaien; componenten worden aangemaakt in Storybook en fungeren als single source of truth. Zoals de library bedoeld is; 'pattern library first' designen en developen.

Dit hebben we tijdens dit project helaas niet actief kunnen doen vanwege een gebrek aan tijd. Dit zou er daarentegen wel voor kunnen zorgen dat we vanaf de basis altijd een soort bibliotheek hebben van de CMD-componenten ondanks dat misschien de hele website op de schop gaat. Die bibliotheek kunnen we dan ook afgezonderd delen met derde partijen, via iets als zeroheight nóg toffer displayen, serveren als een statische site en toevoegen aan de cmd-site zelf, etc.