←back to thread

How and why GraphQL will influence the Sourcehut alpha

(sourcehut.org)
153 points michaelanckaert | 5 comments | 11 Jun 20 04:46 UTC | HN request time: 1.179s | source
Show context
WhatIsDukkha ◴[11 Jun 20 06:44 UTC] No.23485847[source]▶
I don't understand the attraction to Graphql. (I do understand it if maybe you actually want the things that gRPC or Thrift etc gives you)

It seems like exactly the ORM solution/problem but even more abstract and less under control since it pushes the orm out to browser clients and the frontend devs.

ORM suffer from being at beyond arms length from the query analyzer in the database server.

https://en.wikipedia.org/wiki/Query_optimization

A query optimizer that's been tuned over decades by pretty serious people.

Bad queries, overfetching, sudden performance cliffs everywhere.

Graphql actually adds another query language on top of the normal orm problem. (Maybe the answer is that graphql is so simple by design that it has no dark corners but that seems like a matter of mathematical proof that I haven't seen alluded to).

Why is graphql not going to have exactly this problem as we see people actually start to work seriously with it?

Four or five implementations in javascript, haskell and now go. From what I could see none of them were mentioning query optimization as an aspiration.

replies(19): >>23485889 #>>23485918 #>>23485953 #>>23485962 #>>23486202 #>>23486714 #>>23486794 #>>23487403 #>>23487603 #>>23487611 #>>23487709 #>>23488354 #>>23488907 #>>23489619 #>>23489986 #>>23490334 #>>23491786 #>>23492176 #>>23497167 #
devit ◴[11 Jun 20 11:20 UTC] No.23487603[source]▶
The advantage of GraphQL is that the code for each API endpoint, which depends on frontend design (e.g. how many comments should be visible by default on a collapsed Facebook story), is now part of the frontend codebase (as a GraphQL query, that is then automatically extracted and moved to the backend), and thus frontend and backend development are no longer entangled.

Without it or a similar system frontend developers have to ask backend developers to create or modify an API endpoint every time the website is redesigned.

Also, it allows to combine data fetching for components and subcomponents automatically without having to do that manually in backend code, and automatically supports fine-grained caching of items.

replies(1): >>23487853 #
macca321 ◴[11 Jun 20 11:57 UTC] No.23487853[source]▶
Or the frontend devs could have just, like, learned how to write sql queries... :D

A major issue with pushing it to the frontend is that malicious clients can issue unexpected requests, putting strain on the database.

If the graphql query implementation doesn't allow that level of querying on the database, then it's not offering much more before you need to speak to the backend devs than a filterable rest endpoint.

This all came up years ago with OData.

replies(1): >>23488238 #
Nextgrid ◴[11 Jun 20 12:50 UTC] No.23488238[source]▶
My worry with GraphQL is that the server component is essentially a black box (as I don't have time to audit/review it) complex enough that there's more chance an edge case in a GraphQL query will end up exposing something you don't want.

A REST endpoint on the other hand is fairly simple and understood; there's (mostly) a static set SQL queries behind it and as long as those are not returning any unwanted data you are pretty much guaranteed to not expose something you didn't want to.

replies(1): >>23489888 #
1. virtue3 ◴[11 Jun 20 15:29 UTC] No.23489888[source]▶
the graphql server has a contract (the schema) that it will follow, or 500. So you know what you get back is exactly to spec. Or you get nothing.

REST endpoints are usually way more blackbox.

You can't claim that REST is better cuz you can look at the server... when you could do the same thing to the graphql server.

Graphql will -never- return you unwanted data. Because you wrote in the query exactly what you want.

If you want to examine an endpoint and JUST what it returns, you can do so really easily with graphiql.

https://developer.github.com/v4/explorer/

Just enter the api and you get an auto complete list of all the data fields you have access to. Or just use the schema explorer and click through. 100x easier than going through a sql query and analyzing a table.

replies(1): >>23490807 #
2. grok22 ◴[11 Jun 20 16:55 UTC] No.23490807[source]▶
>> Graphql will -never- return you unwanted data. Because you wrote in the query exactly what you want.

But couldn't you intentionally or unintentionally write a query such that it returns too much data and borks the system? Un-intentionally is the worrisome aspect.

replies(1): >>23492112 #
3. tomnipotent ◴[11 Jun 20 18:52 UTC] No.23492112[source]▶
There is nothing inherent in other systems that prevents this scenario, so why should GraphQL? This is a design decision orthogonal to whether it's REST, GraphQL, SOAP, or what have you.
replies(1): >>23514582 #
4. grok22 ◴[14 Jun 20 02:17 UTC] No.23514582{3}[source]▶
With REST, for example, you usually have a smaller set of well defined APIs whose surface area is pretty visible and it could be custom optimized up-front or even disallow certain kinds of queries. GraphQL seems to provide enormous flexibility for the front-end engineer to generate any kind of request that it might not be possible upfront to anticipate all the kinds of requests that will be made and optimize them?

While it might be orthogonal to the design decision, it might add to the amount of unanticipated work that will be required just because of the enormous flexibility.

replies(1): >>23531997 #
5. tomnipotent ◴[15 Jun 20 19:38 UTC] No.23531997{4}[source]▶
Nothing you said can't also be applied to GraphQL. It takes the same level of work to add pagination to a REST as it does to GraphQL, and you can add any arbitrary constraint you want as you see fit - nothing about GraphQL takes this away from you.