3 ms·

Hmm, are you talking about performance here? I'm talking about developer efficiency and code complexity. Sorry, should have been more clear about that.

• dmitriid 8y ago
  Of course we are talking about performance. When someone carelessly says "40 unforseen composable views towards 10 tables" or (as a recent article on HN mentioned [1]) "You should find yourself being able to build a query that delves 4+ relations deep without much trouble", I find myself asking: at what cost?. There's no magic in this world. And yet, no one seems to address the question of the server. If you have 10 tables and 40 composable views, most of those views will end up highly inefficient queries towards the database (possibly with multiple roundtrips). And that's on top of many other concerns: https://news.ycombinator.com/item?id=17293337 https://news.ycombinator.com/item?id=17293337 [1] https://news.ycombinator.com/item?id=17269028 https://news.ycombinator.com/item?id=17269028
  • worldsayshi 8y ago
    "we are talking about performance" - Well, I was not. My comment was not about performance.
    • dmitriid 8y ago
      Well, that's the problem, isn't it? You can always carelessly say "ah, it's magically gives you magical capabilities of magically making 40 composable views that magically make everything shiny." But then the hard questions come. It's no surprise that there are so few GraphQL resources, blogs, docs, posts, proponents that talk about performance on the server.