So this is only really about using OpenAPI, right?
Other than that there's really no interop between Rust and TS?
A Rust-TypeScript integration
41–50 of 52 posts
Re: A Rust-TypeScript integration
#42Why do you need a separate back-end in Rust? Nothing beats Next.js + React server components for me.
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.
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.
Re: A Rust-TypeScript integration
#43I 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.
> 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/Open…
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.
Re: A Rust-TypeScript integration
#44I 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.
Re: A Rust-TypeScript integration
#45Earlier quoted context omitted.
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…
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…
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
Re: A Rust-TypeScript integration
#46I 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
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.
Re: A Rust-TypeScript integration
#47See also, Specta: https://github.com/specta-rs/specta
Re: A Rust-TypeScript integration
#48Earlier quoted context omitted.
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…
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.
Ah the classic retort. X is merely a broken version of Y. Y has flaws. Therefore X has all of flaws of Y.
No. I don’t accept that. Certainly not prima facie.
Solid isn’t a broken version of react. It’s a fixed version of react. Signals aren’t the same as useState because in solid, dependencies are tracked automatically when you read from them and components automatically rerender as a result. Also because component functions are only executed once, it’s usually pretty easy to just add any state management you want into the body of a component.
At least that’s been my experience with solid so far. I’d love to see a counter example in which these external state management libraries actually add value?
Re: A Rust-TypeScript integration
#49I wish people would be a little bit more precise.
There is no type safety.
There must be data validation on the endpoint but anyone can send anything and if you rely on your front-end to send you the right data shapes and valid values without checking, you are in deep trouble.
Re: A Rust-TypeScript integration
#50Earlier quoted context omitted.
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.
Ah the classic retort. X is merely a broken version of Y. Y has flaws. Therefore X has all of flaws of Y. No. I don’t accept that. Certainly not prima facie. Solid isn’t a broken version of react. It’s a fixed version of react. Signals aren’t the same as useState because in solid, dependencies are tracked automatically when you read from them and components automatically rerender as a result. Also because component f…
I am not interested in arguing whether state management libraries add value, or how React useState compares to Solid createSignal, but I will reiterate that with React server components, there is no need to manage state on the client at all.