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

How and why GraphQL will influence the Sourcehut alpha

sourcehut.org

Post reply on HN
Print view View original

141–150 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#141

Post by goto11 »

WhatIsDukkha wrote: post #31

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/w…

I don't see the conflict? If the GraphQL query is translated into SQL on the server, then then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally.

Re: How and why GraphQL will influence the Sourcehut alpha

#142

Post by vertex-four »

pknopf wrote: post #137
vertex-four wrote: post #97

Earlier quoted context omitted.

The goal here is to generate a typed API across a bunch of microservices (written in some typed language suited for the job) that are consumed by a Python frontend. The current design is a pile of vertically-integrated monoliths that touch the disk, database, perform backend operations and rendering all in one process. Python's single-threaded design makes it difficult to be responsive to small queries quickly while…

> The goal here is to generate a typed API across a bunch of microservices You are describing gRPC.

I'm describing a lot of things, JSON-Schema documented REST APIs being another one. The other thing about GraphQL is that you can make a query that contains multiple requests and allows the server to optimise how to process them, which is not something that REST or gRPC are very good at.

Re: How and why GraphQL will influence the Sourcehut alpha

#143

Post by z3t4 »

alexchamberlain wrote: post #28
z3t4 wrote: post #3

Im a Sourcehut user and all I care about is that I can host my public Mercurial repositories, and that web frontend is somewhat usable (it currently is). I dont care what languages is ised to build it nor do i care about apis and other features. If i where to chose I would like an api that i could use with curl, eg. Dont complicate things.

I think this is simply a technical blog post - it could be about any site. It's simply an insight to the way another engineer is thinking, so you can challenge your own.

It was not a comment about the blog post! It was just my thought as a user of the product. He should probably spend his time marketing as he already got a working product, rather then rewriting stuff.

Re: How and why GraphQL will influence the Sourcehut alpha

#144

Post by ryanong »

cletus wrote: post #65

So I've now had the opportunity to use both GraphQL and protocol buffers ("protobufs" is the more typical term) professionally and I have some thoughts on this. 1. Protobufs use integer IDs for fields. GraphQL uses string names. IMHO this is a clear win for protobufs. Changing the name of a field of GraphQL is essentially impossible. Once a name is there it's there forever (eg mobile client versions are out there for…

addressing #7, graphql queries are dynamic and not stored on the server

Re: How and why GraphQL will influence the Sourcehut alpha

#145

Post by mixedCase »

goto11 wrote: post #141
WhatIsDukkha wrote: post #31

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/w…

I don't see the conflict? If the GraphQL query is translated into SQL on the server, then then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally.

> then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally

...and other lies we tell ourselves to sleep soundly at night.

But just like ORMs, they do work for the simple cases which tend to abound and you can hand-optimize the rest.

Re: How and why GraphQL will influence the Sourcehut alpha

#146

Post by virtue3 »

GordonS wrote: post #117
lukevp wrote: post #113

Earlier quoted context omitted.

If you are round tripping because of data, you’re having to traverse the network to the origin and likely composing your queries with dependent data, so http2 is little benefit. For example, if you are loading a book detail page, and want to also show the author name, but you need to retrieve the detail record to get the author ID first so you can call the author detail endpoint. Graphql solves for this by being able…

Sure, I didn't mean multiple requests would always be a net benefit, only that I often come across cases where there is a need to load independent data simultaneously, in which case multiple requests can sometimes provide a better UX. > Graphql solves for this by being able to fetch the book detail and the joined author name with one round trip I don't see why we need GraphQL to solve this though - a REST backend cou…

The real benefit of this, is that you can have all this data available, and now the mobile team and the web team can share a query, maybe the webteam wants everything, ithe ISBN the Author, etc. The mobile team only wants the author and title (and will show the rest when you click in, doing the same query or slightly different but with all the fields).

It's the power of the frontend teams to create a rest endpoint out of a schema.

When you combine it with typescript/JVM/Swift, you get AUTO typing for the graphql queries, you know exactly the data model you get back based on your query. It's quite lovely.

The other aspect is that on the apollo/graphql server you can utilize dataloader and streamline a nested request into as few calls to each service as possible.

And the last benefit over a rest service. If you had to make multiple calls, you're doing round trips from the CLIENT to the backend services. The graphql server is _already_ in your backend service network, so all the data combining is on the orders of GraphQL has a major advantage over rest in that you can't just change the schema without the clients breaking, so you know that your API isn't going to magically just screw you. (Most places use versioning for this, but not always). You can get some of this with RPCs but it's not as robust as the graphql schema.

Re: How and why GraphQL will influence the Sourcehut alpha

#147

Post by tptacek »

searchableguy wrote: post #50
tptacek wrote: post #32

Earlier quoted context omitted.

Null pointer exceptions in Go are, technically, SEGVs. But they're just NPEs. Do you have something more interesting than that?

Have you read this - https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

Yes.

Re: How and why GraphQL will influence the Sourcehut alpha

#148

Post by virtue3 »

Nextgrid wrote: post #115
macca321 wrote: post #104

Earlier quoted context omitted.

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

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

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.

Re: How and why GraphQL will influence the Sourcehut alpha

#149

Post by chrisfosterelli »

kabes wrote: post #45
kevan wrote: post #35

Earlier quoted context omitted.

Seems like you're looking at this through the lens of a single system that could submit a query to a single database and get all the data it needs. From that perspective GraphQL is definitely an extra layer that probably doesn't make sense. But even then there's still some value in letting the client specify the shape of the the data it needs and having client SDKs (there's definitely non-GraphQL ways to achieve thes…

That's indeed one of its selling points. But most products I see that adopt graphql are exactly 1 database.

I think lots of people here are fixed on GraphQL from a backend perspective and are missing that GraphQL has a fantastic front end development experience using libraries like Apollo.

I honestly think the backend benefits are relatively marginal, but on the client being able to 1) mock your entire backend before it even exists, 2) have built in automatic caching on every query and entity for free, 3) use a fully declarative, easily testable and mockable React hook API built with out-of-the-box exposed support for loading and error states, is so valuable. Components written against Apollo feel so clean and simple. That's not to say anything about the benefits you get from being able to introspect the entire backend API or test queries against it with Apollo's extensions or how you can easily retain the entire entity cache across reloads with simple plugins to Apollo.

Can you do all that with REST? Sure. But writing queries against REST APIs is a pain in the butt compared to what you get for free by using Apollo.

Re: How and why GraphQL will influence the Sourcehut alpha

#150

Post by umvi »

WhatIsDukkha wrote: post #31

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/w…

Super useful for bandwidth sensitive situations where you need to piece together a small amount of data from several APIs that normally return a large amount of data.
Post reply on HN