Header configuration + Fix GET with null parameter #602

designatednerd · 2019-07-01T20:48:20Z

I know this has been a request for some time, but this PR contains the ability to change parameters on the URL request before it gets sent out, the ability to have the raw Data?/URLResponse/Error? response from a URLSessionTask so you can grab headers and/or log things as you want, and the ability to retry asynchronously (for example, after re-authenticating).

This work also uncovered some weirdness with sending GET requests with null parameters for optional variables, so I broke out the GET url constructor, simplified it, and tested it.

martijnwalraven · 2019-07-01T21:11:15Z

Sources/Apollo/GraphQLGETTransformer.swift

+
+import Foundation
+
+struct GraphQLGETTransformer {


Breaking this out and testing it is a great improvement. Just wondering why you decided to make this a struct instead of a top-level function. Were you thinking of extending this with additional methods or multi-stage building in the future?

I prefer to make things named structs/classes/enums instead of free-floating functions. This is partly to make it easier to break things into additional methods in the future, but it's mostly for clarity of where the hell something is coming from.

martijnwalraven · 2019-07-01T21:18:10Z

Sources/Apollo/HTTPNetworkTransport.swift

@@ -1,11 +1,32 @@
 import Foundation

+public protocol HTTPNetworkTransportDelegate: class {


I've blocked this way too long and I want to leave it to you to decide what to do, but in the past I've seen it as a hard requirement that our solution should also support retries on error and token refresh, which probably requires at least some callbacks to be asynchronous. See here for the way Alamofire supports this for example. Maybe it would be enough to make shouldSend asynchronous?

Here are some other previous ideas for delegate methods: #257 (comment)

There was also this idea about propagating custom attributes from client API methods in a context argument: #257 (comment)

Not saying you should do anything with this, I know I've probably made it too complicated in the past :)

retries on token error and refresh is supper useful, we have that in our code. Helps with wrong dates on client and token format changes on server

I based a bunch of this on your suggestions here.

What am I missing about Context that wouldn't be covered by just altering the Request object?

I'm gonna take a look at making response handling a separate delegate, since not everyone who needs request handling needs response handling, and optional delegate methods require all sorts of objc nonsense.

I'll admit that I'm kiiiind of reluctant to do custom retry logic due to the additional complexity, but I'll see if I can make that work.

Response handling and retry delegates have now been added.

Oh, I missed this before, but to answer your question about Context: this would allow you to pass in additional data from ApolloClient methods like fetch (so per request, at the point of use), as opposed to doing it from the delegate. Probably not needed right now, but for context :)

designatednerd · 2019-07-02T09:26:41Z

@martijnwalraven Added a couple more delegates to allow retrying and/or handling the raw request + response

koenpunt · 2019-07-02T10:37:17Z

Sources/Apollo/GraphQLHTTPRequestError.swift

  case serializedBodyMessageError
  case serializedQueryParamsMessageError

  public var errorDescription: String? {
    switch self {
+    case .cancelledByDeveloper:
+      return "The request was cancelled by the developer using the HTTPNetworkTransportPreflightDelegate."


Not sure if this should mention "the developer", because then you could attribute almost all implementation to "the developer".

Maybe something like cancelledByPreflight with "The request was cancelled by the the HTTPNetworkTransportPreflightDelegate" is more suitable?

designatednerd · 2019-07-02T19:11:11Z

This is now out of Fake Draft Because You Can't Turn An Open PR Into A Draft PR status and is ready for review 😃

koenpunt · 2019-07-02T21:12:32Z

Sources/Apollo/GraphQLHTTPRequestError.swift

@@ -1,10 +1,13 @@
 /// An error which has occurred during the serialization of a request.
 public enum GraphQLHTTPRequestError: Error, LocalizedError {
+  case cancelledByDeveloper


I think the enum case should be changed too, for the same reason the errorDescription did.

koenpunt · 2019-07-02T21:13:04Z

Great to see some activity on this repo again, thanks!

martijnwalraven · 2019-07-02T21:08:25Z

Sources/Apollo/HTTPNetworkTransport.swift

+  ///   - response: [Optional] Any response received when the error was generated
+  ///   - retryHandler: A closure indicating whether the operation should be retried. Asyncrhonous to allow for re-authentication or other async operations to complete.
+  func networkTransport(_ networkTransport: HTTPNetworkTransport,
+                        receievedError error: Error,


Small typo, should be receivedError.

🤦‍♀️If i spell received right on the first try ONCE IN MY LIFE I will be happy.

martijnwalraven · 2019-07-02T21:18:35Z

Sources/Apollo/HTTPNetworkTransport.swift

 /// A network transport that uses HTTP POST requests to send GraphQL operations to a server, and that uses `URLSession` as the networking implementation.
 public class HTTPNetworkTransport: NetworkTransport {
  let url: URL
  let session: URLSession
  let serializationFormat = JSONSerializationFormat.self
  let useGETForQueries: Bool
+  let preflightDelegate: HTTPNetworkTransportPreflightDelegate?


I'm a little worried about a proliferation of delegate properties here. I can see the benefit of keeping these separate, but it may also be worth simplifying this to a single delegate property that can conform to any of these delegate protocols (similar to how URLSessions delegate can conform to URLSessionDelegate, URLSessionTaskDelegate, etc.).

The problem is that URLSessionDelegate et al are Objective-C protocols, so they can have optional methods. If you only want to implement method foo(), then that's all you have to implement.

Our Swift protocols can't unless we mark the protocol @objc, which has a ton of other knock-on effects we don't want. This means if you're implementing a single protocol, you have to implement ALL of its methods even if you don't need or even want them.

I agree that having to have things conforming to multiple protocols is annoying, but I think the separation of concerns (and the ability to avoid needing to implement EVERYTHING just to get one thing) is worth it.

Ah, I'm ok with having different delegate protocols, but what I meant was that we could still have only one delegate property. I believe that is similar to what URLSession's delegate does, so your delegate has to conform to URLSessionDelegate and optionally to URLSessionTaskDelegate etc.

URLSessionDelegate is the base protocol which inherits from NSObjectProtocol - URLSessionTaskDelegate et al inherit from `URLSessionDelegate. Since these are all Obj-C, they can have optional methods, which pure Swift protocols can't.

We could set up some kind of inheritance with our pure Swift protocols to allow passing the highest level as a single delegate, but the user would still need to implement all protocols in the inheritance tree, which again may not be what they need or want.

AHA. Talking through with Martijn I realized there's a way around this: An empty base protocol. Implementing!

martijnwalraven · 2019-07-02T21:30:44Z

Sources/Apollo/HTTPNetworkTransport.swift

+  ///   - data: [optional] Any data received. Passed through from `URLSession`.
+  ///   - response: [optional] Any response received. Passed through from `URLSession`.
+  ///   - error: [optional] Any error received. Passed through from `URLSession`.
+  func networkTransport(_ networkTransport: HTTPNetworkTransport,


For consistency with platform methods maybe something like networkTransport:didCompleteTaskForRequest:withData:response:error? So didComplete instead of completed, and I'm not sure whether the raw part is necessary? Alternatively, we could leave out the task altogether, and make it something like networkTransport:didCompleteRequest:withData:response:error.

Agree on didComplete vs completed, will update.

The Raw is to indicate that this is unprocessed data (and that the consumer shouldn't necessarily be trying to process it themselves). I started with didCompleteRequest but I went to the bit with Raw because I didn't want it to be confused by users with the actual completion closure.

… an optional delegate.

…ing, clarity, and null param handling

If I spell received correctly on the first try it's a clear sign i'm having an aneurysm

…ameter if their delegate conforms to multiple sub-protocols.

naknut · 2019-07-04T08:18:20Z

Hi @designatednerd thanks so much for fixing this, I've been looking forward to the header reconfiguration for a long time. Is there any documentation on how to actually do reconfiguration of headers? I tried looking through the code in this PR but I feel a little lost.

designatednerd · 2019-07-04T16:22:54Z

Nothing formal yet, but you can can see how we're altering the request if you look at the tests' implementation of willSend. Does that help?

naknut · 2019-07-04T21:21:26Z

Yes I was looking through that but couldn’t really figure it out. But I’ll have an other look!

designatednerd · 2019-07-05T08:14:06Z

Basically since request.allHTTPHeaderFields can't just have stuff appended to it, you copy the existing header fields, insert whatever you need, and re-assign the copy that now includes your additional fields to the request.

Since request is an inout parameter, you don't need to return anything, it just modifies the variable being used directly. Does that help?

alouanemed · 2019-07-05T20:54:53Z

Awesome work there @designatednerd, I wonder when we can see this shipped to the next update? Thanks!

designatednerd · 2019-07-06T08:10:57Z

Hoping for early next week!

designatednerd mentioned this pull request Jul 1, 2019

Provide a pattern for dynamic reconfiguration of network transport / auth headers #37

Closed

martijnwalraven reviewed Jul 1, 2019

View reviewed changes

designatednerd force-pushed the update/get-as-option branch from d2059ab to 6a89b50 Compare July 2, 2019 07:17

designatednerd force-pushed the add/header-configurator branch 2 times, most recently from 6c3cec8 to 5a6cff0 Compare July 2, 2019 08:06

koenpunt reviewed Jul 2, 2019

View reviewed changes

designatednerd mentioned this pull request Jul 2, 2019

Feature: Auto Persisted Queries with CDN Support #608

Closed

designatednerd force-pushed the add/header-configurator branch 2 times, most recently from d0ecc33 to 0f39e66 Compare July 2, 2019 16:20

designatednerd changed the base branch from update/get-as-option to master July 2, 2019 19:06

designatednerd force-pushed the add/header-configurator branch from 0f39e66 to 4b5af8d Compare July 2, 2019 19:07

koenpunt reviewed Jul 2, 2019

View reviewed changes

martijnwalraven reviewed Jul 2, 2019

View reviewed changes

designatednerd changed the title ~~WIP: Header configuration + Fix GET with null parameter~~ Header configuration + Fix GET with null parameter Jul 3, 2019

designatednerd added 2 commits July 3, 2019 16:30

Fix 4 vs 2 space alignment issues

4499a78

Add ability to bail out of or update the parameters of a request with…

ee39b0d

… an optional delegate.

designatednerd added 9 commits July 3, 2019 16:30

break out logic to transform GET requests into a transformer for test…

4d160da

…ing, clarity, and null param handling

pull out request construction into its own method for clarity

a39cd0b

Add request completion delegate, rename pre-flight delegate

bc85bb6

add and test retry mechanism

65b9cd6

better wording on error description

d66e400

fix typo in parameter name 🤦‍♀️

16c70bd

If I spell received correctly on the first try it's a clear sign i'm having an aneurysm

rename parameter for consistency with platform naming

d24b233

rename cancellation error

f983efc

create base delegate protocol so the user only has to pass in one par…

89cfced

…ameter if their delegate conforms to multiple sub-protocols.

designatednerd force-pushed the add/header-configurator branch from 230dec6 to 89cfced Compare July 3, 2019 14:30

martijnwalraven approved these changes Jul 3, 2019

View reviewed changes

designatednerd merged commit fa1c88e into master Jul 3, 2019

designatednerd deleted the add/header-configurator branch July 3, 2019 16:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Header configuration + Fix GET with null parameter #602

Header configuration + Fix GET with null parameter #602

designatednerd commented Jul 1, 2019 •

edited

Loading

martijnwalraven Jul 1, 2019

designatednerd Jul 2, 2019

martijnwalraven Jul 1, 2019

martijnwalraven Jul 1, 2019

martijnwalraven Jul 1, 2019

martijnwalraven Jul 1, 2019

RolandasRazma Jul 2, 2019

designatednerd Jul 2, 2019

designatednerd Jul 2, 2019

martijnwalraven Jul 3, 2019

designatednerd commented Jul 2, 2019

koenpunt Jul 2, 2019

designatednerd Jul 2, 2019

designatednerd commented Jul 2, 2019

koenpunt Jul 2, 2019

koenpunt commented Jul 2, 2019

martijnwalraven Jul 2, 2019

designatednerd Jul 2, 2019

martijnwalraven Jul 2, 2019

designatednerd Jul 2, 2019

martijnwalraven Jul 3, 2019

designatednerd Jul 3, 2019

designatednerd Jul 3, 2019

martijnwalraven Jul 2, 2019

designatednerd Jul 2, 2019

naknut commented Jul 4, 2019

designatednerd commented Jul 4, 2019

naknut commented Jul 4, 2019

designatednerd commented Jul 5, 2019 •

edited

Loading

alouanemed commented Jul 5, 2019

designatednerd commented Jul 6, 2019

		@@ -1,11 +1,32 @@
		import Foundation

		public protocol HTTPNetworkTransportDelegate: class {

Header configuration + Fix GET with null parameter #602

Header configuration + Fix GET with null parameter #602

Conversation

designatednerd commented Jul 1, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

designatednerd commented Jul 2, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

designatednerd commented Jul 2, 2019

Choose a reason for hiding this comment

koenpunt commented Jul 2, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naknut commented Jul 4, 2019

designatednerd commented Jul 4, 2019

naknut commented Jul 4, 2019

designatednerd commented Jul 5, 2019 • edited Loading

alouanemed commented Jul 5, 2019

designatednerd commented Jul 6, 2019

designatednerd commented Jul 1, 2019 •

edited

Loading

designatednerd commented Jul 5, 2019 •

edited

Loading