3 ms·
Maybe you don't need GraphQL
- jerelmiller 2mo agoThere are a few issues I have with this article. First, the opening example is completely wrong and broken. If your GraphQL server is returning the response in a shape that isn't the same as a query, your GraphQL server is broken and you should file an issue with the tool you're using. In no way should querying for `comments { id text user { username }}` give you a response with `comment_id`, `comment_text` or `username` as a top level field. Second, persisted queries/trusted documents help solve many of the security concerns because it allows you to save which queries are allowed to your server. Additionally, the use of directives inside of your schema can help you define auth rules where needed in case certain fields so you can block access where needed (thats just one way to go about it). I'm not quite clear on the condensation of queries either using the SQL example. The query gives you the fields the clients select so you can optimize your query as needed to select what you need. If the criticism is that its more difficult to do across several resolvers, that is fair, but it is not stated. Optional fields in GraphQL can also be accomplished through the `@include` or `@skip` directives which let you opt out of fetching fields when that is true. The responsibility moves to the client instead of the URL for the server, but you can still accomplish the same thing. --- Some things I would tend to agree with though since I don't want to be all negative: If you only have a couple endpoints for a very simple API, yes I agree GraphQL might be overkill and REST might suit you better.