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

101–110 of 116 posts

Re: The GraphQL stack: How everything fits together

#101

Post by yen223 »

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.

Not only do we know exactly what fields the API consumers are using, we also know the types they're expecting. We can make schema refactors fairly safely. That goes a long way towards making the codebase less brittle as a whole

Re: The GraphQL stack: How everything fits together

#102

Post by kazagistar »

lomereiter wrote: post #77
kazagistar wrote: post #59

Earlier quoted context omitted.

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

It could have better documentation but here's the Java client for Android: https://github.com/apollographql/apollo-android There's also a Swift client available: https://www.apollographql.com/docs/ios/

That looks pretty decent indeed, and makes me a lot more hopeful about the promises of GraphQL, but it sounds like its an Android specific implementation, rather then something I could actually use for JVM service-to-service communication.

Re: The GraphQL stack: How everything fits together

#103

Post by abritinthebay »

boubiyeah wrote: post #89
abritinthebay wrote: post #88

Earlier quoted context omitted.

Chose the right tech early and you’ll have less growth pain. I can’t tell you the number of startups I’ve seen that spend time thrashing on their REST APIs who would be better off using GraphQL as the consumable interface. Would have made many companies supplication development go WAY smoother

You're saying "graphQL is always better than REST for new/small companies"; that's simply not true. It's a tradeoff. Same with (g)RPC. Just like you wouldn't buy and install 20 powerful servers to run kafka on day 1 just in case your startup meet huge success in 2 years.

I did not say that at all, I urge you to re-read what I wrote.

Re: The GraphQL stack: How everything fits together

#105

Post by AzzieElbab »

dmitriid wrote: post #98
AzzieElbab wrote: post #93

Earlier quoted context omitted.

but even in your example, you already made 2 rest requests as opposed to 1 via graphql. What if your scenario is to GET all friends whose names start with D of friends of a friend ?

> but even in your example, you already made 2 rest requests as opposed to 1 via graphql. You can easily mitigate that with something like: GET /user/1 Accept: application/vnd.my.user-full+json Where the server will return full data if the client sends `application/vnd.my.users-full` Accept header > What if your scenario is to GET all friends whose names start with D of friends of a friend ? I really wonder what your…

why "mitigate" anything when you are given a language specifically designed to describe and solve these types of problems? Of course, you can create a custom end-point for any type of request. The point is, you do not really have to. Also, as far as scenarios in the real world go, traversing some kind of graph is practically everyday kind of thing, from structured organizations to billing to who follows a guy who liked some tweet to things like snomed

Re: The GraphQL stack: How everything fits together

#107

Post by dmitriid »

AzzieElbab wrote: post #105
dmitriid wrote: post #98

Earlier quoted context omitted.

> but even in your example, you already made 2 rest requests as opposed to 1 via graphql. You can easily mitigate that with something like: GET /user/1 Accept: application/vnd.my.user-full+json Where the server will return full data if the client sends `application/vnd.my.users-full` Accept header > What if your scenario is to GET all friends whose names start with D of friends of a friend ? I really wonder what your…

why "mitigate" anything when you are given a language specifically designed to describe and solve these types of problems? Of course, you can create a custom end-point for any type of request. The point is, you do not really have to. Also, as far as scenarios in the real world go, traversing some kind of graph is practically everyday kind of thing, from structured organizations to billing to who follows a guy who lik…

> given a language specifically designed to describe and solve these types of problems

It's not a first language "specifically designed" and not the last. It is a language designed to solve Facebook's problems. Do you have Facebook's problems? I highly doubt it :)

Meanwhile there are multiple questions that are left unanswered in all the "GraphQL is amazing" articles:

- caching. Where is it? How do you do it? Official docs on caching are laughable at best [1]

- data access. With ad-hoc queries how do you make sure the right people get the right data? GraphQL docs on that are equally laughable [2]

- how do you make sure the server doesn't buckle under ad-hoc uncacheable queries where auth is solved by "passing a fully-hydrated object instead of an opaque token or API key to your business logic layer". Oh, hey, if you rely on microservices, and you need to return only a subset of data for the query, how do you do that? Remember, all queries are ad-hoc.

There are definitely more issues than the ones right off the top of my head. Such as "data collocation", "mutations are guaranteed to execute sequentially" etc.

[1] http://graphql.org/learn/caching/

[2] http://graphql.org/learn/authorization/

Re: The GraphQL stack: How everything fits together

#108

Post by magic_quotes »

dmitriid wrote: post #107
AzzieElbab wrote: post #105

Earlier quoted context omitted.

why "mitigate" anything when you are given a language specifically designed to describe and solve these types of problems? Of course, you can create a custom end-point for any type of request. The point is, you do not really have to. Also, as far as scenarios in the real world go, traversing some kind of graph is practically everyday kind of thing, from structured organizations to billing to who follows a guy who lik…

> given a language specifically designed to describe and solve these types of problems It's not a first language "specifically designed" and not the last. It is a language designed to solve Facebook's problems. Do you have Facebook's problems? I highly doubt it :) Meanwhile there are multiple questions that are left unanswered in all the "GraphQL is amazing" articles: - caching. Where is it? How do you do it? Officia…

> "GraphQL is amazing" articles

Considering how bad most of the web technology is, anything reasonably designed is probably going to be overhyped. It's important to realize that graphql is not some kind of magic graph query language, it's actually a very simple RPC protocol allowing you to submit multiple calls per network request in a tree shape (which is a very neat idea btw). It also has a schema. You still have to solve all the hard problems yourself, but there is a hope that since graphql is relatively popular and not as dysfunctional as SOAP or simplistic as a typical bespoke schemaless one-call-per-request RPC protocol (e.g. non-HATEOAS "REST"), it might be ok target for writing some actually useful utility middleware libraries and dev tools. That's pretty much the whole reason for all the excitement.

Re: The GraphQL stack: How everything fits together

#109

Post by AzzieElbab »

magic_quotes wrote: post #108
dmitriid wrote: post #107

Earlier quoted context omitted.

> given a language specifically designed to describe and solve these types of problems It's not a first language "specifically designed" and not the last. It is a language designed to solve Facebook's problems. Do you have Facebook's problems? I highly doubt it :) Meanwhile there are multiple questions that are left unanswered in all the "GraphQL is amazing" articles: - caching. Where is it? How do you do it? Officia…

> "GraphQL is amazing" articles Considering how bad most of the web technology is, anything reasonably designed is probably going to be overhyped. It's important to realize that graphql is not some kind of magic graph query language, it's actually a very simple RPC protocol allowing you to submit multiple calls per network request in a tree shape (which is a very neat idea btw). It also has a schema. You still have t…

exactly, most web apis feel like kv stores build on top of sql

Re: The GraphQL stack: How everything fits together

#110

Post by exogen »

guelo wrote: post #31
elnygren wrote: post #27

Earlier quoted context omitted.

This question does not make much sense: a GraphQL API can an often is implemented with SQL ! You could ask: why graphql instead of RESTful?

Of course it makes sense. They're both query languages, right? Why is { project(name: "GraphQL") { tagline } } Better than select tagline from project where name = "GraphQL" Especially if the GraphQL server is just an intermediary later that ends up being translated to SQL anyway. That real answer to the parent's question is that most people don't have confidence in SQL servers's access controls.

One immediate improvement: SQL queries return rows of scalars. It's very tedious to reconstruct nested objects from the resulting column aliases that are ultimately necessary (and in this case, the client would even need to do it all themselves!). Your example is simplistic in that it requests one top-level scalar, but any real API will not be like that. Try:

    {
      project(name: "GraphQL") {
        tagline
        authors {
          name
          friends {
            name
          }
        }
      }
    }
Post reply on HN