The main advantage is ROCK SOLID schemas that map 1:1 with your database. Another advantage is less code that you need to maintain. The vast majority of backend code nowadays is basically making DB queries and passing them forward. The strategy you're talking about eliminates that need!
Most DB -> graphql engines are pretty intelligent about the kinds of queries that they make, so it's never just a 1:1 map for the query, only for the schema.
Might I recommend Postgraphile (as a great OSS alternative to hasura) + typescript + graphql-codegen?
You get auto generated apollo graphql hooks (for react) AND an auto generated graphql schema from postgraphile.
I have a little example of a "real" project architecture with this on my github
So, it's basically that the user gets a GraphQL interface, which itself maps GraphQL queries to predefined SQL queries for performance reasons and because it might be in some cases easier to write GraphQL queries :-)
I'm thinking about adding a QraphQL endpoint for a temporal document store (Open Source) of mine, to hardcode really performant queries as I haven't had the time to add cost based optimizations or any kind of AST rewrites, which directly affect the physical aspects of my particular storage engine to the query processor (but the basic query compiler is very performant, as it's set oriented instead of tuple at a time...) :-)
I could use the Vert.x implementation, however I first want to build the front-end now.
So with postgraphile, specifically, it could either create a graphql schema (not queries) or provide a graphql api with that generated schema.
The dev would need to write their own graphql queries, but depending on the queries and the methods being called in them, postgraphile (the server, not the generated schema alone) would intelligently create speedy SQL queries UNLESS the dev defined specific functions for some kind of queryable data.
Postgraphile will generate query schema definitions for any tables in the schema that you give it access to. It can do that with mutations too, but you'll usually just want to write all of those yourself.
I really encourage you to give it a try with a toy DB, it's tough to explain how impressive it is (or how useful I find it) over comments on a post :(
I asked specifically because in the future I might want to build something like that for my own data store/storage engine, which however is based on semi-structured data (binary representation of XML and JSON) and which deduplicates the data naturally and stores an index into each revision... might be interesting, as I can map the fetching of the data probably much more easily to efficient storage operations as for complicated XQuery/JSONiq queries (which seems to be even more complicated regarding all the stuff which is possible in comparison with SQL).
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 main advantage is ROCK SOLID schemas that map 1:1 with your database. Another advantage is less code that you need to maintain. The vast majority of backend code nowadays is basically making DB queries and passing them forward. The strategy you're talking about eliminates that need!
Most DB -> graphql engines are pretty intelligent about the kinds of queries that they make, so it's never just a 1:1 map for the query, only for the schema.
Might I recommend Postgraphile (as a great OSS alternative to hasura) + typescript + graphql-codegen?
You get auto generated apollo graphql hooks (for react) AND an auto generated graphql schema from postgraphile.
I have a little example of a "real" project architecture with this on my github
github.com/benbot/the-way-apps-sho...
So, it's basically that the user gets a GraphQL interface, which itself maps GraphQL queries to predefined SQL queries for performance reasons and because it might be in some cases easier to write GraphQL queries :-)
I'm thinking about adding a QraphQL endpoint for a temporal document store (Open Source) of mine, to hardcode really performant queries as I haven't had the time to add cost based optimizations or any kind of AST rewrites, which directly affect the physical aspects of my particular storage engine to the query processor (but the basic query compiler is very performant, as it's set oriented instead of tuple at a time...) :-)
I could use the Vert.x implementation, however I first want to build the front-end now.
Probably I would map this to storage primitives and in my case axis to navigate to the desired nodes.
So with postgraphile, specifically, it could either create a graphql schema (not queries) or provide a graphql api with that generated schema.
The dev would need to write their own graphql queries, but depending on the queries and the methods being called in them, postgraphile (the server, not the generated schema alone) would intelligently create speedy SQL queries UNLESS the dev defined specific functions for some kind of queryable data.
Postgraphile will generate query schema definitions for any tables in the schema that you give it access to. It can do that with mutations too, but you'll usually just want to write all of those yourself.
I really encourage you to give it a try with a toy DB, it's tough to explain how impressive it is (or how useful I find it) over comments on a post :(
I asked specifically because in the future I might want to build something like that for my own data store/storage engine, which however is based on semi-structured data (binary representation of XML and JSON) and which deduplicates the data naturally and stores an index into each revision... might be interesting, as I can map the fetching of the data probably much more easily to efficient storage operations as for complicated XQuery/JSONiq queries (which seems to be even more complicated regarding all the stuff which is possible in comparison with SQL).