Reaktyvi duomenų platforma
Mūsų reaktyvus BaaS ant native SpacetimeDB — ~200k realaus laiko pristatymų/s, p95<20ms.
Reaktyvi duomenų platforma
Iššūkis
Norėjome reaktyvaus backendo patogumo — gyvų užklausų, tipizuoto kliento ir serverio — bet vieno Node rantaimo lubos ~25-30k realaus laiko pristatymų/s, ir nenorėjome priklausyti nuo nuomojamo backendo.
Ką darėme
Mūsų pačių reaktyvus BaaS su native SpacetimeDB tranzakciniu/realaus laiko varikliu viduje: kompiliatorius verčia mūsų schemą ir funkcijas į STDB modulį, suderinamumo sluoksnis išlaiko tą patį kliento ir serverio API, kurį programos jau naudoja (idealas — tas pats klientas, kitas URL), o worker'is tvarko action'us ir išorinį I/O (Stripe, el. paštas, LLM, webhook'ai); poveikio paviršius įrodytai neturi produkcinės priklausomybės nuo etaloninės realizacijos, kuri lieka tik kaip diferencinio testo oraklas.
Rezultatas
Esamos programos persikelia vos pakeitus URL, ant variklio, laikančio ~200k realaus laiko pristatymų/s p95<20ms — apie 7× vienam boksui prieš seną rantaimą, be Node lubų.
Dev-story straipsnis
Kaip buvo kuriamas projektas: Reaktyvi duomenų platforma
Kiekviena mūsų programa nori to paties iš backendo: gyvų užklausų, tipizuoto kliento ir serverio funkcijų, be nuomojamo produkto viduryje. Jau turėjome reaktyvų BaaS ant vieno Node srauto, ir jis veikė — kol fanout skaičiai nustojo būti patogūs. Tai ta pati produkto realizacija iš naujo, su native SpacetimeDB varikliu viduje, pagal vieną griežtą taisyklę: programos neturi keistis.
Skyriai
05
Moduliai
05
Stackas
Rust + SpacetimeDB
Kodėl projektas atsirado
Norėjome reaktyvaus backendo patogumo — gyvų užklausų, tipizuoto kliento ir serverio — bet vieno Node rantaimo lubos ~25-30k realaus laiko pristatymų/s, ir nenorėjome priklausyti nuo nuomojamo backendo.
Kiekviena mūsų programa nori to paties iš backendo: gyvų užklausų, tipizuoto kliento ir serverio funkcijų, be nuomojamo produkto viduryje. Jau turėjome reaktyvų BaaS ant vieno Node srauto, ir jis veikė — kol fanout skaičiai nustojo būti patogūs. Tai ta pati produkto realizacija iš naujo, su native SpacetimeDB varikliu viduje, pagal vieną griežtą taisyklę: programos neturi keistis.
Ką sukūrėme
Mūsų pačių reaktyvus BaaS su native SpacetimeDB tranzakciniu/realaus laiko varikliu viduje: kompiliatorius verčia mūsų schemą ir funkcijas į STDB modulį, suderinamumo sluoksnis išlaiko tą patį kliento ir serverio API, kurį programos jau naudoja (idealas — tas pats klientas, kitas URL), o worker'is tvarko action'us ir išorinį I/O (Stripe, el. paštas, LLM, webhook'ai); poveikio paviršius įrodytai neturi produkcinės priklausomybės nuo etaloninės realizacijos, kuri lieka tik kaip diferencinio testo oraklas.
Kompiliatorius verčia mūsų schemą ir funkcijas į native SpacetimeDB modulį (Rust), tad tranzakcijos ir realus laikas sukasi tam skirtame variklyje. Suderinamumo sluoksnis iš naujo įgyvendina tą patį kliento ir serverio API, kurį programos jau kalba — idealas yra ta pati kliento biblioteka, nukreipta į kitą URL. Worker tvarko action ir išorinį I/O (Stripe, el. paštas, LLM, webhook) už tranzakcinio branduolio, o skydelis rodo schemą, duomenis ir žurnalus. Senas Node stekas lieka veikiančiu atsarginiu variantu iki įrodyto perjungimo.
Pagrindiniai moduliai ir vartotojo kelias
Perrašymo priežastis yra skaičius: senas Node rantaimas ties ~25-30k realaus laiko pristatymų/s, o native variklis laiko ~200k p95<20ms — apie 7x vienam boksui. Visas dizainas egzistuoja, kad pasiektų tas lubas neįvedus Node kamščio suderinamumo kelyje.
Nepriklausomybė laikoma tuo, ką reikia įrodyti, ne teigti: mašininis skeneris pereina kiekvieną produkcinę priklausomybę, o atskiras geitas paleidžia korpusą fiziškai pašalinus etaloninį paketą. Geitas iš pradžių raudonas — pirmoji kvitancija rodo jį krentantį prieš darbą — ir žalias tampa tik tada, kai produkcinis paviršius tikrai neimportuoja etaloninės realizacijos.
Suderinamumas tikrinamas diferencialiai: minimali etaloninė programa paleidžiama ant abiejų variklių ir išvestys palyginamos, tad etaloninė realizacija tampa testo oraklu, o ne rantaimo priklausomybe.
Provido kodekas yra mūsų pačių, ne pasiskolintas iš etaloninio paketo, tad net naršyklės klientas nustoja traukti tą paketą į produkciją — iki klaidų atpažinimo, atitinkančio oficialų elgesį pagal signalą.
Kodo generavimas ir naujos programos taiko į mūsų pačių paketus; etaloninis API lieka tik kaip suderinamumo ir oraklo paviršius. Esamos programos perkėlimas turi būti URL pakeitimas, o pariteto korpusas (16/16 ir 18/18 leidimo geituose) tai patvirtina.
Architektūra ir technologiniai sprendimai
Sukurta su Rust, SpacetimeDB, Realtime BaaS.
Rust SpacetimeDB modulis schemai ir reducer logikai; kompiliatorius iš mūsų schemos ir funkcijų į tą modulį; suderinamumo sluoksnis kliento ir serverio API; mūsų pačių provido kodekas; Node valdymo sluoksnio gateway (skydelis ir diegimas) mažo srauto operacijoms; worker action ir išoriniam I/O; ir pariteto fixtures, benchmark bei nepriklausomybės geitai CI.
Rezultatas ir pamokos
Esamos programos persikelia vos pakeitus URL, ant variklio, laikančio ~200k realaus laiko pristatymų/s p95<20ms — apie 7× vienam boksui prieš seną rantaimą, be Node lubų.
Mūsų programos gauna reaktyvų backendą, kurį valdome nuo pradžios iki galo, ant variklio, laikančio ~200k realaus laiko pristatymų/s p95<20ms, su tuo pačiu gyvų užklausų modeliu — ir perkėlimu, kuris turi būti URL pakeitimas, paremtu žaliu nepriklausomybės geitu, o ne pažadu.
Susiję straipsniai
Toliau skaityti
Susijusios projektų istorijos
Šie projektai turi artimų technologinių arba produkto sprendimų, todėl padeda matyti, kaip tas pats principas veikia kitame kontekste.
Dev-storyCMS
Dinaminis CMS ant webedge-db — turinio tipai, medija, rolės ir vieša skaitymo API, maitinanti mūsų svetaines ir straipsnius.
Dev-storyMTP-RDMA klasteris
Tensorinis 27B per du Mac'us Thunderbolt RDMA — ~70 → 90–100 tok/s.
Dev-storyKalendoriaus rezervacijų platforma
Rezervacijos ant Vue 3 — laisvi laikai, užsakymai, laiškai ir Meet vaizdo nuorodos.
Turite panašią idėją?
Aptarti projektą