3 ms·
We've used GraphQL in production for about a year now, alongside some legacy rest APIs. It's a lot easier to maintain the GraphQL endpoint, like it's not even c
by yen223 9y ago
We've used GraphQL in production for about a year now, alongside some legacy rest APIs. It's a lot easier to maintain the GraphQL endpoint, like it's not even close.
GraphQL's secret weapon is the static type definition. We can safely alter fields in the backend, and be notified at compile-time if client-side code is about to break as a result of those changes. We don't have the same guarantees with the rest api, which is the only reason they're still around at all - it's so hard to make changes if you have little idea which client-side code depends on which field.
- boubiyeah 9y agoAre you talking about a single client and its server? (a.k.a backend-for-frontend). This is not a hard problem to solve when you share a single programming language, with or without graphql. Because you can't possibly now what your API consumers use on their side.
- djmashko2 9y ago> Because you can't possibly now what your API consumers use on their side. That's the best part - with GraphQL you _do_ know, since people have to ask for every single field they want.
- yen223 9y ago> Because you can't possibly now what your API consumers use on their side. Not only do we know exactly what fields the API consumers are using, we also know the types they're expecting. We can make schema refactors fairly safely. That goes a long way towards making the codebase less brittle as a whole
- lmm 9y ago> We can safely alter fields in the backend, and be notified at compile-time if client-side code is about to break as a result of those changes. I think that's an immensely useful thing to do - that's why I've been doing it for years by using Thrift instead of REST :). Is there still a value proposition for GraphQL if I'm already using strongly typed interfaces?