Ik gebruikte AWS Cognito voor een startup. Ik zou het niet opnieuw doen.

Ik was drie dagen bezig met het instellen van de authenticatie voor onze startup toen ik merkte dat er iets mis was. Niet het soort "ik ben een puntkomma vergeten"-mis, maar meer het soort "ik heb elke stap in de documentatie gevolgd en de flow voor het resetten van het wachtwoord verwijst nog steeds naar de verkeerde plek"-mis.

Ik had de documentatie in twaalf tabbladen openstaan. Ik had de codevoorbeelden gekopieerd en geplakt. Ik had zelfs een tutorial bekeken van iemand die klonk alsof hij precies deze nachtmerrie al eens had meegemaakt.

Het punt is: ik heb eerder authenticatie geïmplementeerd. Ik heb gestreden met Auth0, Firebase Auth getemd, en ik heb zelfs zelf een custom JWT-systeem gebouwd waar ik niet trots op ben, maar dat wel werkte. Dus toen onze startup authenticatie nodig had en het team neigde naar Cognito omdat "het al in het AWS-ecosysteem zit en de eerste 50.000 maandelijks actieve gebruikers gratis zijn", dacht ik: hoe erg kan het zijn?

Ik spijt me van alles.

De documentatie was geschreven voor vijf verschillende personen tegelijk

Het lezen van de Cognito-documentatie voelt alsof iemand drie verschillende handleidingen in een blender heeft gegooid en er vervolgens wat verouderde Stack Overflow-antwoorden overheen heeft gestrooid voor de smaak.

AWS probeert te veel doelgroepen tegelijk te bedienen. Je hebt de enterprise-architect die de onderliggende identiteitsprotocollen wil begrijpen. Je hebt de frontend-ontwikkelaar die gewoon een inlogformulier wil. Je hebt de mobiele ontwikkelaar die native SDK's nodig heeft. De documentatie probeert alles voor iedereen te zijn, wat betekent dat het uiteindelijk voor niemand echt nuttig is.

Als ik zocht naar "Cognito custom attribute validation", kwam ik terecht op een pagina die begon met een paragraaf over directory-schema's, waarbij werd aangenomen dat ik al vier andere pagina's had gelezen waarvan ik niet wist dat ze bestonden. Er is geen duidelijk lineair pad. Het is gewoon een web van hyperlinks en gebeden.

En de codevoorbeelden. Oh, de codevoorbeelden. De helft is voor de oude JavaScript SDK. Sommige verwijzen naar de Amplify v1 API. Andere gebruiken de raw AWS SDK. De documentatie vertelt je niet altijd duidelijk over welke versie het gaat, waardoor je als een detective import-statements moet gaan analyseren.

De dag dat Amplify v6 me in de steek liet

Sprekend over versies: laat me je vertellen over de situatie met de JavaScript-bibliotheek, want deze had me echt overvallen.

Toen we begonnen met bouwen, was Amplify op versie 5. Ik schreef onze auth-flow, testte deze, committe de code en ging door naar andere functies. Een paar weken later kwam ik terug om een bug op te lossen en merkte ik enkele deprecation warnings in de console op. Geen probleem, dacht ik. Ik update gewoon naar de nieuwste versie.

Vrienden, Amplify v6 veranderde niet alleen een paar method-signatures. Het herstructureerde fundamenteel hoe je met Cognito communiceert. Functies waar ik volledige UI-flows omheen had gebouwd, waren weg. Vervangen. Verdwenen. De migratiegids bestond technisch gezien wel, maar het voelde meer als een schattenkaart waarvan de helft van de herkenningspunten ontbrak.

Ik heb de code herschreven. Niet gerefactord. Herschreven. Authenticatielogica die perfect werkte in productie moest opnieuw worden opgebouwd omdat de bibliotheekbeheerders hadden besloten dat de oude API niet langer de gewenste weg was. Dat is geen upgrade. Dat is een gijzelingssituatie.

Lokale ontwikkeling is een bijzonder soort pijn

Hier is een leuk feitje over Cognito: het is cloud-gebaseerd. Ik weet het, schokkend. Maar wat dat praktisch betekent, is dat je niet zomaar een lokale instantie kunt opstarten om je auth-flows offline te testen. Je raakt altijd daadwerkelijke AWS-endpoints aan.

Er zijn tools zoals de serverless-offline plugin en lokale Cognito-emulatoren die dit gat proberen te dichten, maar dat zijn community-projecten met variërende niveaus van onderhoud en nauwkeurigheid. Het officiële advies van AWS is in feite "test tegen de cloud", wat geweldig advies is, tenzij je in een vliegtuig zit, je internet haperig is, of je gewoon snelle iteratiecycli wilt zonder te wachten op netwerkverzoeken.

Ik heb een beschamende hoeveelheid tijd besteed aan het opzetten van een lokale mock die niet helemaal overeenkwam met het echte werk, wat betekende dat bugs lokaal onopgemerkt bleven en pas in staging verschenen. Het hele punt van lokale ontwikkeling is om problemen vroegtijdig te signaleren, en Cognito werkt daar actief tegenin.

Je wilt aanpassingen? Het beste dat ik kan bieden is een logo

Deze stak echt.

De hosted UI die Cognito biedt is functioneel. Hij is er. Hij werkt, grotendeels. Maar als je wilt dat het eruitziet als jouw merk en niet als een AWS-service in een kostuum, dan ga je een nare tijd tegemoet.

Je kunt het logo wijzigen. Je kunt wat CSS aanpassen via de console. Maar de layout, de structuur, het algemene gevoel? Dat is het huis van AWS, en jij huurt daar slechts een kamer. Als je iets nodig hebt buiten de basisaanpassingen, is het advies van de community meestal: "bouw je eigen UI met de SDK". Prima, dat begrijp ik. Maar op dat moment, wat bespaart de hosted UI mij dan precies?

De configuratie voor alleen e-mail die mijn geest brak

Laat me je vertellen over het moment dat ik mijn laptop bijna uit het raam gooide.

Onze app had alleen e-mailauthenticatie nodig. Geen gebruikersnamen. Gebruikers melden zich aan met een e-mailadres, verifiëren dit, stellen een wachtwoord in, en klaar. Simpel concept, toch?

Dus ging ik naar de Cognito user pool-instellingen en configureerde ik deze om e-mailadressen als sign-in identifier te gebruiken. Ik stelde de attribute mappings in. Ik maakte de sign-up flow. Alles leek in orde, totdat ik besefte dat Cognito "e-mail" anders behandelt, afhankelijk van of het een kernattribuut, een alias of een custom attribuut is. De configuratie-opties zijn verspreid over meerdere schermen in de console, met onderlinge afhankelijkheden die nooit volledig worden uitgelegd.

Ik maakte een fout in de initiële setup. Een kleine. Ik had iets geconfigureerd als een custom attribuut dat een standaardattribuut had moeten zijn. Geen probleem, dacht ik. Ik pas het gewoon aan.

Dat kun je niet aanpassen.

Zodra een user pool-attribuut is aangemaakt als custom, is het voor altijd custom. En als je authenticatieschema afhangt van de relatie tussen bepaalde attributen, en je krijgt die relatie fout, dan zijn je opties ongeveer: verwijder de hele user pool en begin opnieuw, of bouw een uitgebreid migratieproces dat gebruikers verplaatst naar een nieuwe pool met de juiste configuratie.

Voor een productie-app met actieve gebruikers is "gewoon verwijderen" geen echte optie. Dus zit je nu gebruikersmigraties te scripten, wachtwoordresets in de nieuwe pool af te handelen en je te verontschuldigen bij je gebruikers voor het ongemak. Alles omdat een dropdown-menu in een console net iets te ambigu was.

Wat ik echt heb geleerd

Ik wil niet alleen klagen. Dat is makkelijk. Maar ik wil wel eerlijk zijn over wat deze ervaring me heeft geleerd, want ik denk dat er iets nuttigs in zit buiten "Cognito is slecht".

Authenticatie is niet de plek om bochten af te snijden. Het argument "het zit al in het ecosysteem" is verleidelijk, maar ecosystem-nabijheid doet er niet toe als de tool je ongelukkig maakt elke keer dat je hem aanraakt. De gratis laag in de prijsstelling is aantrekkelijk totdat je de engineering-uren berekent die zijn besteed aan het vechten met de documentatie en het herschrijven van code vanwege breaking API-wijzigingen.

De volgende keer kies ik een tool op basis van de developer experience eerst, niet op basis van het gemak van AWS-service-integratie. De tijd die we verloren zijn met het debuggen van Cognito-problemen, had betaald kunnen worden voor meerdere jaren van een betaalde auth-provider. En we hadden sneller kunnen releasen, met minder koude pizza's die om middernacht werden gegeten.

Als je dit leest omdat je Cognito momenteel overweegt voor je project, ga ik je niet vertellen wat je moet doen. Maar ik zal dit zeggen: bouw eerst een kleine proof of concept. Iets dat niet triviaal is. Iets met custom attributen, e-mailverificatie en een flow voor het resetten van wachtwoorden. Kijk hoe het voelt. Houd de tijd bij. Tel hoeveel documentatie-tabbladen je aan het einde open hebt staan.

Als dat aantal boven de twintig ligt, overweeg het dan misschien opnieuw.

Ik gebruik overigens nog steeds Cognito voor dit project. We zijn te ver gegaan om het er nu nog uit te slopen. Maar elke keer als ik de AWS-console open en die user pool zie staan, voel ik een kleine, stille wrok. Als een oude huisgenoot die nooit de afwas doet en constant je spullen "leent".

Je kent het gevoel.