Separating networkInterface logic and implementation in favor of supporting more network interface types

(Continuation of #749)

So Generally, my finally goal, is to be able support more then just HTTP for apollo-client, starting with websocket in the near term and maybe HTTP2 in the future.

So, IMO we need separate networkInterface generic/common logic (such as middlewares/batching) from the implementation logic (Http fetch in that case). to do that, the following steps should be taken:

1. Make middleware/afterware generic (GraphQL and not networkInterface)

   • Suggested interface:

     export interface ResponseAndOptions {
             interfaceType: string;      // string indicating which transport layer is used.
                                                     // afterware might treat response differently depends on that.
             result: GraphQLResult;  // GraphQL parsed response
             response: IResponse;    // GraphQL raw response. (Optional, depends on interfaceType)
             options: RequestInit;
     }
     

     NOTE: if the transport layer response is sent to middleware, then middlewares should be able to support errors chain as well. (next(err) should work), else, what/how would you like it to validate?

2. separate the logics (I have a draft which i still need to work on, but now i got one step back), which means:
   • common networkInterface logic will reside in genericNetworkInterface abstract class which will provide an abstract protected/public method to do the network specific operations.
     • for example, HTTPFetchNetworkInterface will inherint the genericNetworkInterface, and then implement just one function which will send the actual fetch.
   • batched interface will become abstract as well and will extend genericNetworkInterface to provide abstracted batching logic.
   • Another class (HTPPFetchBatchedNetworkInterface) will inherit batchedNetworkInterface and implement the same exact fetch as above.

from this point, i believe that adding more and more networkInterfaces will be easier as it is much more generic and all that needs to be done to add an interface is to provide 1 function. also, IMO, this approach will make it easier in the future to release networkInterfaces as different small packages.

[stubailo]

BTW, the answer to this is https://github.com/apollographql/apollo-link

[stale[bot]]

This issue has been automatically closed because it has not had recent activity after being marked as stale. If you belive this issue is still a problem or should be reopened, please reopen it! Thank you for your contributions to Apollo Client!