The intension of GraphQL is not exposing a full-featured query language like SQL, but instead exposing an object graph that is easily understandable and serves as a contract between frontend and backend developers. Ideally that graph is modeled with the frontend in mind, which means the queries are one to one mappable to your UI components and not a representation of your database relationship model.
IMHO it would be a huge security/performance concern by exposing an SQL like API to the public. Malicious and really unperformant queries could be sent.
You can also have aggregated values, you will just execute the right SQL queries in your resolvers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The intension of GraphQL is not exposing a full-featured query language like SQL, but instead exposing an object graph that is easily understandable and serves as a contract between frontend and backend developers. Ideally that graph is modeled with the frontend in mind, which means the queries are one to one mappable to your UI components and not a representation of your database relationship model.
IMHO it would be a huge security/performance concern by exposing an SQL like API to the public. Malicious and really unperformant queries could be sent.
You can also have aggregated values, you will just execute the right SQL queries in your resolvers.