„JavaScript“ galima naudoti geresnę srautų API

JavaScript Streams API turi problemų – ir kūrėjai pagaliau apie tai kalba

Jei kada nors bandėte naudoti Srautų API „JavaScript“ bet kam, išskyrus vadovėlį, pajutote trintį. Tai, kas turėtų būti elegantiška, sukomponuojama abstrakcija, skirta nuosekliems duomenims tvarkyti – failų skaitymui, HTTP atsakymų apdorojimui, duomenų rinkinių transformavimui realiuoju laiku – dažnai perauga į išsamią formulę, painiojančią priešslėgio semantiką ir API paviršių, kuris labiau primena įmonės „Java“ nei šiuolaikinį „JavaScript“. Pokalbis apie geresnio srautinio perdavimo primityvo kūrimą jau daugelį metų virė TC39 pasiūlymuose, diskusijose ir atvirojo kodo projektuose. 2026 m. jis pasiekia lūžio tašką. Klausimas ne tas, ar įmanoma geresnė srautų API, o kaip iš tikrųjų atrodo „geresnė“ ir kas mus sulaiko.

Kur sutrinka esamų srautų API

WHATWG Streams standartas, suteikiantis galimybę naudoti ReadableStream, WritableStream ir TransformStream naršyklėse ir vykdymo laikus, pvz., Node.js ir Deno, buvo tikras inžinerijos pasiekimas. Tai sukėlė atgalinį spaudimą, atšaukimą ir asinchroninę iteraciją žiniatinklio vietiniam duomenų tvarkymui. Tačiau praktiškai API per daug prašo kūrėjo už įprastas operacijas. Norint sukurti paprastą transformavimo srautą, reikia paleisti TransformStream naudojant transformavimo metodą, valdyti valdiklius ir atidžiai tvarkyti praskiedimo semantiką – visa tai reiškia map() per dalis.

Palyginkite tai su tuo, kaip kūrėjai dirba su masyvais. Array.prototype.map(), filter() ir reduce() yra sudaryti, skaitomi ir nereikalauja beveik jokios ceremonijos. „Streams“ API nesiūlo tokio ergonomiško komponavimo iš karto. Srautų sujungimas naudojant .pipeThrough() veikia, tačiau patys transformavimo etapai kūrėjai praranda valandas ir kantrybę. Klaidų apdorojimas vamzdžių grandinėse yra dar vienas skaudus taškas – klaidos neplinta intuityviai, o nutrūkusio konvejerio derinimas dažnai reiškia laikinų registravimo transformacijų įterpimą, kad išsiaiškintumėte, kur duomenys numetami arba sugadinami.

Kambaryje taip pat yra Node.js dramblys. Mazgas turi savo pasenusią srauto diegimą (stream.Readable, stream.Writable), kuris beveik dešimčia metų senesnis nei WHATWG standartas. Abi sistemos yra suderinamos tik per adapterio paslaugas, o daugelis npm paketų vis dar naudoja senesnę API. Kūrėjai, dirbantys įvairiose aplinkose – serverio pusės atvaizdavimo, kraštinių funkcijų, naršyklėje pagrįsto apdorojimo – yra priversti žongliruoti dviem nesuderinamomis abstrakcijomis tai pačiai koncepcijai.

Kaip galėtų atrodyti geresnis srautų API

Keli pasiūlymai ir bendruomenės eksperimentai rodo kūrėjams palankesnę ateitį. Pagrindinės idėjos sutampa remiantis keliais principais: funkcinė kompozicija, asinchroninis iteratoriaus lygiavimas ir sumažintas keitiklis. Įsivaizduokite, kad galite rašyti srautinius duomenų konvejerius taip pat natūraliai, kaip rašote masyvo transformacijas – grandininį .map(), .filter() ir .take() tiesiogiai skaitomame sraute, nekuriant tarpinių „TransformStream“ objektų.

Tai nėra hipotetinė. Pasiūlymas Iteratoriaus pagalbininkai (dabar 4 etape TC39) jau suteikia .map(), .filter(), .take(), .drop() ir .flatMap() sinchronizatoriams. Šio modelio išplėtimas iki asinchronizuojamų iteratorių – o kartu ir skaitomiems srautams, atskleidžiantiems [Symbol.asyncIterator] – yra natūralus kitas žingsnis. Kai kurios vykdymo programos ir bibliotekos jau pradėjo eksperimentuoti su šiuo metodu, todėl kūrėjai gali rašyti tokį kodą kaip:

Galingiausia srautinio perdavimo abstrakcija yra ta, kuri išnyksta. Kai kūrėjai gali išreikšti duomenų transformacijas kaip paprastų funkcijų grandinę – nesijaudindami dėl valdiklių, eilių strategijų ar rankinio priešslėgio – jie sukuria greičiau, siunčia mažiau klaidų ir iš tikrųjų mėgaujasi darbu su duomenų srautu.

Tikslas nėra visiškai pakeisti žemo lygio srautų API. Visada bus naudojimo atvejų – pasirinktiniai protokolai, smulkus atminties valdymas, dvejetainių kodekų diegimas – kai būtina tiesioginė valdiklio prieiga. Tačiau 90 % naudojimo atvejų, kai reikia skaityti, transformuoti ir rašyti nuoseklius duomenis, abstrakcijos sluoksnis turi atitikti užduoties paprastumą.

Kitų ekosistemų pamokos

JavaScript nėra pirmoji kalba, kuri kovoja su srautinio perdavimo ergonomika. Rust funkcijos Iteratorius ir Srautas siūlo komponuojamą, nieko nekainuojančią abstrakciją, leidžiančią kūrėjams sujungti operacijas neskiriant tarpinių kolekcijų. „Elixir“ modulis Srautas pateikia atsainį surašymą su aiškia, patogia sintaksė. Net „Java“, dažnai kritikuojama dėl daugiažodiškumo, „Java 8“ versijoje pristatė java.util.stream.Stream su sklandžia API, kurią „JavaScript“ kūrėjai atpažintų ir pavydėtų.

Šioms ekosistemoms būdingas įsipareigojimas padaryti bendrą atvejį nereikšmingu. Failo skaitymas, eilučių filtravimas ir rezultatų rašymas užima 3–5 sukomponuojamo kodo eilutes. Dabartinėje „JavaScript“ srautų API ta pati operacija gali lengvai išplėsti iki 20–30 eilučių, kai atsižvelgsite į srauto kūrimą, klaidų tvarkymą ir tinkamą išardymą. Skirtumas susijęs ne su galimybėmis, o su ergonomika.

Python požiūris taip pat yra pamokantis. Generatoriaus funkcijos su yield suteikia natūralų būdą atsainiai gaminti ir vartoti nuoseklius duomenis. „JavaScript“ taip pat turi generatoriaus funkcijų, tačiau norint jas sujungti su „Streams“ API, reikia jas apvynioti ReadableStream konstruktoriais su ištraukiamaisiais valdikliais. Griežtesnė generatorių ir srautų integracija, kai generatoriaus funkcija galėtų tiesiogiai tapti skaitomu srautu, pašalintų visą kategoriją.

Realus poveikis programų kūrimui

Tai nėra akademinis rūpestis. Srautinis duomenų perdavimas yra šiuolaikinių žiniatinklio programų esmė. Serverio siunčiami įvykiai, suskirstyti HTTP atsakymai, realiojo laiko analizės prietaisų skydeliai, failų įkėlimo apdorojimas, AI modelio išvesties srautinis perdavimas – tai kasdienės funkcijos, o ne paprasti atvejai. Kai srautinio perdavimo primityvus sunku naudoti, kūrėjai arba visiškai jo vengia (viską buferizuoja į atmintį, kurios mastelis nesikeičia), arba kuria trapius, sunkiai prižiūrimus vamzdynus, kurie tampa gamybos incidentų šaltiniu.

Apsvarstykite, kas vyksta dideliu mastu. Tokios platformos kaip Mewayz, kuri apdoroja duomenis 207 integruotuose verslo moduliuose – nuo ​​CRM vamzdynų ir sąskaitų faktūrų išrašymo iki darbo užmokesčio skaičiavimų ir transporto parko stebėjimo – viduje apdoroja didžiulius nuoseklių duomenų kiekius. Eksporto operacijos, ataskaitų generavimas, „Webhook“ įvykių apdorojimas ir realiojo laiko prietaisų skydelio naujinimai yra naudingi efektyviam srautiniam perdavimui. Kai dėl pagrindinių kalbos primityvų sunku perduoti srautą, kiekvieno modulio ir kiekvieno duomenų srauto kaina padaugėja. Platformos inžinieriai galiausiai sukuria vidines srautinio perdavimo abstrakcijas, o ne kalbos abstrakcijas, taip padidindami sudėtingumą, kuris neturėtų būti būtinas.

• Failų apdorojimas: norint įkelti ir analizuoti CSV failus, kuriuose yra daugiau nei 100 000 eilučių, reikalingas srautinis perdavimas, kad būtų išvengta atminties išeikvojimo, tačiau dabartinė API daro net paprastą transformavimą eilutę po eilutę žodingą.
• Realiojo laiko prietaisų skydeliai: analizės duomenų srautinis perdavimas iš serverio į klientą per SSE arba WebSocket yra naudingas dėl sudėtingų transformacijų (sujungimo, filtravimo, ribojimo), kurias šiandien sunku išreikšti.
• AI atsako srautinis perdavimas: LLM pagrįstoms funkcijoms tampant standartinėmis verslo įrankiuose, atsakymų siuntimas po žetonu į vartotojo sąsają yra pagrindinis lūkestis – ir puikus atvejis grandininio srauto transformavimui.
• Paketinės operacijos: apdorojant tūkstančių darbuotojų darbo užmokestį, generuojant masines sąskaitas faktūras arba sinchronizuojant CRM įrašus su išorinėmis sistemomis, visa tai apima duomenų srautinį perdavimą patvirtinimo, transformavimo ir išvesties etapais.
• „Webhook“ konvejeriai: gaunamų „Webhook“ įvykių iš trečiųjų šalių integracijų priėmimas, patvirtinimas, nukreipimas ir apdorojimas iš esmės yra srautinio perdavimo darbo krūvis.

Kas iš tikrųjų siūloma

JavaScript ekosistema juda keliais frontais. TC39 Iteratoriaus pagalbininkų pasiūlymas jau pateiktas, todėl sinchroniniams iteratoriams suteikiama funkcinė kompozicija. Natūralus plėtinys – Async Iterator Helpers – suteiktų tuos pačius .map(), .filter(), .reduce(), .take() ir .flatMap() metodus asinchronizuojamiems srautų iteratoriams, kurie jau skaito per skaitomus srautus. [Symbol.asyncIterator]. Vien tai labai pagerintų kūrėjų patirtį naudojant dažniausiai naudojamus srautinio perdavimo modelius.

Be TC39, vykdymo laiko naujovės taip pat stumia ribas. Deno eksperimentavo su ergonomiškesnėmis srauto programomis. Žiniatinklio srautų įrankių dėžutė ir panašios bendruomenės bibliotekos teikia pagalbines funkcijas, kurios apvynioja išsamias API dalis. Ir vis labiau įsibėgėja idėja apie savąją srauto standartinę biblioteką – integruotų optimizuotų paslaugų rinkinį, skirtą įprastoms srautinio perdavimo operacijoms, pvz., linijų skaidymui, JSON analizei, CSV apdorojimui ir glaudinimui, kurį kūrėjai šiuo metu renka iš npm.

Taip pat yra įtikinamas argumentas už geresnę klaidų semantiką. Šiuolaikinėje API dėl vamzdžių grandinės klaidos srautai gali būti dviprasmiškos – iš dalies sunaudoti, o skaitytuvuose kabo užraktai. Peržiūrėta API gali pritaikyti struktūrizuotą klaidų plitimą, panašų į Rust Rezultato tipą, arba taikyti susitarimą, pagal kurį klaidos teka per dujotiekį kaip vertės, leidžiančios tolesniems etapams jas tvarkyti arba ištaisyti nenutraukiant visos grandinės. Tai pakeistų gamybos patikimumą.

Kodėl tai svarbiau nei bet kada 2026 m.

Dėl trijų susiliejančių tendencijų srautinio perdavimo API ergonomika dabar yra svarbesnė nei bet kada „JavaScript“ istorijoje. Pirma, kraštų skaičiavimas – „Cloudflare Workers“, „Vercel Edge Functions“, „Deno Deploy“ – veikia laikantis griežtų atminties ir procesoriaus apribojimų, kai visų atsakymų ar duomenų rinkinių buferizavimas tiesiog nėra naudingas. Srautas yra vienintelė galimybė, o šiose aplinkose diegiantiems kūrėjams reikia API, kuri su jomis nesusidorotų.

Antra, dėl AI integravimo srautinis perdavimas tapo naudotojams skirta funkcija. Kai AI asistentas generuoja atsakymą, vartotojai tikisi, kad žetonai bus rodomi realiuoju laiku, o ne lauks viso atsakymo į buferį. Kiekvienai „SaaS“ platformai – nuo ​​verslo operacinių sistemų, tokių kaip „Mewayz“ iki atskirų AI įrankių, dabar reikia patikimo srauto vartojimo iš kliento pusės. Dabartinė API tinka šiam tikslui, tačiau kūrėjo patirtis analizuojant, transformuojant ir teikiant srautinę AI išvestį gali būti žymiai geresnė naudojant komponuojamus srauto operatorius.

Trečia, visos krūvos „JavaScript“ judėjimas reiškia, kad kūrėjai tvarko srautus abiejose tinklo ribos pusėse. Vienas inžinierius gali parašyti serverio srautą, kuris apdoroja duomenų bazės užklausų rezultatus, perduoda juos per transformaciją, nusiunčia juos kaip suskirstytą HTTP atsakymą ir tada naudoja tą patį srautą kliente, kad pateiktų progresyvią vartotojo sąsają. Kai srautinio perdavimo API yra nepatogu, ta trintis jaučiama kiekviename krūvos sluoksnyje.

Judėjimas į priekį: ką kūrėjai gali padaryti šiandien

Kol kalba vystosi, kūrėjai neužstringa laukdami. Kelios praktinės strategijos gali pagerinti dabartinių projektų srautinio perdavimo patirtį. Naudojant asinchroninius generatorius kaip pagrindinį kūrimo šabloną ir supakavus juos į ReadableStream.from(), kur vykdymo laikas tai palaiko, gaunama daug aiškesnė sintaksė nei valdiklio valdymas rankiniu būdu. Bibliotekos, pvz., it-pipe ir streaming-iterables, siūlo komponuojamus pagalbininkus, kurie šiandien suteikia funkcinį grandininį ryšį su asinchroniniais iteratoriais.

Komandoms, kurinčioms daug duomenų reikalaujančias programas, investicijos į ploną vidinį srautinio perdavimo paslaugų sluoksnį atsiperka. Gerai suplanuotas streamMap(), streamFilter() ir streamBatch() funkcijų rinkinys, kurių kiekviena atlieka asinchronizuotą iteraciją ir grąžina asinchroninį iteraciją, suteikia komponavimo galimybę, kurios trūksta standartinei API, be visos srautinio perdavimo sistemos svorio. Tai yra modelis, kuris keičiasi nuo paleisties prototipų iki platformų, atliekančių milijonus operacijų.

1. Priimkite asinchroninius generatorius kaip numatytąjį srautinio perdavimo duomenų kūrimo šabloną – jie yra švaresni, lengviau išbandomi ir lengviau komponuojami nei neautomatinis ReadableStream kūrimas
2. Naudokite ReadableStream.from(), kad sujungtumėte asinchronines iteracijas į žiniatinklio srautų pasaulį, kai reikia sąveikos su API, kurios tikisi ReadableStream egzempliorių
3. Sukurkite arba pritaikykite plonas paslaugų funkcijas, kad galėtumėte atlikti įprastas operacijas (žemėlapis, filtras, paketas, droselis) per asinchronizuotą iteraciją, o ne kurdami TransformStream objektus.
4. Advocate TC39 ir vykdymo metu vykstančiose diskusijose – asinchroninio iteratoriaus pagalbinių pasiūlymų pasiūlymui reikia kūrėjų balsų, skatinančių nustatyti prioritetus
5. Rašykite bandymus su asinchronizuotomis iteracijomis, o ne tiesiogiai srautais – dėl to srautinio perdavimo logika bus nešiojama ir lengviau patvirtinama

JavaScript Streams API buvo būtinas pagrindas. Tačiau pamatai yra skirti statyti, o kitas abstrakcijos sluoksnis, dėl kurio srautas tampa toks pat natūralus, kaip ir darbas su masyvais, yra pavėluotas. Dalys yra savo vietose: asinchroniniai iteratoriai, generatoriaus funkcijos ir iteratoriaus pagalbininkų modelis. Dabar reikia kolektyvinės valios juos surinkti į standartą, atitinkantį tai, kaip kūrėjai iš tikrųjų galvoja apie nuoseklius duomenis. Rezultatas bus ne tik geresnė API – ji atrakins srautinį perdavimą kaip numatytąjį šabloną, o ne paskutinę priemonę, todėl programos bus greitesnės, efektyvesnės atminties ir maloniau kurti.

Dažniausiai užduodami klausimai

Kas negerai su dabartine „JavaScript Streams“ API?

Dabartinė „Streams“ API kenčia nuo pernelyg didelio sudėjimo, paini priešslėgio semantikos ir pernelyg sudėtingo API paviršiaus, kuris neskatina jos naudoti. Paprastoms užduotims, tokioms kaip failo skaitymas arba HTTP atsako apdorojimas, reikia daug daugiau kodo nei reikia. Kūrėjai dažnai naudojasi trečiųjų šalių bibliotekomis arba senesniais modeliais, pvz., atgalinių skambučių ir įvykių skleidėjais, visiškai aplenkdami standartą, nes ergonomika atrodo artimesnė įmonės „Java“ nei šiuolaikinei „JavaScript“.

Kaip geresnė Streams API pagerintų žiniatinklio kūrimą?

Pertvarkyta Streams API su švaresne sintaksė, integruotu asinchronizavimo iteracijos palaikymu ir intuityviais komponavimo metodais labai supaprastintų duomenų apdorojimą realiuoju laiku. Kūrėjai galėtų natūraliai sujungti transformacijas, skaidriai tvarkyti priešslėgį ir įrašyti srautinius konvejerius į dalį kodo. Taip progresyvus atvaizdavimas, tiesioginiai duomenų sklaidos kanalai ir didelis failų apdorojimas būtų prieinamas kiekvienam „JavaScript“ kūrėjui, o ne tik tiems, kurie nori kovoti su žemo lygio primityvais.

Ar šiuolaikinės verslo platformos gali veiksmingai valdyti duomenų srautinį perdavimą realiuoju laiku?

Taip – tokiose platformose kaip Mewayz, 207 modulių verslo OS, kainuojanti nuo 19 USD per mėnesį, jau dabar naudojami efektyvūs duomenų srautai, skirti analizei, automatizavimo darbo eigoms ir tiesioginėms ataskaitoms teikti. Tobulėjant „JavaScript“ srautinio perdavimo standartams, žiniatinklio rinkinyje sukurti įrankiai suteiks dar greitesnę patirtį realiuoju laiku – nuo momentinių prietaisų skydelio atnaujinimų iki sklandaus failų apdorojimo integruotuose verslo moduliuose.

Kokios alternatyvos egzistuoja tol, kol „Streams“ API vystosi?

Kūrėjai šiuo metu naudojasi tokiomis bibliotekomis kaip Node.js srautai, RxJS reaktyviam programavimui arba asinchroniniai generatoriai, suporuoti su laukimo kilpomis, kad ergonomiškiau tvarkytų nuoseklius duomenis. Su žiniatinkliu suderinami daugiasluoksniai užpildai ir pasiūlymo etapo pagalbininkai taip pat užpildo standartinės API spragas. Svarbiausia yra pasirinkti abstrakcijas, atitinkančias jūsų naudojimo atvejį – nesvarbu, ar tai reikštų pastebimus modelius daug įvykių turinčioms programoms, ar paprastą asinchronizavimo iteraciją atliekant nesudėtingas duomenų transformavimo užduotis.