3 ms·

The tradeoffs with GraphQL aren't worth it

16 points by kaycebasques 5y ago

hirundo 5y ago
Strong disagree. GraphQL has given our dev teams huge leverage. It's similar to writing a page of HTML rather than the equivalent GUI code. That might not look helpful if you're already a GUI master, but it's a big productivity win for a mixed team of designers and coders. A vague query specification that used to take a week to turn around has now become a precise query specification that we can turn around in under 250ms.
- pastrami_panda 5y ago
  Did you try to figure out why your specifications were vague, or why implementing a query and bringing it to production took several days? Adding another dependency and attack vector before addressing the root cause doesn't sound that healthy.
  - hirundo 5y ago
    The specifications were vague because they were in prose, rather than a formal specification language, and written in an IDE with instant feedback, auto-complete, history and documentation. It took several days to turn around because it took a developer a half day to write the controller code and specs, to debug it, to write the PR and get it approved, to merge the branch and wait for it to be deployed. This half a day was interleaved with a full schedule as available, so routinely took a week. With a formal, executable specification that is a GraphQL query, all of the above goes away. The back-end devs don't even knows about it unless there's a problem.
Flankk 5y ago
It's like everything else in the JS world. A new solution to a solved problem. It takes more than an incremental improvement to outweigh the learning curve and development costs. New things should be an order of magnitude better. If a new technology isn't obviously better then it should be ignored. Developers have shiny object syndrome.
cersa8 5y ago
What I like about GraphQL is how quickly one can start fetching data without considering the API endpoint. Especially for nested data structures where the alternative is using json_build_object queries with PostgreSQL. I use it extensively in admin backends and only switch to a rest endpoint when I have to get too creative with custom functions (PostGraphile). PostGraphile doesn't require much configuration, it introspecting your db and you're good to go. The moment the tradeoffs start to show you add a custom rest endpoint.

16 points by kaycebasques 5y ago

Strong disagree. GraphQL has given our dev teams huge leverage. It's similar to writing a page of HTML rather than the equivalent GUI code. That might not look helpful if you're already a GUI master, but it's a big productivity win for a mixed team of designers and coders. A vague query specification that used to take a week to turn around has now become a precise query specification that we can turn around in under 250ms.

pastrami_panda 5y ago
Did you try to figure out why your specifications were vague, or why implementing a query and bringing it to production took several days? Adding another dependency and attack vector before addressing the root cause doesn't sound that healthy.
- hirundo 5y ago
  The specifications were vague because they were in prose, rather than a formal specification language, and written in an IDE with instant feedback, auto-complete, history and documentation. It took several days to turn around because it took a developer a half day to write the controller code and specs, to debug it, to write the PR and get it approved, to merge the branch and wait for it to be deployed. This half a day was interleaved with a full schedule as available, so routinely took a week. With a formal, executable specification that is a GraphQL query, all of the above goes away. The back-end devs don't even knows about it unless there's a problem.

Flankk 5y ago

It's like everything else in the JS world. A new solution to a solved problem. It takes more than an incremental improvement to outweigh the learning curve and development costs. New things should be an order of magnitude better. If a new technology isn't obviously better then it should be ignored. Developers have shiny object syndrome.

cersa8 5y ago

What I like about GraphQL is how quickly one can start fetching data without considering the API endpoint. Especially for nested data structures where the alternative is using json_build_object queries with PostgreSQL. I use it extensively in admin backends and only switch to a rest endpoint when I have to get too creative with custom functions (PostGraphile). PostGraphile doesn't require much configuration, it introspecting your db and you're good to go. The moment the tradeoffs start to show you add a custom rest endpoint.