`fragmentIsFulfilled` is unknowable

[pm-dev]

Question

fragmentIsFulfilled returns a boolean for whether or not a response resolves a fragment. I believe this is impossible to know by the client.

Imagine the schema:

type Query { appConfiguration: AppConfiguration! }

interface AppConfiguration {
  foo: String!
}

interface MobileConfiguration implements AppConfiguration {
  foo: String!
}

type iPhoneAppConfiguration implements AppConfiguration & MobileAppConfiguration {
  foo: String!
}

type ChromeAppConfiguration implements AppConfiguration {
  foo: String!
}

And the query:

query AppConfiguration {
  appConfiguration {
    ...Config
  }
}

fragment Config on MobileAppConfiguration {
    foo
}

This creates a type that looks like:

struct AppConfiguration {
  ...
  var asMobileAppConfiguration: AsMobileAppConfiguration? { _asInlineFragment() }
}

In the response, when the concrete type is an iPhoneAppConfiguration asMobileAppConfiguration is non-nil. If the response returned a ChromeAppConfiguration, asMobileAppConfiguration would be nil. This works as expected.

But imagine 2010 rolls around and the following type is added to the schema.

type iPadAppConfiguration implements AppConfiguration & MobileAppConfiguration {
  foo: String!
}

This is a non-breaking server change, however the apps running the query from above would now see nil for asMobileAppConfiguration even though the server is still fulfilling the fragment on MobileAppConfiguration.

Without knowing all the implementation details. I assume Apollo stores all the possible concrete types at generation time then uses the __typename field at runtime and checks if it's one of the possible concrete types. However, because of the way graphql schemas are allowed to evolve over time, it's impossible to know at runtime all the possible concrete types.

To me this seems like incorrect behavior, but please help me understand if I'm missing something.

[BobaFetters]

In a scenario like this there is no way for the client to know or understand a type that is added on the server, the client is compiled against a specific version of the schema so the expectation would be that it understands and handles those types since it is essentially a snapshot at the time it was built. New types being added to the server shouldn't crash the client, however for the client to understand those types it would need to be recompiled. Given those constraints this would be valid behavior and would be based on the known types at build time. Anything beyond this to know types that were added after compilation would require server support, on top of client implementation to handle that in some way.

There is in RFC on the graphql spec currently that you may find interesting.

[github-actions]

Do you have any feedback for the maintainers? Please tell us by taking a one-minute survey. Your responses will help us understand Apollo iOS usage and allow us to serve you better.

[pm-dev]

Acknowledging the server may add new types the client is unaware of, but ignoring that possibility when resolving fragments at runtime seems contradictory.

Without the RFC you linked, there's no way to do this correctly, which is why I question whether its a good idea.

Also worth noting this behavior diverges from typescript codegen which doesn't try to guess if a fragment was fulfilled before resolving it.