PR https://github.com/sholsapp/gallocy/pull/36 adds a lot of duplicate code because we haven't decomposed the client and transport classes into the core parts. We need to fix this, pronto, so that we can continuing trying out new transport classes.
Using an abstraction that would let us instantiate a client like this would be a nice approach.
Here I think we could maintain clean separations of concern:
Application layers (e.g., HTTPClient) would take care of all of the application level stuff. It would take in or build a request object, then hand off a byte buffer to the next layer.
Logical layers (e.g., RobustClient) would take care of random tasks like retrying failed request. It could also implement some of the Raft-specific "return when you have a majority of responses" logic.
Transport layers (e.g., RDPClient) would implement send and recv wire logic.
This might be overkill now if we use the daemon approach, at which point we can just depend on some third party library to do all of this for us. Anyway, let's just brainstorm and have a conversation around it.
PR https://github.com/sholsapp/gallocy/pull/36 adds a lot of duplicate code because we haven't decomposed the client and transport classes into the core parts. We need to fix this, pronto, so that we can continuing trying out new transport classes.
Using an abstraction that would let us instantiate a client like this would be a nice approach.
Here I think we could maintain clean separations of concern:
This might be overkill now if we use the daemon approach, at which point we can just depend on some third party library to do all of this for us. Anyway, let's just brainstorm and have a conversation around it.