4 ms·

graphql on postgres is literally orm. objects are graphs. and graphql inherits all the same problems as the last 1000 attempts to do this. unless you're faceboo

graphql on postgres is literally orm. objects are graphs. and graphql inherits all the same problems as the last 1000 attempts to do this. unless you're facebook who uses an eventually consistent graph datastore!

sorenbs 9y ago
Developers run into all kinds of trouble when they use an orm without understanding the underlying execution model. Before starting Graphcool I lead the team that scaled a consumer site into the top 1000 visited sites globally. A well tuned SQL server and Hibernate took us a long way :-) One of the biggest foot guns when working with ORMs is lazy data loading. This is a feature implemented by most advanced ORMs that allow the developer to pretend that the entire data model is in memory without having to actually fetch all data on every request. The reason this is so dangerous is that you end up passing objects around that other developers then misuse to fetch "just a little more data". Over time this can lead to tens or hundreds of roundtrips to the database for a single request. GraphQL tackles this issue head on by encouraging the developer to specify all data dependencies up front. Client side tools like Apollo and Relay even help you collect data requirements from multiple related components and construct a minimal covering query. This means that there is only one request, and the underlying query engine has all information available. I'm pretty excited to bring these same concepts to the server with GraphQL Bindings: https://github.com/graphcool/graphql-binding https://github.com/graphcool/graphql-binding
- dustingetz 9y ago
  Declaring data dependencies is interesting, but unfortunately the vision you describe is not possible in the general case. Just in contrived toy cases. You show me a Facebook scale application hydrating its data in one request, and I'll show you that it isn't built on RDBMS. Case in point: Facebook. Case #2: GraphQL has a shitty programming language built into it, to make decisions about data fetching closer to the database. Perhaps we should code the entire app in stored procedures? (which might even actually work)
  - intrasight 9y ago
    Absolutely you should code the entire app in stored procedures. The arguments for doing so have long been stronger than the arguments against doing so.
    - dustingetz 9y ago
      Where can I learn more about this?

sorenbs 9y ago

Developers run into all kinds of trouble when they use an orm without understanding the underlying execution model. Before starting Graphcool I lead the team that scaled a consumer site into the top 1000 visited sites globally. A well tuned SQL server and Hibernate took us a long way :-) One of the biggest foot guns when working with ORMs is lazy data loading. This is a feature implemented by most advanced ORMs that allow the developer to pretend that the entire data model is in memory without having to actually fetch all data on every request. The reason this is so dangerous is that you end up passing objects around that other developers then misuse to fetch "just a little more data". Over time this can lead to tens or hundreds of roundtrips to the database for a single request. GraphQL tackles this issue head on by encouraging the developer to specify all data dependencies up front. Client side tools like Apollo and Relay even help you collect data requirements from multiple related components and construct a minimal covering query. This means that there is only one request, and the underlying query engine has all information available. I'm pretty excited to bring these same concepts to the server with GraphQL Bindings: https://github.com/graphcool/graphql-binding https://github.com/graphcool/graphql-binding

dustingetz 9y ago
Declaring data dependencies is interesting, but unfortunately the vision you describe is not possible in the general case. Just in contrived toy cases. You show me a Facebook scale application hydrating its data in one request, and I'll show you that it isn't built on RDBMS. Case in point: Facebook. Case #2: GraphQL has a shitty programming language built into it, to make decisions about data fetching closer to the database. Perhaps we should code the entire app in stored procedures? (which might even actually work)
- intrasight 9y ago
  Absolutely you should code the entire app in stored procedures. The arguments for doing so have long been stronger than the arguments against doing so.
  - dustingetz 9y ago
    Where can I learn more about this?