Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cloudflare workers-rs Support #22

Open
albertocavalcante opened this issue Jan 17, 2025 · 3 comments
Open

Cloudflare workers-rs Support #22

albertocavalcante opened this issue Jan 17, 2025 · 3 comments

Comments

@albertocavalcante
Copy link

Does this SDK work with Cloudflare workers-rs?

It currently does not support tokio or async_std as per https://github.com/cloudflare/workers-rs#notes-and-faq.

Considering async is not supported in the workers-rs construct, I tried to use the SDK with the blocking feature but couldn't get a working example yet. I think would be nice to have a reference example in the docs as well.

@AntoniosBarotsis
Copy link
Collaborator

AntoniosBarotsis commented Jan 17, 2025

I will need to investigate this as I've never touched wasm before. From a quick look here I assume that a passing

cargo +nightly build -Zbuild-std=panic_abort,std --target wasm32-unknown-unknown

build would mean its fine? If that is the case then adding getrandom = { version = "0.2", features = ["js"] } to resend-rs seems to fix the build. This is mentioned here.

I'm not sure if more work needs to be done for this to work (would not be surprising at all) but on the surface this sounds like a good thing to support, though admittedly I am unaware of what sort of things don't work with wasm. The rand library was already surprising but understandable.

I assume you have more experience on the matter, is this change enough or is there more things to look into? The faq doesn't make it seem like async automatically means it doesn't work either (unless I misinterpreted something), just that the wasm target is more restrictive and that things may not work but if the above build succeeds isn't it fine then?

@AntoniosBarotsis
Copy link
Collaborator

I did some research to see what the issue is; it seems there's 2 at the moment

  • async seems to be fine actually, sync causes issues with reqwest (the HTTP client I use internally) because they do not define single threaded code for wasm from what I understand (since JS is single threaded, that would freeze everything, they want you to use async instead). This is fine, it means you can just not use resend-rs's blocking feature
  • The other issue seems to be in the library I use internally for rate limiting (governor). It seems like there was some attempt by a contributor to support wasm but he dropped the pr 4 years ago. I'm not entirely sure about what causes the issue for them.

At the moment, this crate does not work with cloudflare workers because I always enable the rate limiting library for non-blocking code. As a temporary fix it could probably be disabled (code is only used here and here from what I remember) or better, made optional via a feature. This does complicate things a bit so I don't want to go that way if I can avoid it. I think I'll see if I can figure out what the holdup is for governor and whether it is realistic for me to fill the gaps, otherwise I'll probably just add the feature flag.

I'll unfortunately be busy for the next 1-2 weeks so I can't say yet when you could expect an update on this, likely within a month though.

@AntoniosBarotsis
Copy link
Collaborator

If this is something you need at the moment I could cut a beta version with such a feature flag that disables governor which probably would work, let me know @albertocavalcante

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants