mtth / avsc

Avro for JavaScript :zap:
MIT License
1.28k stars 148 forks source link

Issues with Cloudflare Workers/Pages #401

Closed raveclassic closed 2 years ago

raveclassic commented 2 years ago

Hey @mtth! Thanks for this awesome library!

I'm currently trying to set up some encoding/decoding processes in a Cloudflare Worker environment. Basically it nails down to encoding jsons on the server side and encoding them on the client side. The pitfall is that Cloudflare Workers are running pure V8, not Node, so most of avsc internals don't work out of the box due to missing Buffer, missing utils package etc. I am able to polyfill them in my bundler so that altough bundle size increases quite a bit, it's still fine for the POC, let's skip this part for now. The main issue with avsc is that it heavily relies on new Function contstructor and building functions from source code directly in runtime. Unfortunately, due to security reasons, Cloudflare does not allow such things in worker environment, so the code below throws: https://github.com/mtth/avsc/blob/c639014507f08dbbdffecae8ccae0118390d13f8/lib/types.js#L723-L736 var Branch = (new Function(body))(); - throws EvalError: Code generation from strings disallowed for this context, this error is specific to Cloudflare and how they set V8 up.

So the question here - without digging too much in the code and purposes of these "branch constructors", is it even possible to eliminate this in avsc? What are the reasons for having such function constructors? Is it performance or something else?

Thanks! Really looking forward to seeing avsc work in Cloudflare Workers!

mtth commented 2 years ago

Hi @raveclassic. Code generation is not currently optional, unfortunately for your use-case. https://github.com/mtth/avsc/pull/223 was opened a while back to support this feature but is still pending. https://github.com/mtth/avsc/issues/221 is also related.

What are the reasons for having such function constructors? Is it performance or something else?

Right, performance. The dynamically generated functions provide a ~10x speed boost over the static alternative (the PR linked above has a few numbers if you are curious).

W.r.t. next steps, I am still happy to review a PR which implements this as an optional feature. It's a rather large change though so will require a non-trivial amount of work to do well. I can provide a few pointers on where to start if you/your team are interested in picking this up.

mtth commented 2 years ago

Closing this as the improvement is already tracked in #221.