Oh nice, I will take a look. I just today finished implementing my own JWT signing to be able to access Google’s cloud logging API (which we use for our other servers, but doesn’t work with just a simple API key). That was after giving up in frustration yesterday because all the different libraries I tried didn’t work. Then again, I ended up with just a page of code using crypto.subtle and not a 500KB minified monster. I like small and zero dependencies ☺️

Yeah.. one of my mantras is you don't import dependencies, you adopt them..

No thanks I’ve got enough kids already 😂

I hear you! 😄

Hi guys I am manically researching workers and durable objects these days, and I have two noobish questions to open with 1. Is there anything stopping me from uploading a WASM module to a durable object like i would with a normal worker 2. If there isn't... are there any reasons to avoid it? (Btw - I've done some basic examples of durable objects and websockets, but WASM on workers is still unexplored territory for me)

Noob question here, also. If I understand correctly - the only way that workers supports languages other than JS (node) is if those other languages can be compiled to WASM - or - if they compile to Javascript. I guess this would be taken care of using a Webpack configuration. 1) Is this correct? 2) If so, are any of those languages more suitable for the workers platform? i.e. performance - reduced overall CPU time / memory etc?

There are no noobish questions.. and 1: Nope, nothing stopping you AFAIK and 2: There is added complexity on top of JavaScript, but no additional complexity on top of regular workers I would think?

See above, no noob questions. Workers do support JavaScript, but not NodeJS (so you can't use the standard NodeJS libraries) and WASM. So you are correct the it can support any language that can compile to either of those.

I have no idea if any particular language is better with performance or memory when compiled to WASM tbh..

ty very much this is useful info

GC'd languages like Go and Python are not suitable for compiling to WASM today, usually transpiling to JS works better as then you can leverage V8's garbage collector. They have large runtimes that usually don't fit in the Workers size limit... The WASM community is working towards a GC that could be shared by language runtimes that would greatly help with this, but this is pretty far away at the moment last I looked into it.

Is there a limit on the number of open concurrent websockets an account can have?

So for example on the chat example is there a limit either A) on the number of concurrent websocket users you could have on any single durable object or B) the number of concurrent websocket connections you could have across different unique durable object but all under the same Cloudflare account

Good question. A) Chrome has a limit of 256 simultaneous websocket connections (per browser (!) not per tab) so there likely is some limit per DO. Wish all the limits were documented somewhere. B) I'm pretty sure you can have as many different DOs with websocket connections as you want

@UserThanks ! That makes sense.

@User so between the languages that compile to JS, I imagine there are variations in size and efficiency of their respective code generations - do you imagine their differences are negligible ?

In general on a paid plan I probably wouldn't be asking - but I'm just starting out on the free plan wondering how to manage 10 milliseconds of worker limits.

10 milliseconds might be a lifetime - but I'm not used to having to think about it. It's an interesting exercise for me.

10ms is actually quite a bit, as long as you don’t try to make a lot of IO invocations. And they don’t cut you off at 10ms, you have a bit of leeway as long as you don’t go over it consistently.

Pure JS and languages that are closely related like typescript will always be the best code size wise, transpiled languages usually have some level of runtime overhead to handle differences in semantics between the original language and JS, or to implement their builtins and standard libraries. Unfortunately I don’t know specifics about the various compile-to-JS languages/toolchains. (I’ve heard good things about rescript, but that’s about it)

@User that is encouraging - so I would have time to engineer the code to stay within certain bounds. I plan to go to a paid plan soon enough - but it's nice to be able to develop under a free umbrella.

Absolutely.. also, the paid plan is only $5/mo, so won't break the bank just yet

@Userhey, thanks - I'll at least check it out since I haven't heard of it.

you also currently need the paid plan to access the tech this channel is about

@Userexactly. I'm just trying to figure out now how to manage user authentication. Any suggestions on the best way to go - I'm not a full time developer( any longer). So I have to relearn all this stuff.

@User ah yes, good point - it's easy to get conversations off topic or accidentally posted in the wrong category. Thanks for the warning.

I wasn't meaning to be the on-topic police, just an FYI 😄

ah ! actually I'm also interested Durable Objects. I only have my imagination at the moment as to how they actually play in the work flow. I wonder if they can play a role in user authentication. I'm shooting from the hip right now.

Is it possible to connect thousands of websockets to durable objects and have them all share a single consistent state? Like say a counter of the number of connected clients

I might be missing something here but why would you connect them to different durable objects instead of a single one? i'm guessing what you want to do could be achieved with 21423412341 durable objects that each have a websocket attached, who in turn communicate with a singleton durable object whose only function is to coordinate states tho