Writing a toy WebSocket server from scratch
alexanderell.is
alexanderell.is
OP says:
> Goal: write a basic server that can handle the WS handshake and parse an incoming WS frame to see the message sent from the client
> Non-goals: writing a robust or real HTTP server, writing a fully compliant WS server, or handling all edge cases
This is a great way to get started with something that you don't yet understand. I sometimes think of it as implementing "just enough to trick people into thinking that it works".
FWIW, I think the implementation in this post has a bug whereby a client that sends half an HTTP request will block the entire server from accepting further connections, because handle_request() makes blocking calls to recv() until it has a full request, and the program can't accept new connections until handle_request() returns. That's the spirit!
It's interesting to see what different people mean when they say "from scratch". In this case the lowest abstraction is (what seems to be) Python's TCP library.
But you are correct in that websocket support can be written directly on top of tcp (without http) for greater performance.
Otherwise the dude would have given up before it's complete.
No one on their own should aim at building a "cathedral". Build a hut. Then add a toilet cause it sucks to shit outside. Then a sewer system because it stinks. A tap to wash your hands. Might add a bed to sleep overnight. Make that a bedroom. Ok now it needs a shower.
2 years from now you have your "cathedral" and other people come shit in your toilet, so making it squeaky clean becomes a priority.
People tend to forget the word software has "soft" in it.
Nice way to look at it!
OP seems to have enjoyed making a toy websocket server. I highly doubt they want to turn it into something bulletproof. It seems they just wanted to learn and make a cool blog post.
Fun weekend projects are usually things you can quit or modify.
When one of them gets attached to a real goal, you get stuck reinventing 50 wheels, and if any get tedious, or the tech you wanted to learn gets obsolete, it's much harder to drop them, you get sunk cost fallacy stuff, etc, plus you can't try random stuff.
You have to use a toilet. You can't make a paper mache tuba and shop vac contraption on a project meant to succeed.
If someone is going to slowly build a cathedral, I think that works best with something that has a reasonable MVP.
The only WS server I would choose is one of the top most bulletproof ones in the language I was using. Until you reach that threshold, the product is a terrible idea for anything practical.
If you want to make a WS server for fun, you probably want to go just far enough to learn some stuff and then stop, because a practical one takes months(Unless you're one of those NIH nuts that would rather use something small and DIY than something reliable).
I suspect that the lack of expectations is why so many people seem to enjoy these weekend projects, and why I pretty much regret literally 95% of them, and feel that they were just time drains I didn't enjoy at all.
I expected DIY projects to actually be part of my future goals, and did crap like building light fixtures instead of buying DMX lights.
I learned some things in the process, but I didn't actually start getting closer to where I want to be in my career till I learned to stop, and that nobody cares what tech I invent, they want stuff to work, and they want people who know how to use the stuff they already trust.