1. It incentivized using it as the data model which is both inefficient and lossy in regards to transactions.
2. what’s the purpose of graphql in this context? You have to use an ORM anyway with which you can do all delegations to servers etc your heart desires and with typescript you can ensure proper column types regardless. You can trivially autogenerate objects or any kind of descriptor from a database as well.
Seems to me people decided graphql was a perfect solution to nicely hit multiple data stores with the now added caveat that we have a worse query language that lacks joins to boot.
I’ve still yet to see an actual technical argument for why we should add another (less efficient) layer between the actual data stores and the ORM/Application DataModel.
GraphQL is for the client to efficiently query data, it is not supposed to be used as a SQL replacement on the server side. If people are using it for a server side query language, that is not what its benefit is.
IIRC in the Gatsby framework it has a built-in GraphQL parser for server-side developers to query data from Gatsby plugins, which can be things like data stores, other APIs, or even a mixture and blended together.
In a way, that's using the server as a client for other servers, ie it would be the same as a server sending a REST request to another server asking for data. What I mean is nowhere should there be GraphQL between a server and a database, because that doesn't make any sense, just use an ORM.
How can the client most efficiently query data from a sql database without joins? Surely there are cases this would be needed to speedup grabbing of data?
Any ORM will handle getting data with joins just fine when it constructs the SQL. Or you can write your own SQL with joins to pass along to the query.
If you mean GraphQL doesn't have joins, I'm not sure in what use case that would matter when you're declaratively asking the server for some data, not hand constructing SQL. What would you need joins in? You mean like this example [0]?
Right so, again, what exactly is the purpose of graphql?
It seems to be a replacement for an ORM that then needs an ORM. So it’s a replacement for passing JSON objects around except it’s just doing that with a dash of esotericism.
You're mixing up server side and client side. The point of GraphQL is to make a client request only what data it needs rather than making X different REST calls then combining and filtering them in the client side. That's it, that's the entire purpose. (If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table and ask for specific columns in that table, then congratulations, you've reinvented GraphQL.)
You can then implement a server which, given a GraphQL query, turns it into the data that's expected. The client doesn't care how you implement that. You can write raw SQL, use an ORM, whatever. Since people don't want to reinvent the wheel they use libraries like Apollo Server, but again you can do it all by hand if you really want to.
Have you actually used GraphQL? This is all explained within the first 15 minutes of any GraphQL tutorial.
> If you then ask, why not have REST calls that give specific pieces of information, ie have sorts and filters within the query parameters, and be able to take a table and ask for specific columns in that table, then congratulations, you've reinvented GraphQL.
Obligatory note: this really is just supposed to be REST. GraphQL seems to be the final expression of throwing in the towel on REST's original capabilities.
As such it's not clear of it's a step forward (REST as it should be) or a step back (let's just use a crippled SQL and ship)
SPAs and REST APIs moved a lot of the complexity around data to the client side. GraphQL moved it back to the server side. I think that's a reasonable decision, as the client - compared to the server - runs in a much more unpredictable environment. Of course some backend devs complain about more work, especially work that could be moved to the client side at first. Making things the proper way is hard, yes.
The pitch I remember back when it first was released was that GraphQL was meant for development, when the API was still changing a lot, and was supposed to be replaced with dedicated API calls before going to production. During development frontend devs has something flexible they could use without pestering the backend constantly, then the dedicated non-GraphQL production version would be stable and could be significantly more optimized than the GraphQL version.
The backend still needs to implement the endpoints for the frontend? Not sure what you mean, if anything the backend work increases because everything is done on the backend now.
And did you really link me to a meme you made specifically for this conversation?
1. It incentivized using it as the data model which is both inefficient and lossy in regards to transactions.
2. what’s the purpose of graphql in this context? You have to use an ORM anyway with which you can do all delegations to servers etc your heart desires and with typescript you can ensure proper column types regardless. You can trivially autogenerate objects or any kind of descriptor from a database as well.
Seems to me people decided graphql was a perfect solution to nicely hit multiple data stores with the now added caveat that we have a worse query language that lacks joins to boot.
I’ve still yet to see an actual technical argument for why we should add another (less efficient) layer between the actual data stores and the ORM/Application DataModel.
Is it resolver logic between stores?