Merge pull request #479 from ccGabbles/main

Advent calendar blog post: 'Jamstack - Unwrapping the (Possible) Future of Web Development! 🎁' in Dutch and English

src/en/blog/2024/12/jamstack--unwrapping-the-possible-future-of-web-development.md

@@ -0,0 +1,63 @@
+---
+title: Jamstack - Unwrapping the (Possible) Future of Web Development! 🎁
+date: 2024-12-28
+author: Gabriël Moawad
+summary: A concise introduction to the Jamstack architecture, which combines pre-rendering, decoupling, and static files to streamline web development without complex server interaction on the client side.
+categories:
+  - Advent calendar
+key: jamstack--unwrapping-de-mogelijke-toekomst-van-webdevelopment
+---
+
+## The spirit of Jamstack
+
+Jamstack isn't just a set of predefined frameworks, a specific tool, or any programming language. In the true holiday spirit, it embodies conventions, practices, and traditions that mirror an architecture designed to help you build more performant and secure products.
+
+> Jamstack is a modern web development architecture aimed at making the web faster, more secure, and easier to scale. The term "Jamstack" stands for JavaScript, APIs, and Markup. It emphasizes pre-rendering and decoupling, allowing websites to be served as static files from a CDN, which enhances performance and security. JavaScript handles dynamic functionalities, APIs connect to backend services, and Markup is pre-built during the build process.
+
+Reading this definition, you might think: "These concepts are already on the wishlist of many companies and their development teams right now!" And you'd be right. There are many parallels between Jamstack and the Microservice, Composable, and MACH movements we've seen over the last few years. But Matt Biilmann, CEO and Co-founder of Netlify, who first mentioned Jamstack back in 2015, is taking 'decoupling' a step further than we're used to. But before we can fully understand that, a little history lesson:
+
+## The monolithic past and the microservices revolution
+
+In the olden days of web development, we had the so-called monolithic architecture. magine a giant snowball, where everything—client-side user interface, server-side application, and database—is packed tightly together into a single, indivisible unit. This approach results in a large codebase with little modularity, making updates a bit like trying to change the filling of a Christmas pudding without breaking it apart. This all results in a higher risk of downtime, as a failure in one part can affect the entire system. Additionally, these larger codebases become cumbersome to manage, making it harder to implement new features or quickly fix bugs.
+
+Enter microservices architecture, the elves of the web development world. This approach was aimed at breaking down monolithic applications into smaller, independent units. Each microservice handles a specific function and operates independently, communicating through APIs. This modularity allows for independent updates, scaling, and deployment, much like Santa's workshop where each elf has a specialized, isolated task.
+
+## Servers vs. CDNs
+
+Santa's workshop is located at the North Pole, bustling with elves working tirelessly to fulfill all these requests. If every elf had to handle each request for the same toy, and instantly let Santa deliver it when it's done, it would be quite inefficient. This is where Jamstack steps in, transforming the process with the magic of ✨ pre-rendering ✨.
+
+Rather than having a server handle every single request, Jamstack pre-renders all pages, wrapping them up as static HTML files ready to be delivered. These static files are then distributed to Content Delivery Networks (CDNs) around the globe. So instead of Santa having to race everywhere on his sleigh, they're stationed worldwide, ready to deliver gifts from closer proximity. This approach ensures that content is delivered quickly and efficiently.
+
+![Diagram of the traditional flow versus Jamstack flow](/_img/blog/2024/12/advent-2024-gmoawad/jamstack-diagram.png)
+
+## How to get started
+
+Getting started with Jamstack can seem daunting, but it's actually quite straightforward. The magic in all this are the so-called Static Site Generators](https://jamstack.org/generators/) who already do most of the work for you! These frameworks enable you to pre-render external data (From, for instance, an [Headless CMS](https://jamstack.org/headless-cms/) into markup, creating static HTML files. This makes your product less 'error-prone' as whenever it's build, the product including data is now packaged and completely stand alone. This also ensures that if a static site is attacked, there won't be any backend servers that will go down, at most a node of the CDN serving the site.
+
+This might sound like it won't show any changes in data or code, but how this works in the more mature Jamstack implementations is that webhooks (listening for both code and content changes) trigger the build pipeline automatically, and the `dist` folder, consisting of purely static assets, is regenerated with new data/code and uploaded to the CDNs again. By following these steps, You can start by setting up your own Jamstack project and experience the benefits of this form of web architecture.
+
+1. Pick a Headless CMS with a free plan, such as [Contentful](https://www.contentful.com/sign-up/?plan=Free/), and create a space with some content definitions and entries.
+2. Choose a simple Static Site Generator, like [eleventy](https://www.11ty.dev/), and create templates with 'hardcoded' data for now.
+3. Write a Node.js script, for example using Axios, to fetch data from the Headless CMS endpoint and save it locally (e.g., in a JSON file).
+4. Adjust the website templates so they reference the locally stored data fetched from the Headless CMS.
+5. Add another Node.js script to generate the static site using your Static Site Generator's functionality.
+6. Push all of this to a repository, such as on [GitHub](https://www.github.com).
+7. Go to a platform like [Netlify](https://netlify.com/), link your repository, and deploy your project using the combination of the Node.js scripts created earlier.
+8. Configure webhooks for both content updates in Contentful and code changes in your repository to automatically trigger the build process.
+9. At this point, your content should update automatically: the webhooks trigger your script to fetch new data, regenerate the site, and deploy it to your chosen platform!
+
+## Technical constraints
+
+I hear you thinking, weren't we serving static files already back when Santa was a lot younger? Well, we did but directly working in HTML files and not automated with the power of modern web development tools like we can now! These Static Site Generators make this a lot easier for us, but there are still constraints and complexities we have to think about.
+
+For instance, for bigger or frequently changing sites, a dilemma of frequency of changes versus volume can arise. Static site generation might take long or get started so often that it essentially is serving up new data just like we used to in the 'old fashioned' flow, making it impossible to cache the static files on the CDN. To solve these types of questions, we might need to look into scheduled or bundled runs of the Static Site generator. Or even more complex, only pre-rendering the changes (delta) since the last run, instead of regenerating all the unchanged pages.
+
+here are also sites that cannot be fully generated statically. For example, consider interactions on an e-commerce site, where items need to be added to a shopping cart and later retrieved. This means that during runtime, API calls to microservices or interaction with local storage are still required. This process is called 'hydration', where static pages are “enriched” on the client side to enable dynamic functionality. This brings challenges such as data synchronization and optimizing load times to ensure that static and dynamic elements work seamlessly together.
+
+## Conclusion
+
+While Jamstack offers a modern, efficient, and secure approach to web development, it's not without its challenges. The need to manage build times, the frequency of updates, and hydrating static and dynamic content can introduce complexities, especially when working on larger projects. However, with careful planning and considering if the benefits outweigh the negatives, these challenges could possibly be managed, making the Jamstack experience as delightful as opening a present on Christmas morning. 🎄
+
+## About the author
+
+Gabriël Moawad is a front-end developer from Utrecht with over 11 years of experience at Capgemini's Digital Customer Experience Front-end Team. He studied ICT at the Amsterdam University of Applied Sciences and started his career at smaller agency-like companies like Mirabeau and Tizio. At Capgemini, he's worked with clients like ABN Amro, Lacoste, SuitSupply, Unilever, the Dutch Police, and now at Boels where he is implementing Contentstack. Gabriël's current passion lies in the MACH, Headless CMS, and composable domain, which ties into the Jamstack focus of this article. In addition, he loves basketball, board games, video games, and traveling.

src/nl/blog/2024/12/jamstack--unwrapping-de-mogelijke-toekomst-van-webdevelopment.md

@@ -0,0 +1,63 @@
+---
+title: Jamstack - Unwrapping De (mogelijke) toekomst van webdevelopment! 🎁
+date: 2024-12-28
+author: Gabriël Moawad
+summary: Een beknopte introductie tot de Jamstack-architectuur, die pre-rendering, ontkoppeling en statische bestanden combineert om webontwikkeling te stroomlijnen zonder complexe serverinteractie aan de client-side.
+categories:
+  - Adventskalender
+key: jamstack--unwrapping-de-mogelijke-toekomst-van-webdevelopment
+---
+
+## De geest van Jamstack
+
+Jamstack is geen set van voorgedefinieerde frameworks, een specifieke tool of een programmeertaal. In de ware geest van de feestdagen, belichaamt het conventies, best practices en tradities die een architectuur weerspiegelen, ontworpen om producten te bouwen met goede performance en veiligheid.
+
+> Jamstack is een moderne architectuur voor webontwikkeling die erop gericht is het web sneller, veiliger en gemakkelijker schaalbaar te maken. De term 'Jamstack' staat voor JavaScript, API's en Markup. Het legt de nadruk op pre-rendering en ontkoppeling, waardoor websites kunnen worden geserveerd als statische bestanden op een CDN, wat de prestaties en beveiliging verbetert. JavaScript handelt dynamische functionaliteiten af, API's maken verbinding met backendservices en Markup wordt vooraf gebouwd tijdens het bouwproces.
+
+Wanneer je deze definitie leest, denk je misschien: “Deze concepten staan nu al op het verlanglijstje van veel bedrijven en hun ontwikkelteams!”. En je hebt gelijk. Er zijn veel parallellen tussen Jamstack en de bewegingen van Microservices, Composable en MACH die we de afgelopen jaren hebben gezien. Maar Matt Biilmann, CEO en medeoprichter van Netlify, die Jamstack voor het eerst noemde in 2015, gaat met 'ontkoppeling' een stapje verder dan we gewend zijn. Maar voordat we daar volledig induiken, eerst een kleine geschiedenisles:
+
+## Het monolithische verleden en de microservice revolutie
+
+In de beginjaren van webontwikkeling hadden we de zogenaamde monolithische architectuur. Stel je een gigantische sneeuwbal voor, waarin alles dicht op elkaar zit in een enkele, ondeelbare structuur, inclusief de interface aan de client-side, de business logica server-side en de database. Deze aanpak resulteert in een grote codebase met weinig modulariteit, waardoor updates een beetje lijken op het veranderen van de vulling van een kerstpudding zonder deze in zijn geheel uit elkaar te moeten halen. Dit alles resulteert in een hoger risico op downtime, omdat een fout in één onderdeel gevolgen kan hebben voor het hele systeem. Bovendien kunnen deze grotere codebases lastig te beheren worden, waardoor het moeilijker wordt om nieuwe functies te implementeren of bugs snel op te lossen.
+
+Toen was daar de microservices-architectuur, een revolutie in de webontwikkelingswereld. Deze aanpak splitst monolithische applicaties op in kleinere, onafhankelijke eenheden. Elke microservice voert een specifieke functie uit en werkt onafhankelijk, waarbij ze communiceren via API's. Deze modulariteit maakt onafhankelijke aanpassingen, schaling en implementatie mogelijk, net als de werkplaats van de Kerstman waar elke elf een gespecialiseerde, geïsoleerde taak heeft.
+
+## Servers vs. CDN's
+
+De werkplaats van de Kerstman bevindt zich op de Noordpool, waar de elfen onvermoeibaar werken om aan alle verzoeken te voldoen. Als elke elf elk verzoek voor hetzelfde speelgoed zou moeten afhandelen en het meteen door de Kerstman zou moeten laten bezorgen als het klaar is, zou dat behoorlijk inefficiënt zijn. Hier komt Jamstack om de hoek kijken en transformeert het proces in een klap door de magie van ✨ pre-rendering ✨.
+
+In plaats van een server elke aanvraag te laten afhandelen, maakt Jamstack alle pagina's vooraf op en verpakt ze in statische HTML-bestanden die klaar zijn om direct getoond te worden. Deze statische bestanden worden vervolgens gedistribueerd naar Content Delivery Networks (CDN's) over de hele wereld. Dus in plaats van dat de Kerstman met zijn arrenslee overal naartoe moet racen, zijn ze wereldwijd gestationeerd, klaar om cadeautjes van dichterbij af te leveren. Deze aanpak zorgt ervoor dat de inhoud snel en efficiënt wordt weergegeven.
+
+![Diagram van de traditionele stroom versus Jamstack stroom](/_img/blog/2024/12/advent-2024-gmoawad/jamstack-diagram.png)
+
+## Aan de slag
+
+Beginnen met Jamstack kan ontmoedigend lijken, maar het is eigenlijk vrij eenvoudig. De magie in dit alles zijn de zogenaamde [Static Site Generators](https://jamstack.org/generators/) die het meeste werk al voor je oppakken! Met deze frameworks kunt u externe data (van bijvoorbeeld een [Headless CMS](https://jamstack.org/headless-cms/)) vooraf omzetten in markup, waardoor statische HTML-bestanden ontstaan. Dit maakt je product minder vatbaar voor fouten, omdat wanneer het gebouwd wordt, het product inclusief data nu verpakt is en volledig op zichzelf staat. Dit zorgt er tevens voor dat als een statische site wordt aangevallen, er geen achterliggende servers om zullen vallen, hoogstens een node van de CDN die de site distribueert.
+
+Dit klinkt misschien alsof er geen wijzigingen meer kunnen plaatsvinden in data of code, maar in meer volwassen Jamstack-implementaties zorgen webhooks (die luisteren naar veranderingen in zowel code als content) ervoor dat de build pipeline automatisch wordt getriggerd. De `dist`-map, bestaande uit puur statische assets, wordt dan opnieuw gegenereerd met nieuwe data/code en geüpload naar de CDNs. Door de onderstaande stappen te volgen, kan je zelf beginnen met het opzetten van een eigen Jamstack-project en de voordelen van deze vorm van webarchitectuur ervaren.
+
+1. Kies een Headless CMS met een trial/gratis component, zoals [Contentful](https://www.contentful.com/sign-up/?plan=Free/) en maak een space aan met een aantal contentdefinities en entries.
+2. Kies een eenvoudige Static Site Generator zoals, bijvoorbeeld, [eleventy](https://www.11ty.dev/) en bouw een, voor nu, templates met 'hardcoded' data.
+3. Maak een Node.js script met bijvoorbeeld Axios die de gegevens via het headless CMS endpoint ophaalt en lokaal (in een json) wegschrijft.
+4. Pas nu de website templates aan zodat het refereert naar de gegevens uit het Headless CMS die lokaal zijn weggeschreven.
+5. Zorg er nu voor dat je met nog een Node.js scriptje je de site statisch kan genereren (met functionaliteit uit je Static Site Generator).
+6. Push dit alles naar een repository op bijvoorbeeld [GitHub](https://www.github.com).
+7. Ga naar een platform zoals [Netlify](https://netlify.com/). Koppel je repository en implementeer daar alles met de combinatie van bovenstaande Node.js scripts.
+8. Configureer webhooks voor zowel contentupdates in Contentful als codewijzigingen in je repository om de bouw van je statische site te triggeren.
+9. Nu zou je inhoud automatisch moeten worden upgedate daar je script door deze webhooks wordt aangezwengelt, de nieuwe gegevens ophaalt, de site genereert en uitrolt op je gekozen platform!
+
+## Technische beperkingen
+
+Ik hoor je denken: serveerden we eigenlijk al geen statische bestanden toen de Kerstman nog vele jaren jonger was? Nou, dat deden we inderdaad! Alleen werkte we toen rechtstreeks in HTML-bestanden en niet geautomatiseerd met de kracht van alle webdevelopment ontwikkelingen zoals we nu kunnen! Deze Static Site Generators maken dit een stuk eenvoudiger voor ons, maar er zijn nog steeds beperkingen en complexiteiten Waar we rekening mee moeten houden.
+
+Voor grotere of vaak veranderende sites kan er bijvoorbeeld een dilemma ontstaan tussen de frequentie van wijzigingen en het volume. Het genereren van statische sites kan lang duren of zo vaak starten dat het in wezen nieuwe gegevens serveert zoals we gewend waren in de 'ouderwetse' flow, waardoor het onmogelijk wordt om de statische bestanden te cachen op het CDN. Om dit soort problemen op te lossen, moeten we kijken naar geplande of gebundelde runs van de Static Site generator. Of nog complexer, door alleen de delta in wijzigingen te renderen sinds de vorige keer dat het gegenereerd is in plaats van ook alle ongewijzigde pagina's.
+
+Daarnaast zijn er sites die niet in zijn geheel statisch gegenereerd kunnen worden. Denk bijvoorbeeld aan interactie op een e-commercesite, waar dingen aan een winkelwagentje moeten worden toegevoegd en later weer terugkomen, wat betekent dat er tijdens runtime nog steeds API-calls naar microservices plaatsvinden of interactie met localstorage nodig is. Dit heet 'hydrateren', waarbij statische pagina’s aan de client-side pas worden “verrijkt” voor dynamische functionaliteit. Dit brengt uitdagingen met zich mee, zoals data-synchronisatie en het optimaliseren van laadtijden, waardoor statische en dynamische elementen naadloos samenwerken.
+
+## Conclusie
+
+Hoewel Jamstack een moderne, efficiënte en veilige benadering van webontwikkeling biedt, is het niet zonder uitdagingen. De noodzaak om bouwtijden, de frequentie van updates en het hydrateren van statische en dynamische inhoud te ontwikkelen, kan het geheel complex maken. Iets wat vooral bij het werken aan grotere projecten zichtbaar wordt. Met zorgvuldige planning en afweging van de voor- en nadelen kunnen deze uitdagingen mogelijk worden getackled, waardoor een Jamstack-ervaring net zo heerlijk kan zijn als het openen van cadeautjes tijdens Kerst. 🎄
+
+## Over de auteur
+
+Gabriël Moawad is een front-end developer uit Utrecht met meer dan 11 jaar ervaring bij Capgemini's Digital Customer Experience Front-end Team. Hij studeerde ICT aan de Hogeschool van Amsterdam en begon zijn carrière bij kleinere agency-achtige bedrijven zoals Mirabeau en Tizio. Bij Capgemini heeft hij gewerkt met klanten als ABN Amro, Lacoste, SuitSupply, Unilever, de Nederlandse Politie en nu bij Boels waar hij Contentstack implementeert. Gabriëls huidige passie ligt in het MACH, Headless CMS en composable domein, wat aansluit bij de Jamstack focus van dit artikel. Daarnaast houdt hij van basketbal, bord- en videogames en reizen.