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.
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.