Christoph Wille

https://github.com/open-policy-agent/npm-opa-wasm/blob/3e618c84a07ba3af8d7bab75eb77395bd79d7c54/src/opa.js#L267 this library mimics what npm-opa-wasm does in terms of execution order.

Yes (and I just saw that npm-opa-wasm has applied memory fixes recently, so I'll have to take a look at their recent history too) Edit: opened #38 for mem fix...

Can we somehow unit test the behavior?

https://github.com/open-policy-agent/npm-opa-wasm/commit/f1be838de45e3310e7c37bcebbfa387ac17c4db3 corresponding JS impl

Regarding runtime: I did change the runtime once (Wasmer to Wasmtime) and I had to change my object model for a couple of major Wasmtime changes. Those were super-breaking changes...

Regarding serialization: what would be a real-world use case to not use STJ? For Web APIs, I understand the use cases. But deserializing for from/to OPA wasm is very specific...

Regarding DI/policy provider: I have a very old prototype in the spikes folder - AspNetAuthZwithOpa (actually that was the initial reason to build this whole library, but never got around...

Which calls specifically accept an object? (eval and setdata take strings in the current api surface)

So mixing the "metal" layer with a "convenience" layer. The current method signatures play along the lines of the JS API. And I want to keep it simple at the...

I have cooked up an unfinished draft of how a Factory could work: https://github.com/christophwille/dotnet-opa-wasm/tree/master/spikes/HigherLevelApisSpike - start at Program.cs plus the comments in the IFactory... file. The idea here is that...