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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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).
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.
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?
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
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?
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
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.
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.
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.
> 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.
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.
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!”
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'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:
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?
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.
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.
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.
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.
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.
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
I use https://github.com/1Password/typeshare it has it's quirks, but works nicely
I use aeson-typescript but it is broken in subtle ways
https://hackage.haskell.org/package/aeson-typescript
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.
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?
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
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.
I 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.
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.
> 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.
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.
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.
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.
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?
> 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.
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.
> 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.
So this is only really about using OpenAPI, right?
Other than that there's really no interop between Rust and TS?
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?
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
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?
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
so pretty closeQuite interesting! I get similar results on my machine. But let's also measure latency which is what should show the protocol stack overhead:
But I would agree now that it probably doesn't matter for most applications.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.
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.
See also, Specta: https://github.com/specta-rs/specta
[dead]
Why 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.
> 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.
> 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.
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.
That's the first time in many years that I see someone saying they like RSC.
What is there not to like? RSCs simplify state management by so much. There is no longer any need for zustand, redux, etc.
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!”
> 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.
Is the state management problem unique to React? Do you not need to manage state in other libraries, like Angular or Vue or Solid?
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?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?
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?
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.
Yeah because then you are managing a session in the backend. A backend that is not necessary. But still billing.
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.
Angular has NgRx, which is, AFAIK, the same as RTK.
As my previous comment suggests, I don't see why people feel like this is needed. It does seem to be used though.
As someone who has been using it professionally for years, you’re correct
Really few applications ever needed redux, whatever the backend
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.
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.
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.