That is worth a try indeed!

node-jose

works great!

I use it in

@glenstack/cf-workers-access

which verifies the JWT from Cloudflare Access.

First item on https://workers.cloudflare.com/works 😉

Worktop is gunna offer its own module. It was going to be part of 0.6 but I didn't wanna delay it further. Core is done, just adding more algo support

You’ll need this rollup plugin, likely: https://github.com/ionic-team/rollup-plugin-node-polyfills

I'm a bit confused by Websockets with Durable Objects... how does that work when workers is limited in execution time?

thanks, yeah we're trying this!

Thanks, I gave that a read but that still doesn't quite make sense to me, the websocket would be persistent, exceeding the extended cap?

There's a few things at play here. The new 30 second limit is a CPU limit, idle connections don't burn CPU time. Also Durable Object's limits are "re-upped" when new connections come in, keeping the object alive for longer. Additionally, any websocket code will need to be resilient to disconnects anyway, so client side code should reconnect if for some reason the Durable Object instance was killed or relocated anyway.

Ahhh, I see... so every websocket message refreshes that timer, and the max execution during that execution is still 30s?

It's actually 500ms while we're in beta -- but rememebr that is CPU time and not wall clock time, see here: https://community.cloudflare.com/t/2021-4-23-workers-runtime-release-notes/263246/2

🤔 Afaik the 30s is duration, not CPU limit. However, I can confirm that if your DO gets more requests it lives much longer.

Oh okay, thanks! We're looking to use this for a new project.

An open websocket connection would keep it alive. A regular non-DO Worker can already spend (for example!) <1ms of CPU creating a subrequest to a website, that website could spend 10 minutes of wall time working on its response, and the Worker could finally return that response to the user. The limit is CPU time.

@User That's extremely helpful example!

Thanks!

For Bundled plan its CPU limit, but for Unbound its duration, at least thats how I understand the limits now

So DO is some combination between Bundled and Unbound limits?

That's also how I explained "how long does DO live after the last request?" in my head, simply until the duration limit is reached, which is 30s. If any new requests come in, they refill the budget with another 30s

However it would not make sense for open websockets connections to close after 30s, mmmm, seems I am a bit confused now 😅

Yeah, an open websocket connection will keep a DO instance "live" (aka transient in-memory state is kept live) up until you hit the DO's CPU limit, which can be re-upped by new connections. The fact that a DO's transient state can vanish after it doesn't receive requests for a period of time is unrelated.

I am but a lowly engineer and not a PM so I should probably wait for someone else to describe whether that would be considered Unbundled officially or not 🙃

I see, I think I am on the “I understand” wave once again, thanks for the explanation!

So wait... if a DO doesn't recieve requests for a while, it will disappear?

I guess we could stick the DO into KV and if it isn't found, grab it out of KV maybe?

Only it's in-memory state: https://developers.cloudflare.com/workers/learning/using-durable-objects#in-memory-state-in-a-durable-object

Oh.

So it still is persistent then.