Fails in Cloudflare Workers

[coreybutler]

I'm receiving the following error when attempting to use this from a Cloudflare Worker.

The 'credentials' field on 'RequestInitializerDict' is not implemented.

Cloudflare makes it clear this is not supported in Workers.

This just started happening, so I suspect something has changed in this library, though I (unfortunately) do not remember the version I was using originally.

Here is a redacted example of how I'm using it:

const smtp = new ServerClient(env.POSTMARK_API_KEY)

await smtp.sendEmailWithTemplate({
      From: env.POSTMARK_FROM_ADDRESS,
      To: '[email protected]',
      TemplateAlias: 'account-deactivation-notice',
      TemplateModel: {
        company_url: `https://domain.com`,
        company_name: "Acme Inc.",
        name: 'Corey',
        product_name: 'Product',
        username: 'test_user',
        email: '[email protected]',
        support_url: `https://domain.com/support`
      }
    })

[ibalosh]

Hi @coreybutler

postmark.js is a NodeJS library, while Cloudflare has only partial support for it. Due that, we can not guarantee library will work with Cloudflare.

Details about this can be found in following tickets:

• Unable to send email template within Cloudflare Worker #123
• Run postmark on Cloudflare workers #96

Igor

[coreybutler]

@ibalosh I understand it is a Node module and Cloudflare's runtime is not 100% compatible with the entire Node.js runtime. However; that is not the problem here. The problem is this Node module uses the withCredentials attribute when making a request. That attribute is for browser requests. Many servers/proxies/providers block these requests when they don't originate from a browser because that combination suggests an attack (server masquerading as a browser). Bottom line, this is an API rejection, not a runtime error. It has nothing to do with Node.js.

I suspect this has to do with the axios dependency. That library is designed to be embedded in browser apps via bundlers. Though popular, axios provides a non-standard HTTP interface and does a lot of non-standard things for the sake of developer convenience. For example, it throws errors for legitimate HTTP responses (like 404's). That's just not OK.

Node.js has supported standard fetch for quite a while now. I implemented what I needed this way. I'd recommend replacing axios with it. Frankly, I don't see the point of this library in its current state.

[ibalosh]

Hi @coreybutler

Yes, we do use axios as http client, so yes, it's definitely an issue due to usage of axios.

However, we have chosen years ago axios due to wide compatibility, and throughout the years, it has proven it by lack of support tickets related to it. fetch is becoming more popular and more stable throughout the years, but keep in mind that our goal is widest possible compatibility. We do support a larger number of versions of NodeJS, which is our main priority, so switching to fetch is not an option for us, not yet at least.

We did make the library flexible though. It is built in a way that you can switch the client if you want fairly easily, so that wider audience can use it. There are customers who have did this which you can check out in previous topics above or here.

[coreybutler]

@ibalosh This seems contradictory, given how many compatibility issues there are with services like Cloudflare, Vercel, etc. Perhaps it was widely compatible years ago, but the half-life is starting to show. Currently, the library doesn't seem "widely compatible" at all.

Fetch is more than "becoming more popular and stable". It's been a W3C living standard since early 2015 (i.e. it has been the standard for 9 years). As someone who supports every version of Node for tens of millions of users, I can confidently say there is a significant push towards using newer versions of Node where fetch is standardized. Deno/bun had fetch right from the start.

Sure, replacing the HTTP engine is possible, but that defeats the point of this library. It is easier to write fetch statements than to try to rig up a custom HTTP engine for a single library. So again, I don't see the point of this library in its current state.

Obviously, you can do whatever you want. I've worked around this, but when a workaround involves dropping the module from the stack, it's not ideal. I'd rather not do that, but it's the path of least resistance. I'd strongly encourage you to consider the consistent feedback you're getting about this from everal users sooner rather than later.

Anyhow, I'll drop the subject since I've added my $0.02. I hope you find this feedback constructive as it is intended.