Fiber/fasthttp support

[pjebs]

Fasthttp is an alternative http server package that is substantially faster.

This would be great if it supports that.

[pjebs]

https://docs.gofiber.io/api/app#test

[nlepage]

Hi @pjebs

This would be a great improvement indeed.

fasthttp uses a completely different API from net/http so this would need some work.
I’m sorry to say I won’t have the time to do this before several months.

However here are some thoughts after having looked at fasthttp’s API:

• create a new fasthttp sub-package with a Serve func accepting a fasthttp.RequestHandler
• when a request is received from the ServiceWorker, use fasthttp.AcquireRequest and fasthttp.AcquireResponse to create the necessary fasthttp.RequestCtx to give to the RequestHandler
• probably Request.setBodyStream if the request has a body
• copy headers etc.
• not sure how to read back the responses body

[pjebs]

You don't seem to be using net/http/httptest anymore. In your introduction video you used that.

[nlepage]

You don't seem to be using net/http/httptest anymore. In your introduction video you used that.

Yes, the dependency to net/http/httptest was removed to allow the compatibility with TinyGo.

[pjebs]

I wonder if there was a way to run wasm server on a web worker and have something else simpler intercept the fetch on the service worker and communicate with web worker.

Web workers are better suited for long running tasks.

[pjebs]

@gedw99 cloudflare uses standard golang net/http

[pjebs]

That is just a function to convert JS request objects to net/http request objects and vice-versa

[nlepage]

I wonder if there was a way to run wasm server on a web worker and have something else simpler intercept the fetch on the service worker and communicate with web worker.

Web workers are better suited for long running tasks.

go-wasm-http-server’s primary goal is to hook Go’s HTTP framework to the Service Worker’s fetch events.

As I understand it, Web Workers are useful when there is the need to run CPU heavy tasks without impacting the user interface, or in other words the run loop, which is slightly different.

HTTP requests may trigger heavy tasks, but I don’t think this should fall under go-wasm-http-server’s scope, as it is not generally the case.

If one needs to run heavy tasks in a Go WASM binary, I think a better suited approach would be to run a goroutine in a Web Worker, and right some code or even a library to achieve this.

[pjebs]

I wonder if there was a way to run wasm server on a web worker and have something else simpler intercept the fetch on the service worker and communicate with web worker.
Web workers are better suited for long running tasks.

go-wasm-http-server’s primary goal is to hook Go’s HTTP framework to the Service Worker’s fetch events.

As I understand it, Web Workers are useful when there is the need to run CPU heavy tasks without impacting the user interface, or in other words the run loop, which is slightly different.

HTTP requests may trigger heavy tasks, but I don’t think this should fall under go-wasm-http-server’s scope, as it is not generally the case.

If one needs to run heavy tasks in a Go WASM binary, I think a better suited approach would be to run a goroutine in a Web Worker, and right some code or even a library to achieve this.

@nlepage I was thinking more along the lines of WASM running on web worker being long-lasting and not getting shut-down or suspended like service workers are prone to: https://developer.chrome.com/docs/extensions/develop/concepts/service-workers/lifecycle and mswjs/msw#2115

I actually got it to work as a proof-of-concept. You need 2 MessageChannel to pass data from the Service Worker <---> Main Thread <---> Web Worker. It runs smoothly.

Unfortunately there is a limit on the type of data that can pass those boundaries. You can't send a JS Request or Response object past those boundaries because they are either not "transportable" or don't satisfy the structuredClone algorithm. But I just created my own JS object with the url, method, body and headers. Not a big deal. Same deal for Response.

In your code, since the WASM server and Service worker are within the same context, the server can stream data etc very easily. That would be much harder to do when the WASM server is not in the same context as the service worker.

It can be done however: https://github.com/whatwg/streams/blob/main/transferable-streams-explainer.md and https://github.com/MattiasBuelens/remote-web-streams

[pjebs]

https://github.com/romance-dev/poc-fiber-wasm