A Rust-TypeScript integration
44 comments
·July 4, 2025mootoday
aporiador
I use https://github.com/1Password/typeshare it has it's quirks, but works nicely
agnishom
I use aeson-typescript but it is broken in subtle ways
brainless
I have been using https://github.com/Aleph-Alpha/ts-rs to generate TypeScript types from Rust for quite a while now. Very happy and it has a lot of good impact when doing large refactor to the API. Claude Code also selected this automatically for a full-stack app I was experimenting.
graup
Was hoping this was about WebAssembly/WASM. You used to be able to import rust directly into your JS with Parcel, but sadly that feature was dropped in Parcel 2. Is there a simple pipeline for compiling and typesafe binding of Rust-WASM?
kasbah
It's pretty straight forward to include the output of `wasm-pack` into a vite project. The output is a node module in a folder with the wasm files and a single "main" JS file.
Because I wanted to load WASM in a web worker for my project [1] I needed to use vite-plugin-wasm and `wasm-pack build --target web` but without that constraint you should be able to import the main JS file from the wasm-pack output directory using wasm-pack's default `bundler` target and no vite plugins.
diggan
I'm literally building a project right now that executes compiled WASM Components, theoretically written in any language but right now I'm using Rust for both parts (the "runner" and the WASM Components).
But, I did a brief exploration to see how I could compile those WASM Components in any language (including JavaScript), and as far as I can tell, if you could use ComponentizeJS + jco for compiling JavaScript to WASM Components, and if you need to run them in JavaScript too, StarlingMonkey seems to be able to handle that.
I'm not sure about the last part, typesafe bindings would require you to use TypeScript or similar, not just JavaScript. I don't use TypeScript myself so I don't know if the approach above would give you any type safety on the Component-implementation side.
paddy_m
I have a project that has a python backend and react typescript frontend. Both are typed. How do you all handle resolving types between two systems like that. Ideally I'd like to be able to write types in typescript, and write python types, then verify that the types are compatible (not identical). I frequently frontend side features that add new keys to dicts, and fill in python support later.
vaylian
> Ideally I'd like to be able to write types in typescript, and write python types, then verify that the types are compatible (not identical)
Have a look at https://fastapi.tiangolo.com/
FastAPI allows you to define your types in Python using Pydantic for stronger type guarantees. FastAPI also generates an OpenAPI.json file for your backend and then you can feed this OpenAPI.json document into https://github.com/OpenAPITools/openapi-generator to generate a typescript library that contains all the types. Then you don't need to verify your types, because the typescript types will be directly generated from your Python types. The generated typescript library also contains methods for each of your REST endpoints, so that you don't have to think about network requests.
paddy_m
So, this is a jupyter/anywidget project. I think OpenAPI can work, but it's a bit of grafting I think.
Further, I develop the frontend visualization library separately from the python code. It is much more natural to write typescript there, first for types that power the frontend. I just want to make sure earlier that python is sending the same types. I'd like to avoid pydantic, because it is a another dependency, and I control both sides. I'm not worried about an errant request/response, just proviing at build time that I am sending and receiving the proper compatible types.
yedpodtrzitko
Python type system is less expressive than TS, so defining types in Python and then generate (rather than write them manually) the equivalents in TS feels like the better way. There are tools to generate Typescript types/structures from OpenAPI definition for doing that.
pier25
So this is only really about using OpenAPI, right?
Other than that there's really no interop between Rust and TS?
sureglymop
What I don't understand here: Is the sveltekit app built into an SPA or static site? Or is it running on e.g. node as a second backend that communicates with the rust backend over HTTP? If so, doesn't that quite increase the overhead?
eddythompson80
The short answer is: Yes
Long answer is: looking at the skeleton code in the repo, it's setup for development to run 2 servers (a server just serving static files for the svelt app PORT=3000, and a server running the API PORT=3001) https://github.com/beeeeep54/rust-typescript/blob/main/backe...
But I have seen people do that but:
- Package it into 1 docker container (or 1 service for lack of a better term) that runs both with a proxy that's only there in "prod" deployment not local development. so inside the container it's 2 processes, but outside it's like 1 selfcontained application
- enable a static server on the API endpoint once deployed. It's usually 1 line in most web framework. Something like `app.serveStatic("/", "./static")`. In this case it's 1 server doing both
- Deploy them as 2 different services that scale and are managed completely independently. Could as well be 2 different teams or even companies doing frontend vs backend development (with that same setup of style. Though probably you won't be working in the same repo then)
then take all that and multiply it by 2 or 4 for all the proxy/path/domain permutations
sureglymop
Thanks for all the details. I cloned the repo now to take a look.
If I see it correctly here, it's a full sveltekit backend that does ssr, and not just used for serving static files. The +page.ts file has a universal load function so during ssr, the sveltekit backend loads data from the rust backend and later during hydration the client also loads data directly from the rust backend without the requests being proxied through the sveltekit backend.
I'm guessing in production one would proxy all requests through the sveltekit backend (or another proxy) as you mentioned.
Also, if we would run them both in the same location or in a container, wouldn't it be much better to use unix domain sockets for the IPC?
eddythompson80
Yeah, you're probably right if you want ssr. My understanding was that most ssr frameworks have ssr as optional and people fight about the tradeoffs between page load time (better with ssr) vs rps per CPU core (better without ssr). I'm not sure if that's the case with svelte.
> Also, if we would run them both in the same location or in a container, wouldn't it be much better to use unix domain sockets for the IPC?
Probably in 2006? My understanding was that the localhost tcp stack in linux has been optimized so much, that it's hardly a "network" connection anymore and has no overhead compared to a unix domain. The main difference is that people using unix socket tend to hand roll their communication protocols, but if you're gonna be serving http though a
On my desktop
$ netperf -H 127.0.0.1 -t TCP_STREAM
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 10.00 35464.47
$ netperf -t STREAM_STREAM
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
2304 212992 212992 10.00 32852.21
Cshelton
We do something similar, in Dev you have a "dev" server and an API. In Prod, we use a CDN to server the static files using AWS ALB and Cloudfront.
eddythompson80
Yeah, it's pretty common pattern. Especially if you're doing active frontend development as hot/auto-reloading of the page comes standard with all dev servers and it's generally what you want.
Serving your frontend through nginx for local development would work, but it's not very ergonomic. I know .NET has a built-in development server for frontend apps so you can use it in both prod and dev, but I think most frontend devs prefer the CDN option especially that it gives their delivery a performance boost and makes it completely independent of any backend.
sidoshi
I was looking for a solution like this as rspc isn't maintained anymore. I love how clean it looks. But I am a bit new to rust and I am not sure about poem. Axum is very popular and seems like a stable crate. Can you share your thoughts on Poem? Does it feel outdated or unstable? Does it cover all your needs?
vaylian
> Can you share your thoughts on Poem?
There's the poem crate and then there is the poem-openapi crate. The latter is used in this case and it provides very ergonomic ways to define an OpenAPI service in pure Rust. It's nicer than using the utoipa crate with axum (whilch ist still fairly nice, so no shade here).
I'm happy with poem-openapi.
sidoshi
But if I understand correctly, poem_openapi must be used with poem, correct? That brings me to the question of if I am okay with using poem to power the http API. Would be awesome if I could use the poem_openapi style with axum.
vaylian
> But if I understand correctly, poem_openapi must be used with poem, correct?
poem_openapi uses poem under the hood.
> Would be awesome if I could use the poem_openapi style with axum.
If you prefer to use axum, have a look at the utoipa-axum crate. But poem and poem_openapi seem to be well-maintained as well.
evilmonkey19
It looks like a good idea to me if you're developing something that requires it. Nevertheless, most developers which do web development they require something easier to develop with mainly in the backend. Nowadays TS (JS) and Python are widely used do to its versatility.
eYrKEC2
I like not getting paged at night, so I vastly prefer rust backends. I have experience with TS, Python, and Rust backends and the Rust backends very rarely failed for me.
morteify
[dead]
koakuma-chan
Why do you need a separate back-end in Rust? Nothing beats Next.js + React server components for me.
williamdclt
Anything beats next and react server components for me. It’s a mess of lock-in and complexity that brings very little. It also changes all the time, the maintenance cost is _crazy_ compared to almost all other mainstream options, the ROI is super low.
hombre_fatal
Next.js and similar are surprisingly complicated. You pay a hefty price for the optimization of SPA + data on the first request (which is a cool optimization).
I think one of the reasons it's so popular is less about the niche optimization and more about how it seems simpler, especially to beginners, than running an API server that your frontend app connects to.
diggan
> Why do you need a separate back-end in Rust?
Such a generic question, with probably hundreds of possible answers, it really depends on the context. From the top of my mind, whatever library/program you wanna use only being available in $Language comes to mind as something you encounter at least once in your career as a programmer.
koakuma-chan
> From the top of my mind, whatever library/program you wanna use only being available in $Language comes to mind as something you encounter at least once in your career as a programmer.
That wouldn't be a reason to also write your CRUD backend in that language. You would just make it a separate service written in that language.
diggan
I rather include a WASM Component that uses $library and pass data within the program, than setting up an entire service doing the same thing, but now with web transport complexity.
owebmaster
That's the first time in many years that I see someone saying they like RSC.
koakuma-chan
What is there not to like? RSCs simplify state management by so much. There is no longer any need for zustand, redux, etc.
afavour
As someone who lightly dabbles in React my interpretation of that comment is “what’s not to like? It solves at least some of the problems React itself introduced!”
williamdclt
Really few applications ever needed redux, whatever the backend
I use ts-rs [1] in my project to generate Typescript definitions. The files are copied to the web app automatically.
[1] https://crates.io/crates/ts-rs