Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Rust-TypeScript integration

github.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: A Rust-TypeScript integration

#31

Post by yedpodtrzitko »

paddy_m wrote: post #30

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.

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.

Re: A Rust-TypeScript integration

#33

Post by eddythompson80 »

sureglymop wrote: post #29

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

Re: A Rust-TypeScript integration

#34

Post by eYrKEC2 »

evilmonkey19 wrote: post #3

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.

Re: A Rust-TypeScript integration

#35

Post by vaylian »

sidoshi wrote: post #15
vaylian wrote: post #12

Earlier quoted context omitted.

> 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.

Re: A Rust-TypeScript integration

#36

Post by kasbah »

graup wrote: post #13

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

Re: A Rust-TypeScript integration

#37

Post by Cshelton »

eddythompson80 wrote: post #33
sureglymop wrote: post #29

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…

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.

Re: A Rust-TypeScript integration

#38

Post by vaylian »

paddy_m wrote: post #30

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.

Re: A Rust-TypeScript integration

#39

Post by sureglymop »

eddythompson80 wrote: post #33
sureglymop wrote: post #29

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…

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?

Re: A Rust-TypeScript integration

#40

Post by eddythompson80 »

Cshelton wrote: post #37
eddythompson80 wrote: post #33

Earlier 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…

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.

Post reply on HN