A Rust-TypeScript integration
github.com
github.com
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.
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.
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.
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.
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.
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.
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.
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.
Other than that there's really no interop between Rust and TS?
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
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.
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?
> 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
$ netperf -H 127.0.0.1 -t TCP_RR
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 131072 1 1 10.00 63506.58
16384 131072
$ netperf -t STREAM_RR
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
212992 212992 1 1 10.00 122526.23
4608 2304
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?solved
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?
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?
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.
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.
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.
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.