curious what ya’ll think about needing or not need...
# general
p
curious what ya’ll think about needing or not needing contract tests when the provider is graphql. seems like the graphql schema can be a good enough proxy for a stand-in contract test. just want to make sure we use contract testing in the correct places
m
See https://pactflow.io/blog/contract-testing-a-graphql-api/ and let me know what you think. TL;DR - GraphQL doesn’t give you protections on its own, you still need a way to ensure the schema doesn’t change in a breaking way
🤔 1
t
How do you check compatibility between any two versions of the schema? How do you reason about what you can and can't deploy?
☝️ 1
GraphQL doesn't solve those problems, it just makes it less work to implement the transport of data
p
so looks like we already have tooling in place in our automated pipelines to handle disallowing breaking schema changes. i think that addresses the concerns above
t
Does your tooling test that each side understands the same semantics? Most of the time this is the issue with graphql
seems like the graphql schema can be a good enough proxy
My experience is that people assume they don't need contract tests because of graphql tooling, and then they have issues in prod because the tooling couldn't detect the issues.
Of course, you can use what you like. You don't even need to test at all, as tests are only risk reduction. However, doing contract testing (whether or not you use pact) is more than just "is this change a breaking change to the schema". For example, just because an update is backwards compatible it doesn't mean that a non-updated provider is compatible with an updated consumer.
Can you tell me more about your setup? If there is tooling that provides proper deployment confidence for GraphQL, I'm very keen to hear about it.
🤔 1
p
hi! sorry for the late turnaround on this. we’re looking at https://www.graphql-inspector.com/
t
Thanks! I’ll take a look
👍 1