Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The GraphQL stack: How everything fits together

dev-blog.apollodata.com

Post reply on HN
Print view View original

61–70 of 116 posts

Re: The GraphQL stack: How everything fits together

#61

Post by djmashko2 »

boubiyeah wrote: post #49
yen223 wrote: post #39

Earlier quoted context omitted.

We've used GraphQL in production for about a year now, alongside some legacy rest APIs. It's a lot easier to maintain the GraphQL endpoint, like it's not even close. GraphQL's secret weapon is the static type definition. We can safely alter fields in the backend, and be notified at compile-time if client-side code is about to break as a result of those changes. We don't have the same guarantees with the rest api, whi…

Are you talking about a single client and its server? (a.k.a backend-for-frontend). This is not a hard problem to solve when you share a single programming language, with or without graphql. Because you can't possibly now what your API consumers use on their side.

> Because you can't possibly now what your API consumers use on their side.

That's the best part - with GraphQL you _do_ know, since people have to ask for every single field they want.

Re: The GraphQL stack: How everything fits together

#62

Post by djmashko2 »

(Author of the post here)

If you aren't yet familiar with GraphQL and the problems it solves, it might be better to watch the talk on YouTube, since it includes much more of an introduction from the start, plus more color and detail: https://www.youtube.com/watch?v=ykp6Za9rM58

The blog post summary glosses over the introduction and focuses on what a GraphQL-familiar audience will find new, so it's all in the context of the current GraphQL community.

You can also catch up on some of the tools and benefits, and see some case studies from people using GraphQL in production, on our Explore GraphQL site: https://www.graphql.com/

Re: The GraphQL stack: How everything fits together

#63

Post by DigitalJack »

I'm an admitted dumbo about this stuff. Here's what it looked like from that point of view:

Hey cool, a new nice looking common query language that can do neat composition of results. Perfect, I've been wanting to break free of the SQL box since forever.

Wait, what? You have to write SQL queries for everything still? So you define types, and have to write SQL queries for those types, and graphQL gives you some composition on top of that?

Seems kind of redundant. Like wrapping your own christmas present.

But then I realize I'm thinking from the perspective of a one/two person team. Perhaps the real value of this comes from very decoupled consumers.

Re: The GraphQL stack: How everything fits together

#64

Post by CodesInChaos »

Touche wrote: post #38
boubiyeah wrote: post #37

GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network. I'm very happy with REST APIs (maturity level 2/3) and see no reason to change as we've never had performance issues. Most companies are not Facebook with 1 billion customers. The fact that clients can compose their own queries brings nothing new, as you still have to allow these capabilities on your server, just like…

Can't upvote this enough. From what I've read it sounds like GraphQL solves a problem at Facebook where they have so many people working on related data at the same time that they started seeing duplicate API endpoints, and duplicate requests for the same data from different parts of the team. GraphQL provides a chokepoint to prevent that from occurring. Makes total sense at that scale. Why startups are adopting this…

A huge selling point for me is that the client explicitly enumerating all fields they're interested in allows targeted deprecation warnings and finely grained usage statistics.

Re: The GraphQL stack: How everything fits together

#65

Post by djmashko2 »

DigitalJack wrote: post #63

I'm an admitted dumbo about this stuff. Here's what it looked like from that point of view: Hey cool, a new nice looking common query language that can do neat composition of results. Perfect, I've been wanting to break free of the SQL box since forever. Wait, what? You have to write SQL queries for everything still? So you define types, and have to write SQL queries for those types, and graphQL gives you some compos…

You're in luck, there are libraries that can do it for you! https://github.com/stems/join-monster

And even a system that generates your whole schema: https://github.com/postgraphql/postgraphql

Plus, the Graphcool framework allows you to bring your own DB: https://github.com/graphcool/framework

Re: The GraphQL stack: How everything fits together

#66

Post by habitue »

DigitalJack wrote: post #63

I'm an admitted dumbo about this stuff. Here's what it looked like from that point of view: Hey cool, a new nice looking common query language that can do neat composition of results. Perfect, I've been wanting to break free of the SQL box since forever. Wait, what? You have to write SQL queries for everything still? So you define types, and have to write SQL queries for those types, and graphQL gives you some compos…

Yeah the benefits are mainly when you have many different consumers all of whom want to look at the data in different ways, or when you have many different data sources in your architecture and want to aggregate them on the fly based on the exact incoming query.

If you're writing rest endpoints for an SPA and you have one backing store, then the benefits are not really there, it's just another layer. There are some nice things in relay like intelligent caching portions of the data and only refetching the parts needed, but it is very likely not worth it if you can just handcraft your endpoints and make your consumer change in sync.

Re: The GraphQL stack: How everything fits together

#67

Post by dmitriid »

djmashko2 wrote: post #58
dmitriid wrote: post #25

> GraphQL knows all of the data requirements for a UI component up front, enabling new types of server functionality. For example, batching and caching underlying API calls within a single query becomes easy with GraphQL. And immediately after that the article spends two pages of text explaining how insanely complex the "becomes easy with GraphQL" really is, and offers no actual details on the "easy" part. Oh, your c…

(Author of the post here) Thanks for the notes! > And immediately after that the article spends two pages of text explaining how insanely complex the "becomes easy with GraphQL" really is, and offers no actual details on the "easy" part. Hi, thanks for this piece of feedback! I could have done a better job here, since I was summarizing a 38 min talk into a few paragraphs. These parts are actually talking about differ…

> a single fetch from the UI knows about all the data it needs, so you can easily avoid multiple roundtrips to the database.

This needs to be backed up by data. In my opinion there's no difference between

    GET /users/1
    GET /users/1/friends
and

    {
      user(id: 1) {
        name
        age
        friends {
          name
        }
      }
    }
Unless the backend is extremely smart and can generate (optimized!) SQL queries on the fly from GraphQL schemas, this will be two trips to the database.

Granted, there's LINQ and some ORMs where you just chain requests. And still... And the above can also be solved by providing an `Accept: application/vnd.my-company.users-full+json` in REST.

> My intention here was to say that GraphQL's ability to understand what fields are being asked for makes it easy to return specific cache controls, rather than having to put one on the whole query.

How? Skimmed through the video. Oh. Right. By providing custom `maxAge` fields to the returned data so that a custom-built gateway (that has to be schema-aware) could build a cache of that data. An exact same thing can be done in REST: add custom fields, develop a custom resolver/caching layer, voila. There is a reason no one is doing that :)

Re: The GraphQL stack: How everything fits together

#68

Post by dmitriid »

magic_quotes wrote: post #51
dmitriid wrote: post #25

> GraphQL knows all of the data requirements for a UI component up front, enabling new types of server functionality. For example, batching and caching underlying API calls within a single query becomes easy with GraphQL. And immediately after that the article spends two pages of text explaining how insanely complex the "becomes easy with GraphQL" really is, and offers no actual details on the "easy" part. Oh, your c…

> REST APIs and we've known how to do them since 2001. Meh. With the exception of usual html+browser example I've yet to see at least one HATEOAS api.

Even non-hateoas services can be quite good ;)

Re: The GraphQL stack: How everything fits together

#69

Post by orclev »

DigitalJack wrote: post #63

I'm an admitted dumbo about this stuff. Here's what it looked like from that point of view: Hey cool, a new nice looking common query language that can do neat composition of results. Perfect, I've been wanting to break free of the SQL box since forever. Wait, what? You have to write SQL queries for everything still? So you define types, and have to write SQL queries for those types, and graphQL gives you some compos…

I think what you're missing is that GraphQL isn't SQL, but rather a SQL-ish query language that supports a limited subset of what SQL does. Additionally, GraphQL lets the server define the schema that's being exposed to the client independent of the actual storage underneath that, including defining and limiting the types of mutations that can be applied. If you were to simply expose the ability for clients to feed SQL queries into your backend then you have to worry about policing those queries, scrubbing problematic values out of the queries, and in general preventing users from doing bad things with your database. By exposing a GraphQL interface you're providing a limited and tightly controlled view into your data, but still allowing the client the freedom to specify the shape and partitioning of the data being returned.

Re: The GraphQL stack: How everything fits together

#70

Post by boubiyeah »

CodesInChaos wrote: post #64
Touche wrote: post #38

Earlier quoted context omitted.

Can't upvote this enough. From what I've read it sounds like GraphQL solves a problem at Facebook where they have so many people working on related data at the same time that they started seeing duplicate API endpoints, and duplicate requests for the same data from different parts of the team. GraphQL provides a chokepoint to prevent that from occurring. Makes total sense at that scale. Why startups are adopting this…

A huge selling point for me is that the client explicitly enumerating all fields they're interested in allows targeted deprecation warnings and finely grained usage statistics.

That's nice yes. Isn't it rare to deprecate fields though? And you can't be sure some of your clients are not overfetching "for convenience / just in case", especially if they don't use the full suite of Facebook libs.
Post reply on HN