[RFC-6] Using Protocols in favour of structs and classes

[maticzav]

The first and the second version of SwiftGraphQL relied on send and listen functions to perform query calls and subscribe to subscriptions. We noticed that we were making presumptions about which HTTP library people would use and the go-to socket handling library in the Swift ecosystem as we were implementing them. This RFC aims to introduce features that would allow developers to choose their client of choice and harness only the best parts of SwiftGraphQL - query building and response decoding - by introducing a new design paradigm - protocols.

Query building

Internally, SwiftGraphQL performs each send-request in three steps.
We create an URLRequest from the selection.
We send that request to the given server.
We decode the response.
Considering the steps more carefully, we can see that only the first and the last step are related to SwiftGraphQL's core functionality. To achieve greater flexibility, we should thus develop the middle stage independently.

Having this in mind, we can outline the goals of this RFC:
Developers should be in complete control of the network requests,
SwiftGraphQL's core library should only be responsible for query building and decoding,
API should be readily applicable to any networking library.

Proposal

To address the first goal, we would declutter send and listen parameters by extracting all the functionality related to networking into a separate protocol.

protocol HTTPClient {

}

This way, developers would implement conformance to the HTTPClient protocol and, in return, gain a send method that would handle the creation of the query and its decoding. We'd take a similar approach with the socket client. It's important to note that we want to make send and listen methods easily extensible. SwiftGraphQL shouldn't care about the server endpoint, headers, authorization - anything.

struct Network: HTTPClient {

}

Other changes

By removing the flexible parts from the core, we give developers more control. Yet having more control over the execution might be daunting to newcomers and cumbersome for exploration. That's why we should provide default implementations of the HTTP and WebSocket clients as a standalone package.

By separating the execution of the request from query manipulation, we've also set the ground for caching mechanisms and custom networking layers. That shall come together neatly in the future.

• https://github.com/jaydenseric/graphql-multipart-request-spec