But the actual Node.JS packages aren't supported (like

fs

and

http

) and I don't know if they ever will be.

One of the things I truly “need” is the dynamodb package and I think I saw a workers example using it

So is that not possible with functions today?

Oh, AWS' SDK works fine in Workers (and I'm pretty sure in Pages too I think). You just need to make sure to use v3, that's all.

Okay, that's one of my core dependencies. the others I think I can work around... but not ideal. That at least puts it back on the table as an option I guess, but still a lot of work to "convert". 😄

😄

You could always try DynamoDB's HTTP API... There's this for authenticating without sorting out all of the confusing auth details. It's what I do. https://github.com/mhart/aws4fetch

Crap, I just remembered I also have a dependency on ZMQ which looks like it'd probably not be great to re-write nor would it work as written. -_-

To be clear, I don't need the daemon side. I know that workers don't work like that. I need to be able to connect to a socket on the other side and use ZMQs framework to communicate out.

So I guess it's off the table again. 😄

Yeah, I don't know if you'll even be able to rewrite that. Worker's don't allow sockets right now, although there was a blog post late last year so it might be planned.

HTTP only for now, even outgoing.

I guess I could queue up messages in SQS and have a lambda with proper node support handle them. But then it's like... at what point does this start not making sense to do.

Is there a list of these known "caveats" with functions and/or workers? I've been reading the cloudflare docs since we've been talking and it's... lackluster at best. For example, there is a page here that talks about using sockets? https://developers.cloudflare.com/workers/learning/using-websockets/ I think it's correct to say that functions don't have feature parity with workers either?

Do you just have to try it and find out it doesn't work? 😄

No, that's for Websockets. Websockets work fine, it's TCP sockets that don't. Sorry 😄

And yeah, WebSockets should work fine in Functions I think? Functions is currently running a really old runtime since it's in Beta so not entirely sure.

Ahhh, case of me being dumb

Trying to wrap my head around all of the roadblocks I will hit now and might hit in the future.

Yeah, no worries. 🙂

I realllllly like the idea of workers. I really wanna make it work.

Right now I'm using ECS to host the API in a container

Cool, bet that gets expensive though 😦

Yeah, no doubt. Especially with AWS' bandwidth costs.

Part of why "your code runs in 200+ DCs" sounds lucrative. Low latency. Impossible to "take down"

Yeah, Workers are amazing. 😄

Thanks for your time and help by the way; really appreciate it. I'm still fumbling around on if I have the time and willpower to switch. I'll probably be back. 😄

No worries, let me know if you have any more questions 👍

I did come up with another theory you might be able to shoot down 😂. So I’d like to at least use pages for the time being. My api is at

/api

and short of paying for the enterprise plan; there is no “pre-built” solution for path based routing. Workers however does have the same feature it seems as the resolveoverride in the enterprise page rules: https://developers.cloudflare.com/workers/runtime-apis/request/#requestinitcfproperties It seems like I can just create a page function to effectively do the same thing. Does this sound like a viable way to do “redirect” said traffic? Or is there a better way to route the traffic for

/api

to a completely different host?