Re:The GraphQL stack: How everything fits together
by lmm on Thursday November 09, 2017 @10:13AM
(#15663030)
> 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?
Re:The GraphQL stack: How everything fits together
by boubiyeah on Thursday November 09, 2017 @09:28AM
(#15662608)
Are 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.
Re:The GraphQL stack: How everything fits together
by yen223 on Thursday November 09, 2017 @03:40PM
(#15665703)
> 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
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.