Divi atsevišķi projekti šovasar dara vienu un to pašu: paņem Zod shēmu, ko TypeScript izstrādātāji jau raksta, un pārvērš to par gatavu validācijas funkciju vēl pirms koda palaišanas. Rezultāts uz lieliem objektiem — līdz 73 reizēm ātrāka pārbaude, bez nevienas rindas izmaiņu pašā kodā.
Pirmais ir gajus/zod-compiler, otrais — wakita181009/zod-aot. Abi ir spraudņi būvēšanas rīkiem, un abi atrisina to pašu problēmu: Zod validē lēni, jo dara to nepareizajā brīdī.
Kāpēc Zod ir lēns
Kad tu izsauc schema.parse(data), Zod izstaigā visu shēmas koku no jauna — mezglu pa mezglam, ar dispečeru katram tipam un ar pagaidu objektiem katrā solī. To pašu darbu tas atkārto pie katra izsaukuma, kaut arī shēmas forma nemainās. LogRocket analīzē parādīts, ka tieši šī koka staigāšana izpildes laikā ir galvenais bremzes iemesls, un Zod v4 pārrakstīšana to samazināja, bet neizskauda.
Kompilators to apiet vienkārši. Shēmas forma ir zināma jau tad, kad tu to raksti, tāpēc spraudnis to nolasa vienu reizi būvēšanas laikā un izvada precīzu validatoru — bez koka, bez dispečera, bez pagaidu objektiem katram mezglam.
Skaitļi
gajus/zod-compiler README dod šādus mērījumus salīdzinājumā ar Zod v4:
- vienkārša virkne: 1,1× ātrāk;
- vidējs objekts ar derīgiem datiem: 4,3× ātrāk;
- liels objekts ar 100 elementiem: 73× ātrāk;
- rekursīvs koks ar 121 mezglu: 16× ātrāk;
- ligzdota rekursija ar 121 mezglu: 33× ātrāk.
Redzams, ka ieguvums aug līdz ar datu apjomu. Uz vienas virknes starpība ir mērāma, bet niecīga; uz liela objekta tā kļūst tāda, ka to jūt lietotājs.
zod-aot autors publicēja piecu rīku salīdzinājumu ar operāciju skaitu sekundē. Vidējam objektam ar derīgiem datiem Zod v3 sasniedza 1,3 miljonus, Zod v4 — 1,7 miljonus, zod-aot — 5,2 miljonus, Typia — 7,0 miljonus, AJV — 4,8 miljonus. Uz liela objekta ar 100 elementiem plaisa paplašinās: Zod v4 dod 11 600 operāciju, zod-aot — 627 000, Typia — 808 000, bet AJV nokrīt līdz 89 000.
Kur Zod tagad apsteidz konkurentus
Typia joprojām ir mazliet ātrāka par kompilēto Zod uz parastiem objektiem, aptuveni pusotru reizi. Toties zod-aot mērījumos kompilētais Zod pārbauda JavaScript Set un Map tipus, ko Typia un AJV neatbalsta. Kopas ar 20 elementiem validācija Zod v4 deva 461 000 operāciju; kompilētā versija — 7,6 miljonus. Tas ir 16 līdz 22 reizes vairāk nekā bāzes Zod, un šis tips citiem rīkiem vienkārši nav pieejams.
AJV savukārt paliek stiprs pie kļūdu vākšanas, kad datu ir daudz un tie ir nederīgi. Tāpēc izvēle nav vienpusēja — tā ir atkarīga no tā, vai tavi objekti parasti iztur validāciju vai krīt.
Shēmas forma ir zināma jau tad, kad tu to raksti. Kompilators to nolasa vienu reizi un izvada tieši to validatoru, kas vajadzīgs — nekas cits izpildes laikā vairs nav jādara.
Kā tie iekļaujas darbā
Galvenais solis ir tas, ka koda maiņa nav vajadzīga. gajus/zod-compiler noklusējuma režīmā pats atrod visas eksportētās Zod shēmas un tās kompilē; ja gribi kontrolēt precīzāk, konkrētu shēmu var ietīt funkcijā compile(), vai arī ģenerēt failus no komandrindas bez būvēšanas rīka vispār. Spraudņi ir Vite, webpack, esbuild, SWC, Rollup, Rolldown, rspack, Bun un Farm.
zod-aot iet cauri četriem soļiem. Vispirms regulārā izteiksme atsijā failus, kuros Zod tiek importēts izpildei, nevis tikai kā tips. Tad spraudnis ielādē avotu un atrod objektus ar iekšējo _zod.def struktūru, kas iezīmē shēmu. Pēc tam shēma tiek kompilēta par ievietotu validācijas kodu, un caur AST tā tiek aizvietota, izmantojot Object.create(), lai saglabātu pilnu Zod API.
Abi rīki lieto divfāžu validatoru. Derīgiem datiem izpildās ātrā fāze — būla izteiksmju virkne bez atmiņas piešķiršanas. Ja pārbaude krīt, tikai tad ieslēdzas lēnākā fāze, kas vāc kļūdas. Aprēķins ir uz to, ka lielākā daļa datu praksē iztur validāciju, tāpēc ātrā ceļa optimizēšana atmaksājas biežāk.
Kur tie atkāpjas
gajus/zod-compiler dokumentācija nosauc konkrētas robežas. Ja shēmā ir atzvana funkcija, kas ķer mainīgo no ārpuses, kompilators atkāpjas uz parasto Zod. Nezināmās atslēgas pēc noklusējuma paliek izvadē, kaut arī to izmešanu var ieslēgt. Un ieraksti (records) izlaiž simbolu atslēgas un neuzskaitāmās atslēgas.
Neviens no projektiem nav Zod komandas oficiāls rīks. Zod glabātuvē diskusija par iebūvētu iepriekš kompilētu validāciju sākās jau 2024. gadā (discussion #3125), bet tā palika neatrisināta, un abi šie spraudņi ir kopienas atbilde uz to, kamēr oficiāla risinājuma nav.
Praktiskā izvēle ir šaura: ja projekts jau lieto Zod un validē lielus objektus karstajā ceļā, spraudnis dod lielāko daļu no Typia ātruma, neprasot pārrakstīt shēmas citā bibliotēkā. Vienas virknes vai maza objekta gadījumā starpība nav tā vērta, lai pievienotu būvēšanas soli.
Komentāri
Šim rakstam vēl nav komentāru. Esi pirmais, kurš dalās ar savu viedokli.