Is it possible to have strict runtime validation to check: - that the `__typename` field matches th...

# apollo-kotlin

[wasyl]

Is it possible to have strict runtime validation to check:
• that the __typename field matches the expected type name from schema
• that the json response doesn’t contain unnecessary fields/objects
?

[mbonnin]

We could add something like this. It wouldn't be too hard I think.

[mbonnin]

Re __typename, there's the question of types added on the server after compilation

[mbonnin]

Because the __typename is unknown doesn't always mean the response is wrong

[mbonnin]

Do you have a specific use case in mind?

[wasyl]

Yes, and actually I’d like both checks to be off in production 🙂 But we have a set of recorded responses for API layer tests/UI tests, such checks would help us make sure the responses are consistent with the queries

[wasyl]

Recording new responses when the queries change is inconvenient, because the data inside (which we check for and use in UI tests) changes too. Right now we update the jsons semi-manually, with some jq queries, but it’s a bit error prone exactly in the two cases I mentioned

[mbonnin]

I see. Test APIs are the next thing I'd like to tackle. I'm thinking of introducing a DSL so that you don't have to write json (but could if you really want to). Something like:
query:

{
  animal {
    species
    habitat {
      country
    }
    ... on Cat {
      meow
      habitat {
        temperature
      }
    }
  }
}

Test Code:

val testData = buildQueryData {
  animal = cat {
    species = "Cat"
    meow = "meeeeooowww"
    habitat = habitat {
      country = "France"
      temperature = 22.8
    }
  }
}

[mbonnin]

This buildQueryData could also be buildQueryJson too if you still want a Json to enqueue in MockServer or something else

[wasyl]

I suppose you’d only know at runtime that something’s missing, right? Either way, looks nice but I’m not entirely sure we’d like to use that, since we do fetch jsons from the server the first time we introduce some query

[mbonnin]

I suppose you’d only know at runtime that something’s missing, right?

Most likely yes. We could theorically generate all the code to make it compile-time checked but that might not be worth it

[mbonnin]

we do fetch jsons from the server the first time we introduce some query

Makes send, that's completely fair. I guess that'd be for users who'd prefer to manually construct their json (as opposed to recording them)

[wasyl]

Yeah, the sdl looks like a useful thing if someone already creates *Data instances manually, which we specifically try not to do, opting for testing entire jsons instead

[mbonnin]

Mind opening an issue on the repo so we keep track of the "strict" mode?

[wasyl]

For example our server adds some apollo extensions to the response, which now I realise would break the second validation I mentioned originally 😓

[mbonnin]

We could validate only the response.data part

[mbonnin]

extensions are in response.extensions , right?

[mbonnin]

Validating extensions would be another story since there's not a schema for them

[wasyl]

Yes, in root response object, the same level as "data"

[wasyl]

https://github.com/apollographql/apollo-android/issues/3344