I agree! One thing to consider is that it depends a lot on the way you decide to use it. On one "extreme", you only have predefined queries, meaning it could almost be implemented the same way you implement REST API (however you decide to that).
On the other extreme of the spectrum, you allow the client to query the data with much freedom. This means that you have more of a generic resolver which maps GraphQL queries into an ORM or something else that generates your DB queries.
In this mode, you have challenges regarding speed and optimisations. At a previous assignment we for example hand crafted the resolution of some especially nasty queries to increase performance, and left most for some ORM to figure out. We kept the database index structure up to date to match queries we saw from the frontend using metrics tools.
Another thing is security. If you use this model, you are basically allowing the client to query around your graph of data in whatever way they want. This means you need to have some way to answer the question "Should User 37 be able to read field X on Object Y with ID 42", and implement that in your resolver. This is quite tricky, compared to REST or static graph QL queries where you just decide which objects / fields should be returned.
(There is also some interesting DoS attack scenarios when going this route, where a malicious query can just explode in complexity, so you'll have to make sure to solve that some way as well...)
On the other extreme of the spectrum, you allow the client to query the data with much freedom. This means that you have more of a generic resolver which maps GraphQL queries into an ORM or something else that generates your DB queries.
In this mode, you have challenges regarding speed and optimisations. At a previous assignment we for example hand crafted the resolution of some especially nasty queries to increase performance, and left most for some ORM to figure out. We kept the database index structure up to date to match queries we saw from the frontend using metrics tools.
Another thing is security. If you use this model, you are basically allowing the client to query around your graph of data in whatever way they want. This means you need to have some way to answer the question "Should User 37 be able to read field X on Object Y with ID 42", and implement that in your resolver. This is quite tricky, compared to REST or static graph QL queries where you just decide which objects / fields should be returned.
(There is also some interesting DoS attack scenarios when going this route, where a malicious query can just explode in complexity, so you'll have to make sure to solve that some way as well...)