Both REST and GraphQL API's can be well designed, or badly designed. While I'm a GraphQL fanboy, I would much prefer integrating with a well design REST API ov

Both REST and GraphQL API's can be well designed, or badly designed. While I'm a GraphQL fanboy, I would much prefer integrating with a well design REST API over a badly designed GraphQL API. Having spent over 15 years integrating with, and writing API's, GraphQL was a breath of fresh air! If you think of GraphQL as a query language, you will find it frustrating. If you think of it like you do a REST API with all the ugly pain points straightened out and standardised, then it is a dream to work with. GraphQL is as much of a query language as REST is. For example, most REST API's end up getting super long lists of parameters in their urls. How many eCommerce API's end up having REST URL's like: /api/products?category=guitars&include_variants=true&page=20&per_page=100&exclude_fields=description,specs Whereas, GraphQL transforms that into a simple, readable query, which does not require reading pages and pages of documentation to understand. But, if you are creating well designed REST API's, I would prefer to use them over somebodies poorly written Graph. Just like a REST API, a well written Graph should be crafted to be fast and performant to execute. Just like with REST, a Graph designer needs to sit down and think about the ways people will want to use the API. A good graph does not allow endless relationships that will cause performance to blow out.