Salutare tuturor! Ne batem capul la birou cu o problemă de performanță pe serverless și am nevoie de niște feedback real de la cineva care s-a mai lovit de asta. Avem un API cu peste 50 de scheme de validare scrise în Zod și ne gândim serios să migrăm spre Valibot pentru a reduce cold start-urile.
Contextul e simplu. Rulăm vreo 15 microservicii pe AWS Lambda cu Node.js. Fiecare endpoint are schema lui de validare pentru request body și query params. Zod e minunat ca API, îl folosim de ani de zile și din punct de vedere al tipurilor de TypeScript este extrem de solid. Totul e frumos până când te uiți la dimensiunea bundle-ului final.
Problema cu Zod pe serverless
Am observat recent că unele funcții Lambda simple, care ar trebui să fie extrem de rapide, au un cold start de peste 1.2 secunde. Analizând build-ul cu un analyzer de Webpack/esbuild, am văzut că Zod trage după el aproape 60KB (minified, nu gzipped) în fiecare funcție. Deoarece Zod folosește o abordare bazată pe chaining (z.string().email().min(5)), esbuild nu poate face tree-shaking eficient. Importi o singură metodă, importi practic toată biblioteca.
La un proiect cu peste 8.000 de utilizatori activi simultan, aceste secunde pierdute la cold start se adună și devin vizibile în API Gateway.
Alternativa numită Valibot
Am făcut un test rapid săptămâna trecută pe un endpoint izolat. Am rescris schema folosind Valibot, care folosește o abordare funcțională (pipe-based): string([email(), minLength(5)]).
Rezultatul? Bundle size-ul acelei funcții specifice a scăzut cu aproape 40%. Valibot importă doar funcțiile de care are nevoie, iar tree-shaking-ul funcționează perfect. Cold start-ul acelei Lambda a scăzut sub 600ms, ceea ce e o îmbunătățire uriașă pentru noi.
Sincer, unde apare buba (Trade-offs)
Deși pe hârtie sună extraordinar, am început să fac o estimare pentru migrarea tuturor celor 50+ scheme existente și m-am cam blocat. Trade-off-ul este evident: pierdem enorm la capitolul DX (Developer Experience) și lizibilitate.
Sintaxa din Valibot e mult mai greu de citit când ai scheme imbricate adânc, cu obiecte în obiecte și array-uri complexe. Devine o pădure de paranteze rotunde greu de urmărit.
În plus, am dat deja peste câteva probleme:
- Avem niște scheme destul de complexe cu discriminators (
z.discriminatedUnion) și transformări asincrone. Rescrierea lor în Valibot pare destul de anevoioasă și codul rezultat e mult mai verbos. - Ecosistemul din jur e încă fragil. Noi folosim generatoare automate de OpenAPI bazate pe schemele Zod. Pentru Valibot, librăriile de integrare sunt destul de noi și par netestate în producție la scară largă.
Am pierdut deja vreo 4 ore încercând să traduc o singură schemă mare de checkout și tot nu am terminat-o din cauza unor erori ciudate de TypeScript.
Întrebarea mea pentru comunitate
A mai trecut cineva prin procesul ăsta de migrare de la Zod la Valibot pe un codebase de producție mediu sau mare?
Merită efortul de rescriere a celor 50 de scheme pentru câteva sute de milisecunde salvate la cold start, sau mai bine încercăm să optimizăm altceva (poate mutăm funcțiile pe servere clasice sau folosim provisioned concurrency, deși asta ne costă bani)? Cum ați gestionat diferențele de sintaxă și lipsa unor unelte mature în ecosistem?