No, not really. In the end, you're querying data. It's the same thing. This should be made abundantly clear by simply comparing GraphQL and SQl. The former is little more than a simplified version of the latter forcefully pressed into a more JSON-like syntax.
It's because this post failed to highlight the actual strength and use case of GraphQL and tried to present GraphQL as a replacement for REST which is not true. But once you actually learn it and use it, you'll appreciate what it allows you to do.
That very much aligns with my point though; GraphQL is not a replacement for REST because they're different things. GraphQL is a query language, just like SQL is. So it's those two that should be compared, while REST has little to do with either of them.
SQL is for databases, GraphQL (mainly) for frontends. It's apples and oranges.
You query your front-ends for data?
No.. But traffic between a backend service and frontend, or backend service and a database, is something different right?
No, not really. In the end, you're querying data. It's the same thing. This should be made abundantly clear by simply comparing GraphQL and SQl. The former is little more than a simplified version of the latter forcefully pressed into a more JSON-like syntax.
Not really, security, error handling, depreciation, are all totally different.
It's because this post failed to highlight the actual strength and use case of GraphQL and tried to present GraphQL as a replacement for REST which is not true. But once you actually learn it and use it, you'll appreciate what it allows you to do.
That very much aligns with my point though; GraphQL is not a replacement for REST because they're different things. GraphQL is a query language, just like SQL is. So it's those two that should be compared, while REST has little to do with either of them.
I would argue they are 3 different, which each there own good use cases.