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

51–60 of 116 posts

Re: The GraphQL stack: How everything fits together

#51

Post by magic_quotes »

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.

Re: The GraphQL stack: How everything fits together

#52

Post by djmashko2 »

jondubois wrote: post #15

My main concern with GraphQL is access control. What happens if the user doesn't have access to part of the requested data (a subtree)... Will the GraphQL engine return an incomplete result, an inline error or will the whole query fail? What if you only want to allow showing specific fields of a resource; for example when a user requests for another user's account details, we need a way to block them from getting cer…

Hi, author of the post here!

With GraphQL, you can think of each field as a tiny endpoint, and you do access control on that in the same way as before.

It turns out that while GraphQL allows the frontend developers to select the data they need, that doesn't result in an unlimited set of queries. You often get a number of queries which is similar to what you would get if you hand-coded specific endpoints for different UI views, which turns out to be a common pattern outside of GraphQL.

> What happens if the user doesn't have access to part of the requested data

In this case, the gateway just falls back to the underlying server implementation, and it's a cache miss.

Re: The GraphQL stack: How everything fits together

#53

Post by djmashko2 »

jacobr wrote: post #34
JackuB wrote: post #21

Earlier quoted context omitted.

It got more approachable for me when I started to think about it as a specific "backend for frontend" pattern. I don't see it as a _real_ competitor to REST, even though it's trying to market itself this way. I think recent "@rest" addition from Apollo ( https://dev-blog.apollodata.com/apollo-client-2-0-5c8d0affce... ) shows they can easily live together - backend uses REST and frontend can rely on GraphQL.

I would say Backend For Frontend solves the same problems for most people, and the tooling around REST is available everywhere. http://samnewman.io/patterns/architectural/bff/ We have data repositories living behind very simple REST controllers, an endpoint probably doesn't take that much longer to write than a GraphQL query.

(Author of the post here)

I think there are 2 differences:

1. It's very very easy to write a GraphQL query, since GraphQL comes with auto-completing tools to do so. Even non-technical staff at our company often use it to get information about customers, etc. 2. The query is written inside the client codebase, which means you don't need to redeploy the server in response to a change in client data requirements. This reduces a significant amount of the friction caused by frontend features needing to wait on backend deploys.

Other than that, you've got it 100%: GraphQL is a technology to make the Backend For Frontend pattern much easier and more flexible.

Re: The GraphQL stack: How everything fits together

#54

Post by lmm »

yen223 wrote: post #39
d3ckard wrote: post #20

Earlier quoted context omitted.

That I understand. The problem is that on the way you basically reduce your server to the thin layer over DB. Exposing querying API means that you significantly lose control over what, where and how you provide from the server. We are currently considering using GraphQL in current project and I took a long look at both the standard and library (Absinthe for Elixir). It looks terrible to me. Basically you need to prov…

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…

> 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.

I think that's an immensely useful thing to do - that's why I've been doing it for years by using Thrift instead of REST :). Is there still a value proposition for GraphQL if I'm already using strongly typed interfaces?

Re: The GraphQL stack: How everything fits together

#55

Post by djmashko2 »

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…

(Author of the post here)

> GraphQL is above all, just an optimization. It optimizes the amount of bytes sent over the network.

This was a common thought when GraphQL was first announced, but working with organizations that are adopting it we've found just the opposite: It's actually the tooling and development velocity benefits that people get the most value of.

It's kind of like if you could design your API to be super orthogonal and fine-grained, while still getting the optimized network transport of hand-coded endpoints for each view.

> The whole "just cache it on the client" is a big joke and many people seem to underestimate getting caching right.

The post goes over a new architecture specifically for server-side caching. Caching on the client is definitely not sufficient! And Relay isn't the way most people are doing GraphQL today. Also, clients are about to start supporting cache control and TTLs, making life a lot easier. I'm curious what the comparison here is, since people using technologies like Redux with REST APIs are also usually caching responses forever.

This is really useful feedback for those of us that think GraphQL is going to be a super important technology going forward, and I hope you give it another shot in a year or two! It's still pretty fresh, especially compared to REST, but I think it will improve quickly :]

Re: The GraphQL stack: How everything fits together

#57

Post by dudul »

jondubois wrote: post #15

My main concern with GraphQL is access control. What happens if the user doesn't have access to part of the requested data (a subtree)... Will the GraphQL engine return an incomplete result, an inline error or will the whole query fail? What if you only want to allow showing specific fields of a resource; for example when a user requests for another user's account details, we need a way to block them from getting cer…

Access control and permissions shouldn't be part of your API implementation, either REST or GraphQL. It should be part of your business logic so it can be shared regardless of which API protocol you put on top of it.

Re: The GraphQL stack: How everything fits together

#58

Post by djmashko2 »

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 different concepts:

The first is about ensuring that a single fetch from the UI knows about all the data it needs, so you can easily avoid multiple roundtrips to the database. This is something you can do with a basic in-process caching tool called DataLoader: https://github.com/facebook/dataloader

The second is about caching _across_ requests, something that people usually have special infrastructure for in REST, such as Varnish. This talk was elaborating on how a GraphQL-specific piece of caching infrastructure might work, and sit in exactly the same place as REST caching.

> Oh, your client has to be cache aware.

I think the intention was to say that it _could_ be cache aware. It doesn't need to be, but you end up with a really nice situation.

> I would love to see an explanation how GraphQL makes caching for this easy.

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. So your server basically generates the control for you (this is something that exists today)

> It's called REST APIs and we've known how to do them since 2001.

I don't think REST has a way to automatically combine multiple REST services, and then query them all in one HTTP request without multiple roundtrips to the client, which was the goal here.

Happy to talk more, and thank you for bringing up some of the places where I can communicate more clearly in the future! The audience of the talk was a GraphQL conference, but I should definitely consider next time that people who aren't already bought into the idea of GraphQL will be taking a look as well.

Re: The GraphQL stack: How everything fits together

#59

Post by kazagistar »

Cthulhu_ wrote: post #32
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…

> It's called REST APIs and we've known how to do them since 2001. The aim of GraphQL insofar as I understand it is that instead of having to develop two things (a front-end and a back-end REST API that talks to your database or other services), you need just one (a front-end that talks to GraphQL). Mind you, graphQL becomes the back-end-for-front-end then, and will still need a lot of work. The main point is that wi…

> you'll only need one for all of your apps,

So where are my clients for statically typed languages? I looked into GraphQL and promptly dropped it cause I couldn't seem to call into it from Java in any sensible way. If all your "apps" are javascript, maybe this is true, but that hardly makes it a universal technology.

Re: The GraphQL stack: How everything fits together

#60

Post by jamesmp98 »

kazagistar wrote: post #59
Cthulhu_ wrote: post #32

Earlier quoted context omitted.

> It's called REST APIs and we've known how to do them since 2001. The aim of GraphQL insofar as I understand it is that instead of having to develop two things (a front-end and a back-end REST API that talks to your database or other services), you need just one (a front-end that talks to GraphQL). Mind you, graphQL becomes the back-end-for-front-end then, and will still need a lot of work. The main point is that wi…

> you'll only need one for all of your apps, So where are my clients for statically typed languages? I looked into GraphQL and promptly dropped it cause I couldn't seem to call into it from Java in any sensible way. If all your "apps" are javascript, maybe this is true, but that hardly makes it a universal technology.

lol it's 2017 use JS for everything you pleb
Post reply on HN