Support generating Encodable types

[gsabran]

Support generating Encodable types:

• make DataDict conform to Encodable
• add an opt-in option in the codegen config to make the types conform to Encodable (there is no code to generate other than adding the protocol conformance) since the implementation is provided by an extension.

Motivation

In some contexts, using the normalized cache adds a lot of overhead, including large cache size. When that's the case, it is desirable to be able to manage the persistence of Apollo types more directly, and Codable is the standard protocol to do so. This PR provides a solution for the serialization, and possibly for the deserialization when including Apollo as a dependency.

Why not Decodable ?

I think types can be decoded from a JSON value using

@_spi(Execution) import Apollo

try GraphQLExecutor(executionSource: NetworkResponseExecutionSource()).execute(
  selectionSet: Type.self,
  on: dataEntry, // JSONObject
  withRootCacheReference: nil,
  variables: nil,
  accumulator: GraphQLSelectionSetMapper<Type>()
)

which in my understanding has the benefit of going through all the Apollo machinery to validate the data, detect fragment conformance etc. If this understanding is correct this is great. However this code depends on Apollo, not ApolloAPI so this is not something the generated code can depend on.

[netlify]

👷 Deploy request for apollo-ios-docc pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	f9fbc47

[gsabran]

In addition to feedback about the goal of this change, and its implementation, I was curious if there already exist:

• snapshot testing of generated code
• tests that use generated types and validate their behavior (this would be quite useful to validate the encoding/decoding behavior of such generated types)

[AnthonyMDev]

Thanks so much for this PR @gsabran. We've talked about this feature in the past and had decided not to implement it. But it's been requested a number of times, and with a working implementation already proved out, I think it deserves re-consideration.

The team will discuss this and get back to you!

[gsabran]

Thank you. Yes I remember reading something about why it was rejected in the past (but I could not find a pointer for this PR). My recollection was that this was because Apollo's normalized cache is the recommended way to do storage, and that when using it there is no need to manage serialization.

I'm working on a project where the normalized cache is not scaling well and I would prefer to have the ability to do this myself.

I'm not entirely sure this implementation works on all cases (would love some feedback on that or how to better test), but one nice aspect is that it required very few changes to the generated code as we get Encodable for free as long as we can conform DataDict to it.