Cons: you have to write complex resolvers to "tell" it what to return even when you are writing a basic query and it should already know what you want back. Why would I want to write a query and then have to tell the database what to send me back?? It would be like if I went to a restaurant and ordered food and then had to tell the chef how to make it. How is this even remotely acceptable??
Cons: Does not support Aggregates in many cases. Want to use COUNT, MIN, MAX? Sorry you are SOL...
Cons: You will spend hours trying to figure out how to get the data back you need when you could have gotten it back in 5 seconds by writing a SQL query you already know.
Pros: connect your graphQL DB to Rockset and run native SQL Queries on it at lightning speed. No i don't work for Rockset but i use it a lot with Dynamo DB.
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.
Aggregates and pagination also included out of the box with no configuration. If you've defined your data model, you've got your graph. Smart comments allow renaming and omitting certain tables and columns as well.
Performance with it is not an issue. Quite the contrary.
I do not contribute to the project, but I'm a big fan.
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.
Cons: you have to write complex resolvers to "tell" it what to return even when you are writing a basic query and it should already know what you want back. Why would I want to write a query and then have to tell the database what to send me back?? It would be like if I went to a restaurant and ordered food and then had to tell the chef how to make it. How is this even remotely acceptable??
Cons: Does not support Aggregates in many cases. Want to use COUNT, MIN, MAX? Sorry you are SOL...
Cons: You will spend hours trying to figure out how to get the data back you need when you could have gotten it back in 5 seconds by writing a SQL query you already know.
Pros: connect your graphQL DB to Rockset and run native SQL Queries on it at lightning speed. No i don't work for Rockset but i use it a lot with Dynamo DB.
Thanks for such a nice explanation. I am trying to learn graphql and share the basics for beginners.
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.
I highly recommend trying out Postgraphile, especially if you are already familiar with RDBMSs and SQL.
graphile.org/postgraphile/
Aggregates and pagination also included out of the box with no configuration. If you've defined your data model, you've got your graph. Smart comments allow renaming and omitting certain tables and columns as well.
Performance with it is not an issue. Quite the contrary.
I do not contribute to the project, but I'm a big fan.