Case 04
Eén monoliet in plaats van een auth-service
Meer dan één app hosten betekende een keuze over inloggen en rollen. De klassieke aanpak is een aparte auth-service waar ieder ander programma naartoe belt. Wij kozen het omgekeerde: één proces, met identiteit en rollen er al in gebakken.
Aparte auth-service
Geen
Inlogmethode
Magic link, geen wachtwoord
Nieuwe app toevoegen
Eén module, zelfde identiteit
Type wijziging
Architectuurkeuze, vóór de eerste tweede app
Situatie
Waar dit begon
Er kwam een tweede app aan naast de eerste: een capaciteitsplanner naast de microlearning-dienst, met meer daarna te verwachten. Iedere app heeft mensen die inloggen en rollen die bepalen wat ze mogen zien. Dat moest voor N apps werken, niet alleen voor de eerste twee.
De klassieke oplossing daarvoor is een aparte auth-service: één dienst die "wie ben jij, wat mag je hier" beantwoordt, en waar ieder ander programma naartoe belt om dat antwoord te krijgen. Dat is een extra dienst om te bouwen, te bewaken en in de lucht te houden, plus een netwerkaanroep erbij op ieder verzoek dat om een rol vraagt.
Beslissing
Wat we besloten, en waarom niet anders
Wij kozen het omgekeerde: geen aparte dienst, maar één FastAPI-monoliet waar identiteit, inloggen en rollen al onderdeel van zijn, en waar iedere app een module in datzelfde proces is. Een module levert alleen zijn eigen router en tabellen aan; wie iemand is en wat die mag, vraagt hij via één gedeelde functie in plaats van een eigen inlogscherm te bouwen.
Om te voorkomen dat modules elkaar in de weg lopen zonder een aparte dienst daarvoor nodig te hebben, ligt dat vast in een vastgelegd contract: elke module krijgt zijn eigen tabellen-voorvoegsel (cap_, ml_), zijn eigen route-prefix, en mag nooit rechtstreeks in een andere module grijpen. Inloggen zelf gaat via een magic link per e-mail: één keer klikken, geen wachtwoord om te verliezen of te resetten, met een getekende sessie die vertelt wie iemand is en welke rollen die sessie meebrengt.
Verloop
Wat er gebeurde, in volgorde
Van de eerste ontwerpkeuze tot de eerste echte module die op het patroon draaide, 6 tot 7 augustus 2026.
6 augustus 2026, 19:42
De topologie vastgelegd: één monoliet, geen satellieten
Eén FastAPI-proces zou identiteit, rollen en sessies bezitten; elke app zou een module in datzelfde proces zijn, nooit een eigen dienst die naar een centrale auth-dienst belt. Alleen Postgres en de reverse proxy zouden apart blijven, omdat die geen eigen identiteitsbegrip nodig hebben.
6 augustus 2026, 19:42 tot 20:35
Rollen en de sessie zelf uitgewerkt
Eén gedeeld identiteits- en rolmodel, en een sessie als getekende JWT in plaats van een sessietabel: de handtekening plus een vervaldatum is de hele controle, zonder dat ieder verzoek de database moet raadplegen. Alleen de eenmalige inlogkoppeling zelf wordt opgezocht, vóór er een sessie bestaat.
6 augustus 2026, 20:35 tot 7 augustus 2026, 01:14
Het module-contract: hoe N apps naast elkaar blijven werken
Vastgelegd hoe routering, templates, statische bestanden en tabelnamen per module gescheiden blijven zonder onderlinge afstemming: elke module claimt bij het opstarten zijn eigen voorvoegsel, en een dubbele claim laat de container direct falen in plaats van in stilte een andere route te overschrijven.
7 augustus 2026, 01:20
Eerste echte module op het patroon
Een tweede, echte app-module bovenop dit patroon draaide voor het eerst: dezelfde inlogmethode, dezelfde rollen, geen eigen inlogscherm gebouwd. Wat voor de eerste app was ontworpen, werkte zonder aanpassing voor de tweede.
Eén architectuurkeuze voor identiteit, één keer goed vastgelegd, is goedkoper dan een auth-service bouwen die daarna voor iedere nieuwe app weer moet meebewegen.
Een aparte auth-service lost hetzelfde probleem op, maar voegt er een dienst, een netwerkaanroep en een eigen levenscyclus aan toe. Voor een klein team dat nog niet weet hoeveel apps er uiteindelijk bij komen, is dat extra gewicht dat pas later iets teruggeeft, als het al te laat is om er nog vanaf te stappen.
Door identiteit in het proces zelf te bakken, en per module alleen een vastgelegd contract af te dwingen, kost een nieuwe app geen nieuw inlogscherm, geen nieuw wachtwoordbeheer en geen eigen rolsysteem. Dat is precies het moment waarop iemand inlogt: één keer, met toegang tot alles waar die rol op recht heeft, in plaats van per app opnieuw.
Volgende stap
Zo'n verhaal, maar dan uw eigen
Weet u al hoeveel interne tools er de komende jaren nog bijkomen? Als het antwoord 'meer dan één' is, is dit precies het moment om over de architectuur ervan na te denken, niet nadat de tweede of derde er al staat.