Okay... a few things are being conflated here... A websocket connection is a stream connection to a server... that's it.
From there, you can use different queuing patterns for relaying messages to other connected users, but that process will widely vary. While this does discuss the different patterns for communication, there's several missing and others that are not spelled out that well.
While Off-topic better examples can be found in the 0mq introduction and documentation, or for that matter RabbitMQ. Lately I've found that most of these patters are better implemented behind Redis with filters against connected sockets for relay managed by the application if needed.
YMMV.
My only/biggest concern with DateTime libraries, after seeing how bloated moment is, especially with the timezone info, is how absolutely huge these things can be/get. Curious how big the bundle size is.
I know very few are bundling via Deno currently, but can see it becoming a popular option in a couple years.
Should note that an `async function` *ALWAYS* returns a promise... I often see things like...
async function foo() : Promise<bar> {
return new Promise(...)
}
Because of a lack of understanding of this simple fact, which seems to be amplified with the typescript typing of Promise<T> in the declaration.
One niggle with the post. IndexedDB's API was really meant to be a groundwork API and the expectation was that libraries would be built on top of that to make interactions easier to deal with for front end developers.
somewhat useful package... I usually just put the following at the top of js modules that need it..
const delay = ms => new Promise(r => setTimeout(r, ms));
Then I can use `await delay(10)` or whatever in practice. Often after file operations, so they can sync up before continuing (more for windows antivirus, etc) in node... or to slow down certain operations in a browser.
I will also use this when stubbing API clients when the server-side isn't ready, or similar on the server to simulate longer loads to check UI/UX behaviors.
I think about the only time I ever use defer method these days is with something like zxcvbn, that is massive. I have a wrapper (asdfgh) that waits for it to be loaded, and handles this for me.
I do like the import() function since it's in browser pretty much everywhere at this point... I don't really worry too much about supporting legacy browsers these days. ES2020 is generally a safe to use target at this point. I also realize that some people will disable JS altogether, and while I understand the sentiment, it shouldn't apply to applications.
Appreciate the article... and I agree, redis is very cool... I've used it for sequence generation, caching, pub/sub and queues. This article off topic though.
I just removed the other two posts since this one had conversation... the author keeps posting about this library via differing venues though.
Not a huge issue... just gets a bit over the top sometimes.
Should note that an `async function` *ALWAYS* returns a promise... I often see things like... async function foo() : Promise<bar> { return new Promise(...) } Because of a lack of understanding of this simple fact, which seems to be amplified with the typescript typing of Promise<T> in the declaration.somewhat useful package... I usually just put the following at the top of js modules that need it.. const delay = ms => new Promise(r => setTimeout(r, ms)); Then I can use `await delay(10)` or whatever in practice. Often after file operations, so they can sync up before continuing (more for windows antivirus, etc) in node... or to slow down certain operations in a browser. I will also use this when stubbing API clients when the server-side isn't ready, or similar on the server to simulate longer loads to check UI/UX behaviors.