[xtrapolate]

"We moved to GraphQL because things were bad, and now things are good. GraphQL is amazing".

I don't want this to come off as a personal attack (and I apologize if it does), but your comment contains absolutely no information whatsoever regarding a specific situation/use-case, nothing from which the rest of us can formulate our own opinions on the REST/GraphQL discussion.

[Zyst]

>we were spending a lot of client time fetching deep trees through resource links

>it solved a lot of the administrative and philosophical headaches

>considerably reduced the number of connections

>considerably reduced wasted data

>made our client code so much simpler through easily grokked queries

I feel that grandparent does contain information which might be valuable for adoption.

[CuriousSkeptic]

My interpretation was: “We did ReST trying to follow dogma and ended up with a badly designed API that din’t fit our needs. Switching to a tech with less dogma on how to do things led us to a better API-design with a better fit” (inferring some context from my own experience here, could be wrong)

In the end I would guess you can end up in a similar place with a standard fetch-json design if you just ignore ReST dogma and focus on getting the API into a shape that fits the need.

Not saying ReST dogma is necessarily wrong, or bad, just that it’s easy to get lost in design when focusing more on learning others design than understanding the actual problem you’re trying to solve.

[chillacy]

For reference we’re switching from the non dogmatic get/post requests over http to graphql and it’s been equally good for us too for different reasons.

[naasking]

Also consider that a second implementation of a system is always going to be cleaner than the first because you actually know what you need to do. This is an inherent bias inherent to any GraphQL migration story.