You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's face it, our API might be clean (arguably), but it's cumbersome to work with.
IMO we should first figure out some use cases for our API to see how this is actually going to be used.
The socket-client component is quite lowlevel, so it's unlikely to be used by many users directly. It's probably more likely going to be used as part of some high level abstractions (say, a Redis or MySQL client implementation). See also https://libraries.io/packagist/react%2Fsocket-client/dependents
These high level components depend on a ConnectorInterface and will likely use DI to inject this. They probably care little about how the connector works. Neither should they care about any "additional" parameters. They do care about the target (hostname and port). Hence (IMHO) they should not have to take care of context options, connection timeouts or even selecting the "right" connector.
Afaict all they (essentially) need to do is to establish a connection to a given remote location. As such, I'm suggesting a simplified API similar to this:
// probably one of the most common use cases$api->createConnection('tcp://www.google.com:80');
// automatically assumes TCP transport, as does fsockopen()$api->createConnection('www.google.com:80');
// automatically picks use secure connector$api->createConnection('tls://www.google.com:443');
// create Unix domain socket, as does fsockopen()$api->createConnection('unix:///var/tmp/demo.sock');
The implementation of such a facade would be pretty easy, it could accept a Connector and SecureConnector (or any other classes implementing the ConnectorInterface for that matter).
This facade would probably become the one class that every consumer of this component is going to use. The other classes should probably be left as-is and can still be used in advanced scenarios.
The text was updated successfully, but these errors were encountered:
Let's face it, our API might be clean (arguably), but it's cumbersome to work with.
IMO we should first figure out some use cases for our API to see how this is actually going to be used.
The socket-client component is quite lowlevel, so it's unlikely to be used by many users directly. It's probably more likely going to be used as part of some high level abstractions (say, a Redis or MySQL client implementation). See also https://libraries.io/packagist/react%2Fsocket-client/dependents
These high level components depend on a
ConnectorInterface
and will likely use DI to inject this. They probably care little about how the connector works. Neither should they care about any "additional" parameters. They do care about the target (hostname and port). Hence (IMHO) they should not have to take care of context options, connection timeouts or even selecting the "right" connector.Afaict all they (essentially) need to do is to establish a connection to a given remote location. As such, I'm suggesting a simplified API similar to this:
Also, once we support Unix domain sockets (#37):
The implementation of such a facade would be pretty easy, it could accept a
Connector
andSecureConnector
(or any other classes implementing theConnectorInterface
for that matter).This facade would probably become the one class that every consumer of this component is going to use. The other classes should probably be left as-is and can still be used in advanced scenarios.
The text was updated successfully, but these errors were encountered: