Yeah I'm not entirely sold on GraphQL but I think it shines in some cases.
Ex: you are building on top of third party ecommerce software.
You need to add more data to the Cart entity because you have a custom module/plugin/etc. You write a graphql resolver, extend the schema and the Cart type. You can use the existing built-in endpoint to query your new data.
So it's nice to be able to extend a framework and data access in that manner.
In general though, I do prefer REST APIs and then writing custom endpoints if I need data for a specific UI, like for visualizations.
Parent is mixing up GraphQL and ORMs which serve two completely different purposes and doesn't seem to have actually used GraphQL. GraphQL is purely a way for a client to request some data instead of REST. How the backend serves that request is not any concern to the frontend, the backend can use an ORM or it can use raw SQL, or whatever else it wants.
Yes I think you are right; I wasn't following the ORM part either. I mean, you can return whatever you want so long as matches the schema. Hard code it, raw sql, whatever.
I wrote some custom resolvers yesterday to extend graphql on a Cart entity and it works well for that.
I used some existing repositories the backend already had but was not yet available on the GraphQL side.
All the resolvers can lead to extra performance issues of course, but I suppose you can adjust your schema as needed and tune it with more efficient queries or code (ex: move some properties to nested and resolve with a single tuned query)
GraphQL was designed to solve a singular problem, slow mobile internet speeds. Now that mobile internet (5G) is faster then some wired home connections I'm worried that GraphQL will die off. It's a solution that no longer has a problem. Though it is a cool tech.
Ex: you are building on top of third party ecommerce software.
You need to add more data to the Cart entity because you have a custom module/plugin/etc. You write a graphql resolver, extend the schema and the Cart type. You can use the existing built-in endpoint to query your new data.
So it's nice to be able to extend a framework and data access in that manner.
In general though, I do prefer REST APIs and then writing custom endpoints if I need data for a specific UI, like for visualizations.