wasm / deno updates

[gedw99]

hey @dosco

Been playing with the wasm....

Can you add a script to show how to boot the wasm / deno compbo

BTW it works with gotip. no need for tinygo. gotip has the "new wasm" build in.

GOOS=js GOARCH=wasm gotip build -o graphjin.wasm .
GOOS=wasip1 GOARCH=wasm gotip build -o graphjin.wasip1 .

[dosco]

./wasm/make-tiny.sh has been added the build needs testing. the build is about 5mb smaller

[gedw99]

thanks @dosco will try this out.

[dosco]

any thoughts on the the tinygo wasm build? also any thoughts on how gotip helps us?

[gedw99]

I don’t think we need gotip. The WASM updates are now in the released version of golang .

tinygo works well on most simple projects.

Graphjin should work because it has simple dependencies. Reflection is still a bit of a work in progress.

I will try to work on testing it but am pretty stretched right now. Would appreciate if you and others can update this issue with results …

[dosco]

It already compiles with gotiny and with the standard go compiler. But even with go tiny its not as small as I like it to be.

[gedw99]

Its server side though so who cares ?

I presumed you wanted to run ti with wazero, so than devs have sandboxing, without Docker...

[dosco]

That's true, some folks asked me the wasm build could be smaller it's used by the npm package for GraphJins Nodejs API. Thanks for the tip on wazero I did not know about it.

[gedw99]

Glad to help …

Would be also woth looking at the SQLite WASM that uses wazero too to get a head start . I am using it and it’s working really well

https://github.com/ncruces/go-sqlite3

the perf is actually excellent too .

I am running it server side and client side in a browser . The client side is however only capable off in memory storage, but that suits my needs perfectly. I can compile my server to run in a browser, allowing isometric architecture. I use web components SSR, so I can run them in both places , getting me very fast GUI by only hitting the client side WASM. Google SEO only users server side SSR. Humans user the server side SSR for the first 10 seconds and switch over to the client side WASM once it’s loaded into the service workers.

Once this switch over occurs , the db changers pertinent to that human are streamed to the client side DB, these only hitting the client side.

Once the human closes the browser and data is lost . It’s in memory. This is realistic because a browser can garbage collect web storage at any time . Especially on mobiles. There is no free lunch and it’s a decent trade off.

The other system that can do this is Corrosion. It has built in support for stream subscription queries and master / master replication using CRDT. It allows the same isomorphic architecture I described above.

https://github.com/superfly/corrosion

it has a clean http API for subscriptions:

https://superfly.github.io/corrosion/api/index.html