Visi projektai

Reaktyvi duomenų platforma

Mūsų reaktyvus BaaS ant native SpacetimeDB — ~200k realaus laiko pristatymų/s, p95<20ms.

RustSpacetimeDBRealtime BaaS
01

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.

02

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.

03

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

01

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.

02

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.

03

Pagrindiniai moduliai ir vartotojo kelias

M01

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.

M02

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.

M03

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.

M04

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ą.

M05

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.

04

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.

05

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.

Toliau skaityti

Šie projektai turi artimų technologinių arba produkto sprendimų, todėl padeda matyti, kaip tas pats principas veikia kitame kontekste.

Turite panašią idėją?

Aptarti projektą