Is it possible to have strict runtime validation t...
# apollo-kotlin
w
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 ?
m
We could add something like this. It wouldn't be too hard I think.
Re
__typename
, there's the question of types added on the server after compilation
Because the
__typename
is unknown doesn't always mean the response is wrong
Do you have a specific use case in mind?
w
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
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
m
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:
Copy code
{
  animal {
    species
    habitat {
      country
    }
    ... on Cat {
      meow
      habitat {
        temperature
      }
    }
  }
}
Test Code:
Copy code
val testData = buildQueryData {
  animal = cat {
    species = "Cat"
    meow = "meeeeooowww"
    habitat = habitat {
      country = "France"
      temperature = 22.8
    }
  }
}
This
buildQueryData
could also be
buildQueryJson
too if you still want a Json to enqueue in MockServer or something else
w
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
m
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
👍 1
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)
w
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
m
Mind opening an issue on the repo so we keep track of the "strict" mode?
👍 1
w
For example our server adds some apollo extensions to the response, which now I realise would break the second validation I mentioned originally 😓
m
We could validate only the
response.data
part
extensions are in
response.extensions
, right?
Validating extensions would be another story since there's not a schema for them
w
Yes, in root response object, the same level as
"data"
👍 1