On the socket.io integration and network layer agnosticity.

[akash-joshi]

I was thinking about the functionality of Rocketrpc, and why someone would use it. People would use RocketRpc primarily because of the client-side method call functionality we're demoing, and not because of the network layer we use. The original reason why I chose socket io was to sort of build fast and get to an implementation. Socket io also deals with HTTP, websockets, whatever we can think of - leaving us free to build.

However, RocketRpc is not a socket-io framework primarily, and I don't want to bind us to them. I envision a future where the network layer becomes pluggable as well - as we see a lot of network layers beyond REST, regular websockets popping up.

If we build extensibility for our underlying network layer now - that will lead to leaky abstractions with people relying on the extensions in a way that we can not predict. This will increase maintainability costs for things which do not primarily relate to the library, and will also make it difficult to make the network layer pluggable in the future.

Hence, I think we shouldn't build code which further exposes the underlying network layer - and also maybe roll back on the previous change around exposing the socket client, since future users might rely on it in unexpected ways as well.

Let me know if anyone has thoughts on this.