we are planning to move our inner store management app from Angular to GTK4. All our backend services are in rust, so it seems to be a not bad idea.
I have read GTK4-rs online documentations, and checked the github examples (at the project site), but havent figured it out how to use async api calls. Reqwest seems to be the way, but it uses Tokio runtime, so we cannot use it directly with GTK4-rs.
Could you help me which is the right way to go? Our app would heavily communicate to our REST API, and display the results.
Use reqwest blocking everywhere? Or use another http library? Or somehow use Tokio runtime? Or something else?
I haven’t checked gtk4-rs, but this is an example using gtk3-rs with tokio. The main idea is to spawn a tokio runtime in a different thread and use messages to communicate witb the main/ui thread.
Generally the approach I would recommend is to spawn a single-threaded Tokio runtime on a separate thread, then use one of the strategies described in this article on bridging sync and async code under the other approaches section. Basically, to perform a request, you spawn a Tokio task on the runtime remotely and then you have the Tokio task send messages back to your UI in some manner (e.g. shared memory that your UI code checks periodically, or use a glib channel to execute code on the UI thread once the request completes).
Awesome! I have started to create an mvp app, and everything has worked so smoothly that I almost forgot to use event based approach.
Do you think using a spawned background process and running tokio runtime have any benefit over just using a blocking http library such as ureq, spawn an ureq http blocking query in the background and using the same event based approach using MainContext::channel(..)?
Now I tried the second one, just spawned a blocking ureq query, and used a channel to handle the background events in the main thread. It works nicely, and seems to be a bit less heavy then using tokio. But I have faar not enough experience with GTK-rs to see what i am missing.
Well, both would work. I guess it depends on whether you need any libraries that only exist in async, or if you want any features that only async can provide, e.g. cancellation of arbitrary background tasks. And also, if you're going to run many operations at the same time, async would likely use less resources.