| I love SQL. I'll write CTEs and window functions until the cows come home with a smile on my face. But not everyone needs to know SQL. There are many other worthy pursuits. REST suffers from the N+1 problem and overfetching. Most ORMs do as well. "Oh! You want order info AND product reviews? (At least) 2 more REST calls for you. Oh! You don't need the person's shipping and billing addresses in this case? So sorry, take them anyway, otherwise we would have to make another REST endpoint just for you." Also affects versioning. In REST you commonly see URLS like "/v1/foo/54321" because if you try to remove or rename ANY PART of the JSON payload coming back, you break a contract. With GraphQL, you make the new name available and mark the old name with a directive like @deprecated. Over time you watch the logs to see if any clients are still using the old name. If so, keep it around and write another blog post asking folks not to use it anymore. If not, just remove it. You're done. No broken contracts. No differently versioned URLs. GraphQL handles N different clients with a single schema. Mobile app clients, desktop clients, B2B clients, et al get exactly the data they need—no more and no less. REST either shoehorns them all into one or two access models or explodes into an unmaintainable mess of hundreds or thousands of often redundant endpoints. The biggest difference, the one that GraphQL was really originally built to solve at Facebook, was to allow the CLIENT to determine what data they needed at any given time rather than REST which may be driven by client requests but ultimately is what servers THINK clients will need, and is much harder to change as needs change (and they will change). |