Asset handler as a web server for existing frontend application

[emcfarlane]

Looking for general feasibility/recommendations. Is it okay to use the AssetHandler as a webserver for an API and the frontend to interact through it. Any downsides?

The benefit is getting a stable webserver API to implement against with frontend components already designed to use the API requests for managing state. Hoping to reduce complexity in porting a web application to wails. Thanks!

[leaanthony]

I think @mholt might be doing something similar....

[mholt]

Yeah, that works. AFAIK the built-in server will pass along anything that doesn't match a static asset to AssetHandler. Oh, but websockets won't work. Those will have to be transitioned to Events (I have yet to do this).

I decided to eliminate HTTP for my Wails GUI though. It wasn't a lot of work since my HTTP handlers were basically: 1) decode the request, 2) call the function, 3) write the HTTP response. I just split out step (2) so JS can call it directly. It's so nice to be able to simply call a function in JS and have the response as a native JS value without having to deal with HTTP status codes, etc; and my Go code can just do its thing and return error values, without having to worry about HTTP.

I still kept parts (1) and (3) (basically the bread to the API sandwich) but moved them into a separate package where I spawn my own HTTP server so I can still do go run and get a workable API server that I can dev against, without needing to do the Wails bindings. That's purely my preference though.

So if you have an existing HTTP API, you can keep using it AFAIK. But tbh I wouldn't want to do it that way long-term, when you don't have to use HTTP at all. Wails takes care of direct IPC for you, which IMO is a lot more elegant.

[emcfarlane]

Thanks! Makes sense I’ll look more into porting over the functions.

[gerbil]

But how you can just 'rewrite' ws to events for wails to be used in this case?