Update new networking stack docs#1484
Conversation
designatednerd
force-pushed
the
update/docs
branch
from
8d40021 to
aa70069
Compare
| - `LegacyCacheWriteInterceptor` writes to a provided `ApolloStore` based on code from our current Typescript-based code generation. | ||
| - `CodableParsingError` is a **work in progress** which will parse `Codable` results form the Swift Codegen Rewrite. | ||
|
|
||
| Interceptors are designed to be **short-lived**. A new set of interceptors should be provided for each request in order to avoid having multiple calls hitting the same instance of a single interceptor at the same time. |
There was a problem hiding this comment.
A new set of interceptors should be provided
at the moment it "must be"
There was a problem hiding this comment.
I would disagree with this - you can choose to ignore this, but in doing so you need to understand the trade-off with what the design is.
| - `AutomaticPersistedQueryInterceptor` handles checking responses to see if an error is because an automatic persisted query failed, and the full operation needs to be resent to the server. | ||
| - `LegacyParsingInterceptor` parses code generated by our Typescript code generation. | ||
| - `LegacyCacheWriteInterceptor` writes to a provided `ApolloStore`. | ||
| - `LegacyParsingInterceptor` parses code generated by our current Typescript-based code generation. |
There was a problem hiding this comment.
Why not to rename it to TypescriptGeneratedParsingInterceptor - ok name is not best but at least no-one will run to look for non legacy interceptor
There was a problem hiding this comment.
I definitely understand the thought here, but honestly given that we've abstracted a lot of the typescript stuff away I think that may be more confusing.
|
|
||
| A `RequestChain` is constructed using an array of interceptors, to be run in the order given, and handles calling back on a specified `DispatchQueue` after all work is complete. | ||
|
|
||
| A chain is started by calling `kickoff`. This causes the chain to start running through the chain of interceptors in order. |
There was a problem hiding this comment.
...witch makes me wonder, is there any reason why kickoff is public?
There was a problem hiding this comment.
So that if you want to use it in a different NetworkTransport you can
| - `endpointURL`: The GraphQL endpoint URL to use for all calls. | ||
| - `additionalHeaders`: Any additional headers that should be automatically added to every request. Defaults to an empty dictionary. | ||
| - `autoPersistQueries`: Pass `true` if [Automatic Persisted Queries](https://www.apollographql.com/docs/apollo-server/performance/apq/) should be used to send an operation's hash instead of the full operation body by default. **NOTE:** To use APQs, you need to make sure to generate your types with operation identifiers. In your Swift Script, make sure to pass a non-nil `operationIDsURL` to have this output. Due to this restriction, this option defaults to `false`. | ||
| - `additionalHeaders`: Any additional headers that should be automatically added to **every** request, such as an API key or a language setting. Headers that should not be sent with every request should be configured through an interceptor. Defaults to an empty dictionary. |
There was a problem hiding this comment.
still think this should be interceptor. Would allow to avoid questions like "who has priority? additionalHeaders or Interceptor?"
There was a problem hiding this comment.
Honestly, I disagree - I don't think you should need to set up an additional interceptor if all you need to do is add the same API key to every single request. I'll add language about headers whose value changes across different requests being something that should be added in interceptors, though.
…" vs "use in the future"
designatednerd
force-pushed
the
update/docs
branch
from
582b0a5 to
28bda32
Compare
2 participants
Thanks for the feedback, particularly in #1472!