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

91–100 of 116 posts

Re: The GraphQL stack: How everything fits together

#91

Post by scotty79 »

typon wrote: post #42
jasode wrote: post #36

Earlier quoted context omitted.

>, you now don't just expose a couple of endpoints, you need to support a query language, Here's how I think of it. (Others can correct or elaborate my understanding.) Let's say you have 1 REST endpoint such as "xyz.com/customerlist" to return a JSON response and behind the implementation is a SQL "SELECT ∗ FROM T" and you get back a 100k response with all rows and all columns. You really only wanted customer's name…

What if you had one one endpoint called xyz.com/sqlquery and you would just send it a SQL Query in the form a string, the server would validate it and authorize it and return the data or reject the request. Is that different than GraphQL?

The difference is that you'd have to have very smart query builder on the front end side that would construct one sql query from combined declared needs of all the front-end components on one page. Then after it gets response (flat as is usual with sql) it would have to split it up and feed to all of the components.

On the backend you'd probably need sql query analyser that would figure out which tables and rows query touches to determine if currently logged in user should be able to see this data.

So on frontend you need a language in which components can specify their needs (why not graphql?). Next step is asking youself why flatten those to sql before sending them to server only to have it parsed again by the server. It's easier to pass them as grqphql and let server decide if it should respond and draw from data source (or possibly multilple data sources, for example solr and database).

Congrats, you invented graphql. Too bad nobody came up with that 15 years ago, this could save a lot of people a lot of trouble.

Re: The GraphQL stack: How everything fits together

#92

Post by SkyPuncher »

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…

> Why startups are adopting this without that sort of problem, I have no idea. Because the query syntax is pretty?

IMO, we're seeing a trend where the server doesn't necessarily strongly control what's sent to the client. You can build and deploy a simple server then move most complex logic to the client.

It seems to make the development process a lot easier since you really only need to write client side data.

That being said, I don't intend to use GraphQL anytime soon. It seems to be a bit of a loose cannon.

Re: The GraphQL stack: How everything fits together

#93

Post by AzzieElbab »

dmitriid wrote: post #67
djmashko2 wrote: post #58

Earlier quoted context omitted.

(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 t…

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 ?

Re: The GraphQL stack: How everything fits together

#94

Post by cheald »

k__ wrote: post #90
cheald wrote: post #75

Earlier quoted context omitted.

That's entirely up to you and how you choose to implement your fields' resolutions.

Are there any best practices?

I don't know if there are for GraphQL in particular. I have my GraphQL implementation as a part of a Ruby app. graphql-ruby has this handy error handling doc: https://github.com/rmosolgo/graphql-ruby/blob/master/guides/... and there's the graphql-errors gem which sort of does this in a generic manner, allowing individual fields to fail without the whole query failing: https://github.com/exAspArk/graphql-errors

Re: The GraphQL stack: How everything fits together

#95

Post by CodesInChaos »

Touche wrote: post #84
CodesInChaos wrote: post #64

Earlier quoted context omitted.

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.

Another thing that sounds worthy when working on gigantic teams and less so when at a startup / small company.

It's mainly useful if the API consumers are outside your own company. For example my company is a small B2B SaaS startup and our customers integrate themselves into our platform via a web api.

Re: The GraphQL stack: How everything fits together

#96

Post by elnygren »

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.

If you're proposing that web servers should not exist and we should just expose the SQL DB via HTTP: what about when you don't have all of your data in a single database?

What if I want/need Cassandra, ElasticSearch or MongoDB? An SQL DB is just one place where you have data and there are very valid reasons for using other solutions.

In fact, some people might argue that you want to do everything with event sourcing / kappa and use Kafka + specialised data stores.

GraphQL fits this universe perfectly. It also fits the one where you only use a single SQL DB since a GraphQL query translates quite nicely to SQL with minimal amount of code in between.

Re: The GraphQL stack: How everything fits together

#97

Post by dragonwriter »

elnygren wrote: post #96
guelo wrote: post #31

Earlier quoted context omitted.

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.

If you're proposing that web servers should not exist and we should just expose the SQL DB via HTTP: what about when you don't have all of your data in a single database? What if I want/need Cassandra, ElasticSearch or MongoDB? An SQL DB is just one place where you have data and there are very valid reasons for using other solutions. In fact, some people might argue that you want to do everything with event sourcing…

Using SQL as a query language doesn't limit your choice of backend data source(s) any more than using GraphQL does.

Re: The GraphQL stack: How everything fits together

#98

Post by dmitriid »

AzzieElbab wrote: post #93
dmitriid wrote: post #67

Earlier quoted context omitted.

> 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 t…

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 scenario would be on the server for this request in GraphQL

For REST you would look at actual use cases and design for that.

Most likely something like

    GET  /user/1?filter=friends&by=D
    Accept: application/vnd.my.user-full+json

    GET  /user/1/fof
    Accept: application/vnd.my.user-full+json

Re: The GraphQL stack: How everything fits together

#99

Post by kyberias »

djmashko2 wrote: post #83
kyberias wrote: post #80

How is this different, better, worse than OData? http://www.odata.org/

Jonas Helfer gave a talk about this: https://www.youtube.com/watch?v=coU6OmISOBM

That wasn't very objective or thorough comparison. But I certainly learned that the guy didn't like OData.

Re: The GraphQL stack: How everything fits together

#100

Post by otto_ortega »

djmashko2 wrote: post #52
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…

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

Could you please elaborate on that? Im new to GraphQL and I assumed that you only have to provide it with a schema that defines entities and their relations and it will let you query any combination over it.

Does queries have to be explicitly set on the server? As an example, if I have the table "doctors" that has a 1:n relationship with the table "patients", do I have to explicitly define something like:

queryDoctors { id name patients { id name } }

To be able to query a doctor's patients?

Post reply on HN