Monorepo’s en micro-frontends

Monorepo's bieden verschillende voordelen, vooral voor grotere teams:

• Eenvoudiger afhankelijkheden beheren: Versies van gedeelde bibliotheken zijn gemakkelijker te beheren en conflicten zijn eenvoudiger te voorkomen.
• Code delen: Componenten, hulpfuncties en TypeScript-typen kunnen eenvoudig worden gedeeld en hergebruikt in verschillende projecten.
• Atomische commits: Wijzigingen die meerdere projecten raken, kunnen samen worden vastgelegd, zodat alles altijd compatibel blijft.
• Gecentraliseerde hulpmiddelen: Configuraties voor bouwen, testen en linten kunnen in alle projecten worden gedeeld, waardoor je minder tijd kwijt bent aan configuratie.

In een Next.js-monorepo kun je een structuur gebruiken waarin je applicaties duidelijk van je gedeelde pakketten zijn gescheiden:

my-monorepo/
├── apps/
│ ├── web/ // A Next.js application
│ ├── admin/ // Another Next.js application
├── packages/
│ ├── ui/ // Shared React components
│ ├── utils/ // Shared utility functions
│ ├── types/ // Shared TypeScript types
├── package.json
└── tsconfig.json

Hulpmiddelen zoals Turborepo of Nx helpen builds en afhankelijkheden binnen monorepo's efficiënt te beheren.

In een monorepo kun je algemene functionaliteit in een gedeeld pakket plaatsen. Hier zie je een eenvoudig TypeScript-hulpprogramma voor het opmaken van datums, dat zich normaal gesproken in packages/utils/src/formatDate.ts zou bevinden:

export function formatDate(date: Date): string {
  return date.toLocaleDateString('en-US', {
    year: 'numeric',
    month: 'long',
    day: 'numeric',
  });
}

Elke applicatie binnen de monorepo kan deze functie nu importeren en gebruiken.

Stel dat de functie formatDate uit de vorige scène in een gedeeld utils-pakket binnen je monorepo staat. Zo zou een Next.js-pagina (bijvoorbeeld apps/web/app/page.tsx) deze gebruiken. Hoewel dit fragment voor de demonstratie op zichzelf staat, zou je in een monorepo formatDate uit je gedeelde pakket importeren.

Micro-frontends zijn een architectuurstijl waarbij een webapplicatie uit veel onafhankelijke, kleinere applicaties bestaat. Elk "micro-frontend" wordt door verschillende teams zelfstandig ontwikkeld, geïmplementeerd en beheerd.

• Onafhankelijke teams: Elk team beheert een specifiek deel van de UI (bijvoorbeeld de koptekst, productcatalogus of het gebruikersprofiel).
• Technologieonafhankelijk: Verschillende micro-frontends kunnen verschillende frameworks gebruiken (bijvoorbeeld één in Next.js, een andere in Vue en nog een andere in React).
• Onafhankelijke implementatie: Elk micro-frontend kan afzonderlijk worden geïmplementeerd, waardoor er minder afstemming nodig is.

Micro-frontends bieden veel flexibiliteit, maar brengen ook afwegingen met zich mee:

• Voordelen:
  - Schaalbaarheid voor grote organisaties
  - Flexibiliteit in de technologiestack voor verschillende teams
  - Snellere, onafhankelijke implementatie van specifieke functies
  - Meer zelfstandigheid en verantwoordelijkheid voor teams
• Uitdagingen:
  - Meer complexiteit bij integratie en communicatie tussen onderdelen
  - Mogelijk inconsistente UI/UX tussen verschillende micro-frontends
  - Meer operationele overhead door het beheren van meerdere implementaties

Next.js-applicaties kunnen worden gebruikt om afzonderlijke micro-frontends te bouwen of kunnen fungeren als de "containerapplicatie" die ze host. Hoewel Next.js zelf geen ingebouwde ondersteuning voor micro-frontends heeft, zijn veelgebruikte strategieën:

• Iframes: Afzonderlijke Next.js-apps als iframes in een hoofdapplicatie insluiten.
• Module Federation: Module Federation van Webpack 5 gebruiken (hiervoor is een aangepaste Webpack-configuratie of zijn bibliotheken nodig) om tijdens runtime dynamisch modules tussen Next.js-apps te delen.
• Web Components: Onafhankelijke UI-componenten bouwen die in elk framework kunnen worden geïntegreerd, ook in Next.js.

De keuze hangt af van de mate van integratie en onafhankelijkheid die je project nodig heeft.

Zowel monorepo's als micro-frontends proberen schaalbaarheidsproblemen op te lossen, maar ze richten zich op verschillende aspecten:

• Monorepo: Het meest geschikt voor het delen van code en het garanderen van atomische wijzigingen in gerelateerde projecten, die vaak door één groot team of nauw samenwerkende teams worden beheerd. De nadruk ligt op codeorganisatie en de ontwikkelaarservaring.
• Micro-frontends: Ideaal voor grote, verspreide teams die onafhankelijke ontwikkeling, implementatie en technologiekeuzes nodig hebben voor afzonderlijke delen van een gebruikersinterface. De nadruk ligt op de organisatiestructuur en zelfstandigheid bij implementatie.

Het is ook goed om te weten dat een monorepo soms meerdere micro-frontends kan bevatten, zodat je de voordelen kunt combineren.

In deze les hebben we twee krachtige architectuurpatronen voor het schalen van webapplicaties verkend: monorepo's en micro-frontends.

• Monorepo's brengen meerdere projecten samen in één repository en bevorderen het delen van code, vereenvoudigd beheer van afhankelijkheden en atomische commits.
• Micro-frontends splitsen één grote UI op in onafhankelijke, afzonderlijk implementeerbare applicaties en bevorderen de zelfstandigheid van teams en flexibiliteit in technologie.

Als je deze patronen begrijpt, kun je goed onderbouwde keuzes maken bij het structureren van grootschalige Next.js-projecten voor optimale schaalbaarheid en onderhoudbaarheid.