Agree, it is one of the best WASM interpreter! Even better than some of the runtimes we can get here and then Performance is very good and architecture and beauty of the code is definitely impressive.

Thanks!

Author here. Feel free to ask questions :) Hope this is interesting

I once made an app and a talk on this matter. Slides about problems mentionned in the article were addressed from slide 15 onwards. Mainly I remember having used Lamport clocks to track rows' causal history. And negative primary keys for inserting data in offline mode (these days I'd use UUID). Since IndexedDB was not a thing yet on every browser, I used asm.js (ancestor to WebAssembly) to compile SQLite for the browser. The database file was stored in the LocalStorage and I used zlib (compiled with emscripten) to make most of the little space LocalStorage gave to us. It has been a learning experience, and worked at the end. I wonder how I would do differently today... By the way, we were using GWT to code for the browser, but that's just an anecdote and not important for that matter...

Here is the link : https://fr.slideshare.net/ltearno/easing-offline-web-applica...

Thanks for sharing.

I do not miss GWT but I think it was inspirational.

Ive also gone the negative key route, and would move to a "client dictates the key via UUID" like you mention if I redid it today.

Why? I have done this before and found negative much easier to use and understand. UUID have the nasty property that deny easy debugging, logging or any kind of HUMAN understanding...

Some of that depends on the version of UUID you are using. v1 and v6 UUIDs with timestamps can provide very useful for debugging. Of course v1 are problematic with MAC address embedding and v6 still just "draft/experimental" with the IETF.

My offline-first apps I settled on using ULIDs, which have time stamps and put them first so that they sort lexicographically (such as when included in string CouchDB/PouchDB _ids), and I've been pretty happy with that. That timestamp up front in the first few bytes can help a lot in debugging/"human understanding" of about where the ULID fits in a log stream.

I can also tell you at this point way more than you care to know about storing ULIDs in Microsoft SQL Server to get decent clustered index behaviors.

The primary benefit is theres no post-hoc reconciliation you need to do where you re-write all the foreign keys and object ids. It greatly streamlines the entire process, and lets you eliminate a lot of code / potential bugs.

I found it make far easier to see what object are candidates for sync, and to know the original row in the server.

I think makes a diference if exist a master database or if is peer-to-peer..

Yeah peer-to-peer is a different scenario. I'm assuming traditional client-server.

What I like too, is that there is a datadog connector. It sends the number of VUs and we can correlate that in our main datadog board, viewing how the app reacts to the load.

With a bit of typescript wrapping, you can gain autocompletion quite easily...

I use it since 6 months to test a kubernetes micro service application. I love the model, when you write CODE for your tests. We code the tests in typescript.