4 ms·

Imagine you have a cross-platform app with multiple teams. You have a lot of data-driven components like different feed types. You want to avoid situations that

Imagine you have a cross-platform app with multiple teams. You have a lot of data-driven components like different feed types. You want to avoid situations that change in backed API needs to be synced with every team/app. You want to give power to app developers to define efficient queries. Unless you develop multiple apps or data-driven application there is very little reason to use GraphQL. Personally, I am in favor of building two APIs: public/third party REST and JSON-RPC for the frontend. Getting REST right is difficult and after you create your resources your frontend needs to workaround incomplete/superfluous data.

dmitriid 8y ago
This doesn't answer my question :) You still have 10 tables, and you still have 40 ineffecient ad-hoc views into that database. Why is it that any text, and post, and comment about GraphQL focused on client-side only and completely ignores any questions about server-side?
- Chyzwar 8y ago
  Because your source data will be like 10 tables. But your frontend needs to access this data in different ways (views). There no way to design your database to support all possible queries in an efficient way. With complex queries even caching become tricky. user(id = 6) -> with ('comments') -> with ('votes') ORM - create a complex query that hit three tables. There is no way to represent this as proper REST service (/userNameWithCommentsVotes - resource). You end up with REST resources that accept a lot query params. Each endpoint will create coupling to both data storage and consumer (front-end). User (id = 6) { name comments { votes: { up down } } } GraphQL shift data access towards the client. It will make multiple DB queries but it will be trivially cached using Dataloader pattern. You hit DB more with simple queries but you don't muddle you data schema with ad-hock views/queries. People start with pretty REST and normalized Database, then frontend and third-party requirements demolish this to another "Paypal API". I am not saying that GraphQL is a silver bullet, you need to structure your frontend application Graph as well and complex conditional queries are difficult to express.
  - dmitriid 8y ago
    > ORM - create a complex query that hit three tables. 1. ORM isn't a requirement for REST 2. A REST endpoint will execute a highly specialised query that will hit all the right database indices and will return just the dataset required in one roundtrip to the database. And since it's a known quantity, it will benefit from: hot db indices and caches, intermediate caches, and even HTTP caches (because GET requests are both idempotent and cacheable, for example). Meanwhile with GraphQL your server will have execute what's essentially `SELECT <all>` three times (otherwise your "dataloader" won't be able to cache data for more complex queries) and do all the filtering and joins in-memory in-code. > GraphQL shift data access towards the client. Hahahha wat? The client has no access to data. The only thing it does is send a query request to the server. The server will parse the query. The server will request data from the database (multiple times). The server will end up joining, filtering out, caching, figuring out proper auth access to, etc. etc. to data. And only then will that data will be returned to the client in the form that the client requested. The client has no access to data. The only thing that the client can do is ad-hoc potentially non-perfromant queries to the server. > You hit DB more with simple queries but you don't muddle you data schema with ad-hock views/queries. Yup. You only muddle your code with those queries (the code needs to find a way to compose/filter out/etc. etc. etc. the data for the ad-hoc queries from the client). And you only do multiple redundant and expensive trips to the database (what happens when the DB is sharded, and some data required for the query lies in a different shard? What happens when connections are slow/interrupted? etc. etc.) > it will be trivially cached using Dataloader pattern. No it won't. Dataloader only caches some data during one request. On the next request you will do the same: expensive multiple roundtrips to the database. Oh. By the way. Remember how you dismissed ORM? Well, your dataloaders and data resolvers (and whatever other new lingo GraphQL came up with) is nothing but a very limited and inefficient ORM.
    - Chyzwar 8y ago
      > A REST endpoint will execute a highly specialised query that will hit all the right database indices and will return just the dataset required in one roundtrip to the database. Each time you need to have a new highly specialized query you create REST resource. That why I prefer to be honest and just make RPC call. > Meanwhile with GraphQL your server will have execute what's essentially `SELECT <all>` three times (otherwise your "dataloader" won't be able to cache data for more complex queries) and do all the filtering and joins in-memory in-code. That fine, because easy cache invalidation is worth it. You will find that REST complex endpoints will take cache the same data multiple times. > Hahahha wat? The client has no access to data. The only thing it does is send a query request to the server. The server will parse the query. The server will request data from the database (multiple times). The server will end up joining, filtering out, caching, figuring out proper auth access to, etc. etc. to data. I said data access, not data. The benefit of GraphQL materializes when you have multiple client application that targets same backend data store. You describe your data schema and clients can figure out what data they need. > Yup. You only muddle your code with those queries (the code needs to find a way to compose/filter out/etc. etc. etc. the data for the ad-hoc queries from the client). And you only do multiple redundant and expensive trips to the database (what happens when the DB is sharded, and some data required for the query lies in a different shard? What happens when connections are slow/interrupted? etc. etc.) You have cache. Having only one copy of user in the cache is super important. GraphQL is not creating expensive queries. With GraphQL it is easier to shard your DB because you will have less joins. > No it won't. Dataloader only caches some data during one request. On the next request you will do the same: expensive multiple roundtrips to the database. Dataloader supports any Cache backend. In production, you will use something like Redis. Whole point dataloader is to cache between requests. Its supports cache invalidation as well. > Oh. By the way. Remember how you dismissed ORM? Well, your dataloaders and data resolvers (and whatever other new lingo GraphQL came up with) is nothing but a very limited and inefficient ORM. No, they are query interface. They expose DSL for accessing data. Mapping is something that can be done in Relay.

dmitriid 8y ago

This doesn't answer my question :) You still have 10 tables, and you still have 40 ineffecient ad-hoc views into that database. Why is it that any text, and post, and comment about GraphQL focused on client-side only and completely ignores any questions about server-side?

Chyzwar 8y ago
Because your source data will be like 10 tables. But your frontend needs to access this data in different ways (views). There no way to design your database to support all possible queries in an efficient way. With complex queries even caching become tricky. user(id = 6) -> with ('comments') -> with ('votes') ORM - create a complex query that hit three tables. There is no way to represent this as proper REST service (/userNameWithCommentsVotes - resource). You end up with REST resources that accept a lot query params. Each endpoint will create coupling to both data storage and consumer (front-end). User (id = 6) { name comments { votes: { up down } } } GraphQL shift data access towards the client. It will make multiple DB queries but it will be trivially cached using Dataloader pattern. You hit DB more with simple queries but you don't muddle you data schema with ad-hock views/queries. People start with pretty REST and normalized Database, then frontend and third-party requirements demolish this to another "Paypal API". I am not saying that GraphQL is a silver bullet, you need to structure your frontend application Graph as well and complex conditional queries are difficult to express.
- dmitriid 8y ago
  > ORM - create a complex query that hit three tables. 1. ORM isn't a requirement for REST 2. A REST endpoint will execute a highly specialised query that will hit all the right database indices and will return just the dataset required in one roundtrip to the database. And since it's a known quantity, it will benefit from: hot db indices and caches, intermediate caches, and even HTTP caches (because GET requests are both idempotent and cacheable, for example). Meanwhile with GraphQL your server will have execute what's essentially `SELECT <all>` three times (otherwise your "dataloader" won't be able to cache data for more complex queries) and do all the filtering and joins in-memory in-code. > GraphQL shift data access towards the client. Hahahha wat? The client has no access to data. The only thing it does is send a query request to the server. The server will parse the query. The server will request data from the database (multiple times). The server will end up joining, filtering out, caching, figuring out proper auth access to, etc. etc. to data. And only then will that data will be returned to the client in the form that the client requested. The client has no access to data. The only thing that the client can do is ad-hoc potentially non-perfromant queries to the server. > You hit DB more with simple queries but you don't muddle you data schema with ad-hock views/queries. Yup. You only muddle your code with those queries (the code needs to find a way to compose/filter out/etc. etc. etc. the data for the ad-hoc queries from the client). And you only do multiple redundant and expensive trips to the database (what happens when the DB is sharded, and some data required for the query lies in a different shard? What happens when connections are slow/interrupted? etc. etc.) > it will be trivially cached using Dataloader pattern. No it won't. Dataloader only caches some data during one request. On the next request you will do the same: expensive multiple roundtrips to the database. Oh. By the way. Remember how you dismissed ORM? Well, your dataloaders and data resolvers (and whatever other new lingo GraphQL came up with) is nothing but a very limited and inefficient ORM.
  - Chyzwar 8y ago
    > A REST endpoint will execute a highly specialised query that will hit all the right database indices and will return just the dataset required in one roundtrip to the database. Each time you need to have a new highly specialized query you create REST resource. That why I prefer to be honest and just make RPC call. > Meanwhile with GraphQL your server will have execute what's essentially `SELECT <all>` three times (otherwise your "dataloader" won't be able to cache data for more complex queries) and do all the filtering and joins in-memory in-code. That fine, because easy cache invalidation is worth it. You will find that REST complex endpoints will take cache the same data multiple times. > Hahahha wat? The client has no access to data. The only thing it does is send a query request to the server. The server will parse the query. The server will request data from the database (multiple times). The server will end up joining, filtering out, caching, figuring out proper auth access to, etc. etc. to data. I said data access, not data. The benefit of GraphQL materializes when you have multiple client application that targets same backend data store. You describe your data schema and clients can figure out what data they need. > Yup. You only muddle your code with those queries (the code needs to find a way to compose/filter out/etc. etc. etc. the data for the ad-hoc queries from the client). And you only do multiple redundant and expensive trips to the database (what happens when the DB is sharded, and some data required for the query lies in a different shard? What happens when connections are slow/interrupted? etc. etc.) You have cache. Having only one copy of user in the cache is super important. GraphQL is not creating expensive queries. With GraphQL it is easier to shard your DB because you will have less joins. > No it won't. Dataloader only caches some data during one request. On the next request you will do the same: expensive multiple roundtrips to the database. Dataloader supports any Cache backend. In production, you will use something like Redis. Whole point dataloader is to cache between requests. Its supports cache invalidation as well. > Oh. By the way. Remember how you dismissed ORM? Well, your dataloaders and data resolvers (and whatever other new lingo GraphQL came up with) is nothing but a very limited and inefficient ORM. No, they are query interface. They expose DSL for accessing data. Mapping is something that can be done in Relay.