You can't know everything that has been done in the past, or is being done and finished before you ended. But as far as you are not just cloning something that you already seen working, you can explore what you are capable of doing, for the sake of it, for the experience of doing it and make it work, for the things that you think are useful or nice or whatever in what you did.

And if all that effort don't end in something that can be sold, you still grow through the process. You are not ensured commercial success even if you try something truly new. But maybe that is not always a bad thing.

It didn't start out like that. Initially, it was just another WebSocket library with a focus on making it easier to scale to multiple processes.

It's kind of mind-bending to me though that it still feels like it's "too early." You'd think that the ability to efficiently process RPCs and pub/sub messages from clients whilst maintaining ordering would be critical... Yet if you look around the industry; callback-based event handlers are still the norm for most application logic and people are still not using queues where they should be. People think of queues as some expensive/bulky system with overhead which requires additional architecture (e.g. RabbitMQ, Kafka, STOMP, NSQ) and always requires exactly-once delivery, they have not tried to make the idea a core part of their application logic. Software today is FULL of race conditions because of this blind-spot. Yet I still cannot communicate my message. It's too difficult to explain the benefits.

But know what's really fun? Taking something that's been done before, has been forgotten about, and can be iterated on with your own spirit. There's so much exploration to be done.