ittysockets.com is about to cross 0.5M messages handled in the last week alone!
It's a public WebSocket service:
- without logins/auth (or payment of any kind)
- flexible enough to design your own messaging system
- with a client under 500 bytes
Built for devs to prototype on.
FUN FACT:
itty.dev includes several itty scripts in the console... with examples you can copy/paste right there to play:
That said, it's not like I'm pushing any boundaries at the moment... haha. I'm sure it has rough edges I haven't discovered!
What specifically you having issues with?
I generally haven't had much issue with local CF DX. Pretty wild that it works as well as it does TBH...
A few notes...
1. Every route can take N handlers. Each can return or not return (middleware)
2. Every handler is automatically awaited
3. The request itself is a transport, since it's always available
4. "Just returning" is the easiest pattern, since we do this the most
FUN FACT:
Tiny size isn't the strongest selling point of itty-router... it's how clean your code can look.
Removing virtually every shred of boilerplate while keeping it fast, Web Standards, and ultra-tiny was the original goal.
Here's a direct comparison with Hono:
I should note... while this API can handle load fine, you should only use something like this for prototyping/hacking stuff out, not in production.
Why?
Any latency adds overhead to your system, and this is nowhere close to as fast as just including your chosen uuid/id generator into your code!
I'll be adding in some of the usual culprits like uuids and nanoids as well...
Need some quick and dirty custom id hashes?
itty.id to the rescue :)
Full API help here: itty.id?help
The flipside is, obviously it solves some issue for some audience, or it never would have been built in the first place.
One could say the same for any of my byte-optimized libs... in a world where devs don't seem to care about bundle size, one could always ask: who cares?
A few do! :)
I mean I sorta see what they're getting at, but...
IMO it solves an edge case problem that I don't think stresses the majority of devs out (we expect *any* function to be able to throw)
...by converting arguably readable code into symbol soup, with added bloat per function.
By their own example:
Violence only creates more violence, hatred more hatred.
I fully believe the answer is to overwhelm each other (the good and the bad) with compassion.
It’s really hard to be shitty to a person who truly cares for you and shows you kindness.
When the majority of the workforce is out of work from the AI revolution, who will be buying the products/services still being sold?
That requires income that many will no longer have…
Ultimately much of our economy hinges on a massive consumer base that spends constantly. Without that, it dies.
Inspired me to play… 🍻
edit: <100ms, lol.
This is all available for anyone else to play with, explore patterns on, etc.
ittysockets.io
The client is tiny (<500 bytes), and uses a standardized public backend. You can send/receive any message format you need (within reason) for your app!
Go check it out!
Since everyone is already connected via socket, the latency is reduced to a few ms (typically under 9ms) for messaging, allowing incredibly fast back-and-forth systems like this - which would be impractical/slow via REST/HTTP.
6. When the user receives a state message in response, they decode it and apply it to their board. Now they are fully synced with the users!
All in all, a typical time from component mount to fully synced takes between >100ms. This is often WAY faster than a round trip to some sort of API layer.
5. If a user receives a "request-state" message, they immediately encode/compress their board (takes about 1-2ms) and sends it.
3. Since every new player will need the board state, each existing player responds to the join event with a welcome message to that user.
4. That user listens for welcome messages, and responds to the first one (fastest), asking for the board state.
Let's assume someone is already in the channel with a drawing/board.
1. You join.
You as the joiner have no idea who is in the channel (just the number of players).
2. However, when you join, everyone in the channel is notified of this (standard event in ittysockets.io).
Still playing with this little ink demo... and I'm loving this concept of hybrid p2p state sharing.
Basically there's zero backend - the boards are shared between players only. That has limitations, but it's also SUPER fast.
Here's how it works.
itty.af incoming.
🤫
Seriously. Was it wrong/punishable for them to criticize Biden? I don't understand how folks can see one side, but not the very obvious reverse?
It's like our brains now just process one side of an equation and ignore the mismatch... :(
The only 3rd-party component/UI in my entire trading app...
...the glorious @simeydotme.bsky.social sliders (still on v3, if you can believe it!)
This component is SUPER flexible, and SUPER sexy. The end effect is unmatched IMO. 👌
Cool things about itty-sockets:
- auto stringifies/parses payloads
- WebSocket race conditions solved
- message queuing built in
- event handlers are resilient through disconnects
- it's insanely small (~480 bytes)
I will eventually re-release the generic ws (not ittysockets.io) version again :)
And by all means, if you agree/disagree, def let me know [why]! :)
Another example:
