TypeError: WebAssembly: Response has unsupported MIME type 'text/plain; charset=utf-8' expected 'application/wasm'

[idc77]

Getting this error

TypeError: WebAssembly: Response has unsupported MIME type 'text/plain; charset=utf-8' expected 'application/wasm'

package ui

import "github.com/maxence-charriere/go-app/v9/pkg/app"

type Home struct {
	app.Compo
}

func (h *Home) Render() app.UI {
	return app.Html().Body(
		app.Head().Body(
			app.Meta().Name("charset").Content("utf-8"),
		),
		app.Body().Body(
			app.H1().Text("Hello World"),
		),
	)

}

package cmd

import (
	"net/http"

	"mypackagepath/ui"
	"github.com/maxence-charriere/go-app/v9/pkg/app"
	"github.com/spf13/cobra"
)

// uiCmd represents the ui command
var uiCmd = &cobra.Command{
	Use:   "ui",
	Short: "",
	RunE: func(cmd *cobra.Command, args []string) error {
		app.Route("/", new(ui.Home))
		app.RunWhenOnBrowser()
		http.Handle("/", &app.Handler{
			Author:       "A name",
			Description:  "domain.tld is an URL shortener service",
			LoadingLabel: "Yo! Wait up, it's loading...",
			Name:         "Some Name",
			Title:        "domain.tld - shorturl service",
			Version:      "1",
		})

		return http.ListenAndServe(":7890", nil)
	},
}

func init() {
	rootCmd.AddCommand(uiCmd)
}

[idc77]

never mind, I didn't read to the end of the getting started

[ocdtrekkie]

Sadly, I don't see what you found at the end of the getting started which solved this for you! :(

[oderwat]

He probably did not compile the WASM part, which needs to be in the web folder as 'app.wasm'.

[ocdtrekkie]

Oh. I did do that part.

[oderwat]

Do you still get the same error as he got? Or why did you end up here?

[ocdtrekkie]

So my browser appears to be getting a 404 not found. (And hence is returning MIME type text/html.)

I am very very new to writing Go, but I'm pondering... what in the getting started is actually serving the /web directory?

[oderwat]

The app executable you start has a webserver build in and handles serving the wasm. I am uncertain if it helps you because it has a lot more stuff going on, but you may want to check out either:

https://github.com/oderwat/go-nats-app
or
https://github.com/oderwat/go-guess-the-number-app

[oderwat]

There is also https://github.com/mlctrez/goappcreate by @mlctrez which uses another approach (the usual make instead of mage and gin framework instead of the chi router). I do not have our "watcher" included in my first example (the reloading because that's a lot of proprietary code now). In the go-nats-app there is also the back- and front end communication solved. But it is using NATS for that, which is a very cool and powerful but unusual approach. Before that, we were using "Twirp" and a bit web sockets and standard REST. The NATS combines this and makes stuff effortless to write and understand.

[ocdtrekkie]

Hmm... Okay, so I am trying to serve this in an abnormal environment (a Sandstorm.io dev sandbox, as the case is), and I may have to go back and ask someone else to explain this oddity for me, but I'll explain here unless this provides some context that's useful.

My app is built at /opt/app/app and my WASM is at /opt/app/web/app.wasm, so everything should work out of the box, I think, but as I said, I'm getting a 404 on the app.wasm, which is weird. However, I was reading about some of the other stuff in Docs, and was pondering the ability to config where static resources are, and added Resources: app.LocalDir("/opt/app/web"), even though, of course, that's the default relative location anyways?

That loaded me a Hello World! But also did some weird stuff with the loading screen:

[oderwat]

I had some strange things happen to me too when using app.LocalDir(). In fact, I did not really understand how that works at all. It may help to check what paths are used from the browser (development console / net tab) and fiddling with the static resources option. It looks like it does not find the 'app.css'. If you do not need a backend, you may get happy by just creating a static version of the site.

[ocdtrekkie]

Interestingly enough, the app.LocalDir() is the only thing that got me going at all. By default, I just get a 404 on the wasm and that's it. So I'm wondering if go-app does anything clever with the host URL or something in some way to find it that's defeated by Sandstorm by default.

I definitely will need a backend if I'm going to use this at all, Sandstorm renders local storage useless.

[oderwat]

Out of curiosity:

Sandstorm renders local storage useless.

Why is that? I use a modified and wrapped version of idbkv for one of our projects. What does Sandstorm, that interferes with that (but I still need a backend anyway)?

About your problem: I guess that "localDir()" changes where the "web" directory is located on the server drive. There must be another setting for the "base url", the app.css (and something else I don't remember) gets served directly from the app and that URL needs to be added. So actually, there needs to be the prefix defined and you most likely do not need the localDir() after that. But I am just guessing, right now.

[oderwat]

Ahem. What about adding the appHandler not to "/" but to "/prefix/"? I guess that may solve it?

// HTTP routing:
	http.Handle("/prefix/", &app.Handler{
		Name:        "Hello",
		Description: "An Hello World! example",
	})

[ocdtrekkie]

Where is "prefix" coming from in this context?

So the reason local storage doesn't work in Sandstorm is because we spawn apps on a randomized subdomain every time you open them. Local storage isn't necessarily blocked, but the chances the app will ever be at that origin again is statistically impossible, so it effectively doesn't persist for us. This is good anyways: We want apps to store on the server so that everything is cross-device.

[oderwat]

I guesstimated that the path of your application is not in the root. But if it is, the prefix idea does not apply. I am still not sure if I understand the problem. The web directory needs to be below the current work directory when the binary is started. As I said above, changing the local directory never worked as I expected because it did strange things (like in your example).

About the subdomain: Yeah ;)

[oderwat]

But... having this kind of subdomain actually prevents one of Go-App's main functionality: Installation as an App on the user's phone or desktop. Which is the only reason for us to use it. Loading such a large Wasm code every time I open the app again does not make sense :). So, I wonder why you want to use Go-App for that use case?

[ocdtrekkie]

Yeah, the app is served at the root of the subdomain, and the web folder is in the same directory on the server as the server binary.

So server is listening at http://subdomain/ and 404ing trying to load the wasm at http://subdomain/web/app.wasm, which seems like where it should be.

[ocdtrekkie]

It's entirely possible it does not make sense to use go-app here!

[oderwat]

Can you do a log.Println(os.Getwd()) (and watch the output somewhere) in func main() to verify the current working directory is where the "web" folder is?

[ocdtrekkie]

It'll be a bit until I can check, but you might be on to something. I think we launch /opt/app/app, but don't cd to /opt/app first.

[oderwat]

You can use os.Executable() in that case in your app.

[ocdtrekkie]

I just did a cd in the script that launches it. All good, that was it. Thanks for talking me through it!