-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
Compiler as a Service #27
Comments
@gedw99 thanks for pinging me. I'm in the end parts of our month-end wazero release, so can't think too much through this yet. I've forked hackpad locally for my long flight to golab.io this weekend. I like the idea you are talking about, but want to familiarize a bit more and it may take a few days. |
Hey @codefromthecrypt yeah it’s a bit of a Holy Grail sort of architecture, so take sone digesting . I wrote up a doc on it in 3 hrs today just to get it all down and structured. It’s for an Open Science platform . I would like you to eyeball it and see what your think |
Oh and no rush !! Sure your mega busy with conference as I imagine your presenting |
@gedw99 thanks when you have the doc together link it! For the conference, I'm not speaking, but there's a lot of wasm content there (also at rustlab). Mainly trying to meet some folks. Besides the wazero release other source of busy is this experimental http handler https://github.com/http-wasm |
thanks @codefromthecrypt https://github.com/http-wasm looks relevant to this... AH now i get it :) https://docs.dapr.io/reference/components-reference/supported-middleware/middleware-wasm/ |
It would be cool to have a compiler as a service running on a server that the HackPad IDE can interact with.
the reason is because I am interested in making plugins . You write it in golang and compile with Tinygo . The Compiler As A Service ( CAAS ) does that and then you can “ see it “ in the IDE.
I saw the Web Worker Par in HackPadFS and it got me thinking. I presume that’s so that the FS in running isolated in its own isolated area outside of the main GUI and so hence hardening the system from crashes.
so my rational is to do it for all code. The developers code that they are developing in the IDE is compiled and exposed as a Web Worker.
The same can then be done with Wazero so that you can run the wasm on the server also. Why think about this ? Because you end up with reconfigurable ( is that a real word ? ) computing, and so depending on the nature of the code can run it in a Browser or on a Server ( with Wazero ).
The way WASI and WASM exposes the exports is different . But it’s possible to shim that by writing a compile time wrapping that walks the AST and code generates the equivalents needs for it to run in the browser too. If we write the exports out as a JSON file then an IDE can “ discover “ the exports and elevate it in the IDE GUI.
@codefromthecrypt as I figure this is interesting to you .
I probably should have made this a discussion.
My request is to know what are the blockers.
is my codegen concept the way to go for at least the golang community. I read about WIX but the more I delve into it I get the impression that there is no standard yet ( or ever will be ) for WASI and WASM being able to be single sourced and run in both environment easily . Hence sone compile time and runtime wrapper ingredients seems needed.
The isolation aspects of WebWorker and Service Workers can possibly mapped to similar topology primitives on the Server works. A WebWorker is easy because it’s the same as a Fly.io Machine or a Wazero server hosting WASI.
the Service Worker equivalent would be a gateway / Proxy / Caching type of thing similar to Caddy with Caddy Modules but not sure . Service workers have logic , caching and procuring capabilities.
The text was updated successfully, but these errors were encountered: