Apollo-ios: Networking Beta: Convenience constructors for HTTPRequest and JSONRequest

Created on 21 Sep 2020  路  8Comments  路  Source: apollographql/apollo-ios

In my use case i have to append to the URLRequest.query before a request is actually sent and that was fairly straight forward with the old network stack using HTTPNetworkTransportPreflightDelegate.networkTransport(_:willSend:)

With the new network stack things have gotten a bit more complex but i was able to come up with a solution involving a custom ApolloInterceptor that turns a given JSONRequest into a custom subclass which overrides toURLRequest().

So to make implementation of custom HTTPRequests more easy i suggest you to add some convenience constructors for HTTPRequest and JSONRequest that take a single argument of their own type. This would let me get rid of this bunch of constructor arguments like this:

        let customRequest = CustomJSONRequest<Operation>(jsonRequest)

instead of this:

        let customRequest = CustomJSONRequest<Operation>(
                operation: jsonRequest.operation,
                graphQLEndpoint: jsonRequest.graphQLEndpoint,
                contextIdentifier: jsonRequest.contextIdentifier,
                clientName: jsonRequest.additionalHeaders["apollographql-client-name"] ?? "",
                clientVersion: jsonRequest.additionalHeaders["apollographql-client-version"] ?? "",
                additionalHeaders: jsonRequest.additionalHeaders,
                cachePolicy: jsonRequest.cachePolicy,
                autoPersistQueries: jsonRequest.autoPersistQueries,
                useGETForQueries: jsonRequest.useGETForQueries,
                useGETForPersistedQueryRetry: jsonRequest.useGETForPersistedQueryRetry,
                requestCreator: jsonRequest.requestCreator
                )
networking-stack

All 8 comments

The override is the correct way of doing this - I'm not quite clear why the super init, which has a bunch of default parameters, isn't the way you're doing this, though. Can you go into a bit more detail on that?

When looking for a way to get my CustomHTTPRequest with its overriden toURLRequest() into place i learned about the concept of ApolloInterceptor in the new network stack architecture.

Therefore i have implemented a custom interceptor to replace the original HTTPRequest instance with one of CustomHTTPRequest as a substitution. Basically what i'm trying to do here is to create a copy of the request _with whatever particular values its properties have_ but extend its original functionality.

If there is something i have misunderstood or a better approach to achive this i'm glad to get enlighted.

OK! I think I see what the problem is here: While the RequestChain can take an arbitrary subclass of HTTPRequest, there's no way to say "You should use this specific subclass" from the level of the RequestChainNetworkTransport, so as of right now you're having to recreate the request at the interceptor level.

It sounds like the issue is that there needs to be a way to specify the request type that's customizable at that level, so that you can actually use the custom type you've created.

Does that sound accurate? I'm gonna poke at some ideas on this.

Indeed, if subclassing HTTPRequest is the intended way to go, a more simple way to place that type into the processing is greatly appreciated.

@knox Please see #1405 . You may have opened a trapdoor to a bigger change but it's a good one 馃槃

Wow i didn't mean to ask for moving mountains but opening RequestChainNetworkTransport and constructRequest(for:cachePolicy:contextIdentifier:) seems to perfectly fit my needs.

Haha, this worked as designed: You pointed out that I hadn't provided an access point to something, so I added it. Then by adding it I realized something else that was annoying me could change. 馃槆

With 0.34.0-rc.2 i was able to implement a clean and simple solution to my use case.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

maxsz picture maxsz  路  4Comments

hiteshborse12 picture hiteshborse12  路  4Comments

plm75 picture plm75  路  4Comments

jeromeDms picture jeromeDms  路  5Comments

uericw picture uericw  路  4Comments