graphql

hlship 2020-10-23T00:04:11.042Z

Well, tests did change output, but that output was wrong. The implementation is a little complicated by pushing as much as possible into the schema compile stage.

chrisulloa 2020-10-23T21:29:05.044300Z

Oh yeah, I mean it’s good it’s more spec compliant, but it fundamentally changes the behavior of how our GraphQL responses will look when non-nilable fields are nil. I think this means we need to make sure our schema is more ironclad and fault tolerant when we upgrade to the newest version that includes this change. Right now our consumers are used to getting back mostly partial data when a service goes down that causes a non-nilable field to come back as nil. Now they will need to expect less partial data returned when this happens.

2020-10-25T21:37:24.045300Z

A stance I (sometimes) read from blogs about GraphQL is that you should embrace nullability. So in this case that would mean that if a field could be unavailable due to a partial outage, it could be nullable in your schema. Not that our schema is perfect in this regard :’)

👍 1
chrisulloa 2020-10-26T16:43:42.046400Z

That’s a great point, thanks for insight

isak 2020-10-23T21:24:14.043800Z

Question for anyone in here: If you provide GraphQL APIs to your customers, what kind of feedback do you get? Do people consider it hard to use?

gklijs 2020-10-25T08:12:21.045100Z

In our case, having 'internal' customers it's often putting them off, as they think it's complicated. But some of them have started using GraphQL, so I think it's just a matter of getting used to.

hlship 2020-10-26T00:24:30.045700Z

We used to get a bit of pushback because it was unfamiliar; then we parked ’em in front of GraphiQL and that solved most of the problems. Now way more of Walmart is on the GraphQL bandwagon, including federation.

isak 2020-10-26T15:33:21.045900Z

Interesting, thanks @gklijs and @hlship!

gklijs 2020-10-26T15:38:25.046100Z

No problem, I tend to see a difference between backend use and frontend use. Where frontend easier/faster to adopt GraphQL than backend. Probably helped because there are a lot of ‘serverless’ GraphQL solutions, but not that many GraphQL backend clients. But it seems more and more ‘acceptable’ for server to server as well.

isak 2020-10-26T17:25:05.046600Z

Ah, interesting. I've noticed some resistance too (main use case is server to server), just not sure if it is a vocal minority, or what.

gklijs 2020-10-27T08:34:22.046800Z

Also server to server the bandwidth is much less of an issue, while it’s one of the strong points of GraphQL that you only get what you aks for. But server to server often want ‘everything’ and that can be quite complex with GraphQL. But the introspection and graceful deprecation/evolution are big wins for server to server you get in return, in my opinion.

1