New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeError: WebAssembly: Response has unsupported MIME type 'text/plain; charset=utf-8' expected 'application/wasm' #641
Comments
never mind, I didn't read to the end of the getting started |
Sadly, I don't see what you found at the end of the getting started which solved this for you! :( |
He probably did not compile the WASM part, which needs to be in the web folder as 'app.wasm'. |
Oh. I did do that part. |
Do you still get the same error as he got? Or why did you end up here? |
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? |
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 |
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. |
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 That loaded me a Hello World! But also did some weird stuff with the loading screen: |
I had some strange things happen to me too when using |
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. |
Out of curiosity:
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 |
Ahem. What about adding the appHandler not to "/" but to "/prefix/"? I guess that may solve it?
|
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. |
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 ;) |
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? |
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. |
It's entirely possible it does not make sense to use go-app here! |
Can you do a |
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. |
You can use os.Executable() in that case in your app. |
I just did a |
Getting this error
The text was updated successfully, but these errors were encountered: