Ideas to unblock usage in deno? about magic-admin-js HOT 4 CLOSED

🚀 Issue was released in v1.4.0 🚀

from magic-admin-js.

I'd like to be able to use Deno as my backend with Magic, but currently it doesn't seem to be possible. The main blockers I saw when I briefly tried it were a bunch of exceptions on import from ethereum libraries for node.

I'm open to a PR enabling Deno compatibility, but as you mention it may take some work to pull this off. It might require us to maintain these crypto functions internally, which is a trade-off I'm willing to consider. If the community is interested in helping us out here, we'd be grateful! 🙏

I'm wondering if it might be feasible to change this however? Maybe some of the crypto operations could be moved behind the Magic provided rest endpoints that the SDK already calls?

This is an interesting idea, but would be a little bit counter-productive to the long-term vision of our security model. We are working towards a decentralized system that centers less trust in one authoritative entity, even Magic itself. By putting more emphasis on a trustful connection to our API services, especially for something as low-level as cryptographic recovery functions, I see that as going backwards. 😓

This would also unblock integration in backend languages/environemnts that Magic hasn't provided SDKs for, of which there are still plenty other than deno.

You're definitely right, but we're not trying to do the "easy" thing. We are maintaining a growing list of backend SDKs through the efforts of our engineering team as well as contractors with domain-specific knowledge. In the case of Deno, we don't currently have a resident expert, but we might be interested in hiring one! This is where I'm hopeful that the community can show us the way! If it would be possible to maintain the Node and Deno-compatible code in one place, that would be just chef's kiss! 👨‍🍳👌

from magic-admin-js.

I've been looking into https://nats.io/ lately, and found that they have a pretty cool approach to node/deno cross compat, basically by using the Deno version as the base implementation (i.e. using ES modules and standard web APIs) and then laying a small compatibility layer on top of that for node support, since node now supports ES modules and many standard web APIs today: https://github.com/nats-io/nats.js#contributing

Just thought I'd leave this as a reference for if/when you guys start working on deno support.

from magic-admin-js.

I believe this issue is also blocking the use of Magic with Cloudflare Workers and Fastly Edge@Compute. When building for CFWorkers I see unsupported dependencies for assert, events, and stream coming from a few Eth libraries as well as core nodejs modules.

I didn't see this repo relying on any of the core modules specifically so should we be focused on fixing the compatibility issues in the dependencies like ethereumjs-util and eth-sig-util?

Edge computing is increasing in popularity and it would be a shame for Magic to miss out on that. I'm sure there is a way we can achieve the long-term vision and edge support.

from magic-admin-js.