[HN Gopher] A Rust-TypeScript integration
___________________________________________________________________
A Rust-TypeScript integration
Author : wreedtyt
Score : 45 points
Date : 2025-07-04 11:42 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| koakuma-chan wrote:
| Why do you need a separate back-end in Rust? Nothing beats
| Next.js + React server components for me.
| owebmaster wrote:
| That's the first time in many years that I see someone saying
| they like RSC.
| koakuma-chan wrote:
| What is there not to like? RSCs simplify state management by
| so much. There is no longer any need for zustand, redux, etc.
| afavour wrote:
| 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 wrote:
| As someone who has been using it professionally for
| years, you're correct
| koakuma-chan wrote:
| Is the state management problem unique to React? Do you
| not need to manage state in other libraries, like Angular
| or Vue or Solid?
| Mipila wrote:
| Cant speak for Vue or Solid, but in Angular this has
| never been a big issue like it is in react. There is
| state of course but it is not something you have to
| actively think about all the time. State is kept as
| properties in classes, directly on your component or
| (when it needs to be shared) in services that can be
| injected. Angualar change detection will update the view
| when needed. You can argue about the performance of this,
| but in my experience it is easier on the developer.
| koakuma-chan wrote:
| Angular has NgRx, which is, AFAIK, the same as RTK.
| Mipila wrote:
| As my previous comment suggests, I don't see why people
| feel like this is needed. It does seem to be used though.
| josephg wrote:
| I've written a fair few Solid apps. I've never felt the
| need to reach for 3rd party tools to help manage state.
| In my experience, solid's built-in signals (& resources)
| are enough on their own for simple apps. And when I need
| something more complex, you can build on top of them if
| you know what you're doing.
|
| If anyone is curious, here's an interactive, editable
| tutorial teaching how solidjs signals work. If you
| haven't seen solid before, its similar to react but
| components don't re-run whenever their state changes:
|
| https://www.solidjs.com/tutorial/introduction_signals?sol
| ved
|
| Am I missing out on some whiz bang magic that the react
| ecosystem has invented? Is it substantially better than
| what solid provides out of the box?
| koakuma-chan wrote:
| I agree that Solid signals and resources are robust, but
| they are still very similar to React's useState and
| useEffect, and you are basically suggesting to implement
| your own state management library. Regardless, with React
| server components, there is no need to manage state on
| the client at all.
| scotty79 wrote:
| > some of the problems React itself introduced
|
| You never had to do state management before React? Maybe
| it wasn't called that but I definitely had to manage some
| state between frontend and backend in webapps.
|
| Also it's hard to tell what problems come from React and
| what from any SPA. As I keep familiar with React
| development I'm inclined to say that almost all React
| problems people are complaining about are SPA problems
| and modern React is the only framework that even dares to
| try to solve them and does it increasingly successfully.
| williamdclt wrote:
| Really few applications ever needed redux, whatever the
| backend
| koakuma-chan wrote:
| When a dynamic web app is needed, the general trend is to
| build SPAs, which in turn require managing state on the
| client, which is complex and thus redux et al were
| invented.
| williamdclt wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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.
| evilmonkey19 wrote:
| 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 wrote:
| 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.
| sidoshi wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
| graup wrote:
| 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?
| diggan wrote:
| 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.
| kasbah wrote:
| 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.
|
| [1]: https://github.com/kasbah/calm-go-pattern-search
| mootoday wrote:
| 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
| agnishom wrote:
| I use aeson-typescript but it is broken in subtle ways
|
| https://hackage.haskell.org/package/aeson-typescript
| aporiador wrote:
| I use https://github.com/1Password/typeshare it has it's
| quirks, but works nicely
| jtwaleson wrote:
| I switched to utoipa as I also needed an Open api client
| generator.
|
| One neat thing is that I generate the complete client with a
| bit of python code. Then I use Knip to find unused exports in
| my Typescript project. I actually found some unused backend
| methods that were left over from refactoring.
| sureglymop wrote:
| 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 wrote:
| 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
| Cshelton wrote:
| 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 wrote:
| 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.
| sureglymop wrote:
| 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 wrote:
| 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
|
| so pretty close
| paddy_m wrote:
| 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.
| yedpodtrzitko wrote:
| 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.
| vaylian wrote:
| > 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 wrote:
| 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.
| pier25 wrote:
| So this is only really about using OpenAPI, right?
|
| Other than that there's really no interop between Rust and TS?
| brainless wrote:
| 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.
___________________________________________________________________
(page generated 2025-07-04 23:01 UTC)