If I have an interface type, and our client queries that type. But server introduced a new concrete ...

# apollo-kotlin

[agrosner]

If I have an interface type, and our client queries that type. But server introduced a new concrete type, do we need to update the schema in client to parse that new concrete type if we select only the interface as a fragment?

[mbonnin]

Usually you don't as long as you only select interface fields

[mbonnin]

{
  animal {
    species
    name
  }
}

You will get a model matching Animal irrespective of the different concrete types (Lion , Turtle , etc...)

[agrosner]

Cool thanks!

[agrosner]

Just making sure. I thought that was the case. This allows our backend teams to introduce more types by different subgraphs without requiring client change if we only select interface fields. 🥳

[agrosner]

I think

[mbonnin]

yes, definitely. If not, that'd be a huge issue for all the apps already deployed

[agrosner]

Yeah totally

[agrosner]

I was thinking in the case of possible types, requiring that all types are present in the client schema . Maybe that was old Apollo client js code

[mbonnin]

Something you might have is not being able to read all the fields returned by the backend in some cases where you have 2 interfaces. Let me try to find an example

[mbonnin]

{
  node {
    id
    ... on Animal {
      species
    }
  }
}

[mbonnin]

If you introduce a new type Cat then the backend knows it's a Animal

[mbonnin]

So the backend will send back

{
  "animal": {
    "__typename": "Cat",
    "id": "42",
    "species": "Cat"
  }
}

[mbonnin]

But from Kotlin code, your old app cannot access species

[mbonnin]

only id

[mbonnin]

The old app keeps working. Only it doesn't display as much data as it could

[agrosner]

interesting. is it because the typename is not recognized? so only if we have a node query that references an interface vs a concrete type that has an interface field?

[mbonnin]

Only thing the old app can assume is that "Cat" is a "Node"

[agrosner]

{
  animal {
    id
    eyes {
      color
    }
  }
}

If Animal was concrete field type, then a field named eyes was an interface with color field.

[mbonnin]

Without the schema, it cannot know that "Cat" is also an "Animal"

[agrosner]

App is bundled with type DefaultEyes implements Eyes but backend decides to send type BrownEyes implements Eyes , then it should work

[mbonnin]

Yes, because you don't have any fragment under the eyes field

[mbonnin]

The situation I described only happens with fragments

[agrosner]

what if it was:

eyes {
  color
  ... on DefaultEyes {
    anotherField
  }
}

app would still see color, is my thought. if im understanding correctly. which is perfectly fine

[agrosner]

thank you color

[mbonnin]

app would still see color, is my thought. if im understanding correctly. which is perfectly fine

Yep, exactly. Every subfield of the given field ("just under") will be still be seen. But not always for fields that are nested in fragments

[agrosner]

ok cool thanks