3 ms·

This is why I dislike graphql especially with react. It’s gets set up as a half assed ORM (but without joins!) and then all but the most senior of engineers en

This is why I dislike graphql especially with react. It’s gets set up as a half assed ORM (but without joins!) and then all but the most senior of engineers end up using it as your application state which slows the whole app to crawl forcing a big rewrite. Using an orm and building a proper data model in your code using a store like redis takes very little additional time (especially with sequelize!) and it has the benefit that your junior and mid level engineers understand where the underlying data is stored.

cercatrova 4y ago
Not sure I understand because I use GraphQL with an ORM, Prisma with Postgres and Pothos which converts the Prisma schema into GraphQL types. It even has the ability to use Redis as a store. So we get all the features of an ORM and also typesafe queries.
- edgyquant 4y ago
  Right my point is that 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?
  - cercatrova 4y ago
    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.
    - rob-olmos 4y ago
      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.
      - cercatrova 4y ago
        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.
    - edgyquant 4y ago
      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?
      - cercatrova 4y ago
        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]? [0] https://stackoverflow.com/questions/51805890/how-to-do-a-simple-join-in-graphql https://stackoverflow.com/questions/51805890/how-to-do-a-sim...
        edgyquant 4y ago
        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. What can graphql do that an ORM can’t?
exclusiv 4y ago
Yes I've also seen a bunch of these apps with extremely chatty graphql calls because it's so convenient! One component just needs 2 pieces of data = graphql call. Another needs more data and they're doing another similar call. And so on. You got query flexibility but now you are drowning in additional network requests because it's so easy for your team to just "query for what they want". To me, if your application doesn't need to have the flexibility in querying, then it isn't worth it. Is your dataset so large you don't wish to overfetch data (you can do that without graphql anyway)? Do you need ad-hoc querying in your UIs? Think about your data, how you will need to expose it and expose it.
- cercatrova 4y ago
  Seems you're not familiar with recent advances. GraphQL servers have the ability to collate requests together and only redo a query when data changes instead of "whenever they want" because the client and server know exactly what data is used for which component. This video describes how this is done in Relay but it can exist in other servers too: https://www.youtube.com/watch?v=KT3XKDBZW7M https://www.youtube.com/watch?v=KT3XKDBZW7M
  - exclusiv 4y ago
    That doesn't prevent your frontend and components from making a ton of extra network requests because graphql makes it easy for frontend devs to do fire a new query for their component. Simple example: 1. header component - dev queries user for first name to do a welcome message. 2. sidebar component - another dev does a query for first/last/avatar/profile/etc. Your app sends 2 network calls. Certainly it doesn't have to, but I've seen this chattiness get implemented. So you avoided overfetching of data like official REST APIs but now you have more network calls.
    - cercatrova 4y ago
      Yes, it does. As I explained, GraphQL servers can see which requests should be collated and deduplicated and puts them all into one request. For example, Relay: > Relay combines the advantages of both of these approaches by allowing components to specify what data they require, but to coalesce those requirements into a single query that fetches the data for an entire subtree of components. In other words, it determines statically (i.e. before your application runs; at the time you write your code) the requirements for an entire view! > This is achieved with the help of GraphQL. Functional components use one or more GraphQL fragments to describe their data requirements. These fragments are then nested within other fragments, and ultimately within queries. And when such a query is fetched, Relay will make a single network request for it and all of its nested fragments. In other words, the Relay runtime is then able to make a single network request for all of the data required by a view! https://relay.dev/docs/principles-and-architecture/thinking-in-relay/ https://relay.dev/docs/principles-and-architecture/thinking-...

cercatrova 4y ago

Not sure I understand because I use GraphQL with an ORM, Prisma with Postgres and Pothos which converts the Prisma schema into GraphQL types. It even has the ability to use Redis as a store. So we get all the features of an ORM and also typesafe queries.

edgyquant 4y ago
Right my point is that 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?
- cercatrova 4y ago
  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.
  - rob-olmos 4y ago
    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.
    - cercatrova 4y ago
      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.
  - edgyquant 4y ago
    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?
    - cercatrova 4y ago
      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]? [0] https://stackoverflow.com/questions/51805890/how-to-do-a-simple-join-in-graphql https://stackoverflow.com/questions/51805890/how-to-do-a-sim...
      - edgyquant 4y ago
        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. What can graphql do that an ORM can’t?

exclusiv 4y ago

Yes I've also seen a bunch of these apps with extremely chatty graphql calls because it's so convenient! One component just needs 2 pieces of data = graphql call. Another needs more data and they're doing another similar call. And so on. You got query flexibility but now you are drowning in additional network requests because it's so easy for your team to just "query for what they want". To me, if your application doesn't need to have the flexibility in querying, then it isn't worth it. Is your dataset so large you don't wish to overfetch data (you can do that without graphql anyway)? Do you need ad-hoc querying in your UIs? Think about your data, how you will need to expose it and expose it.

cercatrova 4y ago
Seems you're not familiar with recent advances. GraphQL servers have the ability to collate requests together and only redo a query when data changes instead of "whenever they want" because the client and server know exactly what data is used for which component. This video describes how this is done in Relay but it can exist in other servers too: https://www.youtube.com/watch?v=KT3XKDBZW7M https://www.youtube.com/watch?v=KT3XKDBZW7M
- exclusiv 4y ago
  That doesn't prevent your frontend and components from making a ton of extra network requests because graphql makes it easy for frontend devs to do fire a new query for their component. Simple example: 1. header component - dev queries user for first name to do a welcome message. 2. sidebar component - another dev does a query for first/last/avatar/profile/etc. Your app sends 2 network calls. Certainly it doesn't have to, but I've seen this chattiness get implemented. So you avoided overfetching of data like official REST APIs but now you have more network calls.
  - cercatrova 4y ago
    Yes, it does. As I explained, GraphQL servers can see which requests should be collated and deduplicated and puts them all into one request. For example, Relay: > Relay combines the advantages of both of these approaches by allowing components to specify what data they require, but to coalesce those requirements into a single query that fetches the data for an entire subtree of components. In other words, it determines statically (i.e. before your application runs; at the time you write your code) the requirements for an entire view! > This is achieved with the help of GraphQL. Functional components use one or more GraphQL fragments to describe their data requirements. These fragments are then nested within other fragments, and ultimately within queries. And when such a query is fetched, Relay will make a single network request for it and all of its nested fragments. In other words, the Relay runtime is then able to make a single network request for all of the data required by a view! https://relay.dev/docs/principles-and-architecture/thinking-in-relay/ https://relay.dev/docs/principles-and-architecture/thinking-...