search

hobofan / yew_webview_bridge

2-way communication between yew and web-view
Apache License 2.0
5 stars 10 forks source link

headless/browser/serve mode #9

Open kellpossible opened 4 years ago

kellpossible commented 4 years ago

It would be great if it were possible to run the backend in headless mode, and serve the front-end to a web-browser like in wails which also implements something a bit similar for webview in Go. This has the benefit of having more standard web development and debugging tools available. But one drawback is that the APIs available are less restricted in the browser, so it would be important to explain this in the documentation.

I was thinking we could rely on the library user deciding how to serve/load the wasm assets themselves to the front-end, which they already need to do anyway, and instead focus purely on providing an alternate mode of communication.

Ideally it should be possible to have both methods available at the same time, and can be selected by the application at start-up, so it could be provided as an optional debug command line switch for the application.

Websockets seems like it could be a good candidate replacement for communication, there are already a couple of native Rust libraries for doing this:

On the frontend it seems like it should be possible to do with web_sys:

Provided of course that the web-view browsers on all platforms support this API.

hobofan commented 4 years ago

Do you have a specific use case in mind? Everything I come up with seems to better served by a yew+traditional server framework (e.g. tide/rocket) combination, and in some cases even specific solutions tailored to that domain like GraphQL.

I'm using a similar "bridge" paradigm for yew+tide, but wasn't really able to come up with any meaningful publishable abstractions (because I didn't want to leave all the route generation to bridge magic).

kellpossible commented 4 years ago

I wasn't thinking of making this a full fledged way to develop an application for the web and web-view, but rather something to use locally for debugging and developing. The final application would still be published using web-view. Routes wouldn't need to be implemented if you don't use a browser route based router (I think web-view doesn't support changing the browser's routes anyway on all the platforms). There are a lot of developer tools available for Chrome and Firefox, which aren't available in web-view. For instance I'm thinking of adding support for Redux DevTools eventually in an application I'm building.

kellpossible commented 4 years ago

For additional context, the application I'm currently developing currently doesn't use a web server at all. All assets are either embedded in the HTML to begin with, or are transferred via yew_webview_bridge.

kellpossible commented 4 years ago

I hacked together a rough implementation you can see in this pull request