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

111–120 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#111

Post by StavrosK »

fastball wrote: post #110
StavrosK wrote: post #80

Earlier quoted context omitted.

Exactly agreed. I basically only use Flask for things I want to explicitly be single-file these days. For anything larger, I reach for Django, because I know that if I need at least one thing from it (and I always need the ORM/migrations/admin), it will have been worth it. My current favorite way of building APIs is this Frankenstein's monster of Django/FastAPI, which actually works quite well so far: https://www.sta…

I built the backend for my knowledge-base platform[0] using Flask originally, but performance was definitely a struggle so I rewrote the whole thing with FastAPI. Have definitely seen a serious performance bump from that switch, and currently am quite happy with it. Many of our users are actually impressed with how fast everything is on the platform. I still want to rip out SQLAlchemy ORM and replace it with pure SQL…

That sounds like a good solution, and is a good data point to know, thank you. Did you try Sync FastAPI? I'm wondering how its performance compares with async

Re: How and why GraphQL will influence the Sourcehut alpha

#112

Post by AmericanChopper »

GraphQL as a query language is simply better than REST in most cases imo. REST has too much client side state, which not only has the potential to make things harder for clients to consume, but also has all the inconsistent states to handle where your consumer gets part way through a multiple-REST method workflow, and then bails. REST also absolutely sucks for mutating arrays.

Really I just look at GraphQL as a nice RPC framework. The graph theory operations like field level resolvers are mostly useless. But if you treat each relationship as a node rather than each field, you can get it to work very nicely with a normalized data set. I haven’t found it hard to preserve join efficiency in the backend either, and it so far hasn’t forced me into redundant query operations.

Just as long as you don’t use appsync. Really, don’t even bother.

Re: How and why GraphQL will influence the Sourcehut alpha

#113

Post by lukevp »

GordonS wrote: post #103
square_usual wrote: post #70

Earlier quoted context omitted.

As GP said: > 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 It may not exactly "shine" in those cases, but it reduces round trips and makes it easy for fronted engineers to make views that revolve around use cases instead of the resources in the database.

> it reduces round trips Is that really a big deal with HTTP2 and pipelining? I can also imagine situations where it results in a better UX to make multiple small calls, rather than one big one, as you'll have something to render faster.

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 to fetch the book detail and the joined author name with one round trip.

Re: How and why GraphQL will influence the Sourcehut alpha

#114

Post by Nextgrid »

GordonS wrote: post #103
square_usual wrote: post #70

Earlier quoted context omitted.

As GP said: > 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 It may not exactly "shine" in those cases, but it reduces round trips and makes it easy for fronted engineers to make views that revolve around use cases instead of the resources in the database.

> it reduces round trips Is that really a big deal with HTTP2 and pipelining? I can also imagine situations where it results in a better UX to make multiple small calls, rather than one big one, as you'll have something to render faster.

I always find it sad when developers waste time on developing over-engineered methods to reduce the amount of API calls while having 10 advertising/analytics SDKs in the background sending countless amounts of requests (which can still saturate the data link and make the main API requests stall even if it's a single one).

Re: How and why GraphQL will influence the Sourcehut alpha

#115

Post by Nextgrid »

macca321 wrote: post #104
devit wrote: post #92

Earlier quoted context omitted.

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

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 are pretty much guaranteed to not expose something you didn't want to.

Re: How and why GraphQL will influence the Sourcehut alpha

#117

Post by GordonS »

lukevp wrote: post #113
GordonS wrote: post #103

Earlier quoted context omitted.

> it reduces round trips Is that really a big deal with HTTP2 and pipelining? I can also imagine situations where it results in a better UX to make multiple small calls, rather than one big one, as you'll have something to render faster.

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 could have an endpoint that returns the exact same data.

I can see how GraphQL might be somewhat nice for front end developers when the data to be displayed hasn't been nailed down yet - maybe we decide to show the book's ISBN number, and we can do that without changing the backend. Maybe this justifies the extra complexity for some teams, but I'd personally much prefer the simplicity of a REST API, to which you can always add OData on top if you really want.

Re: How and why GraphQL will influence the Sourcehut alpha

#118

Post by DrFell »

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…

GraphQL is instant API to frontenders.

Their justification for needing it is that the API team takes too long to implement changes, and endpoints never give them the data shape they need.

The silent reason is that server-side code, databases, and security are a big scary unknown they are too lazy to learn.

A big project cannot afford to ask for high standards from frontenders. You need a hoard of cheap labor to crank out semi-disposable UIs.

Re: How and why GraphQL will influence the Sourcehut alpha

#119

Post by crabmusket »

> Another (potential) advantage of GraphQL is the ability to compose many different APIs into a single, federated GraphQL schema.

If anyone else can share experiences of this sort of problems and solution, I'd be really interested to hear it. I've written non-GQL APIs before that back onto other internal and external services; what am I missing?

Re: How and why GraphQL will influence the Sourcehut alpha

#120

Post by maddyboo »

crabmusket wrote: post #119

> Another (potential) advantage of GraphQL is the ability to compose many different APIs into a single, federated GraphQL schema. If anyone else can share experiences of this sort of problems and solution, I'd be really interested to hear it. I've written non-GQL APIs before that back onto other internal and external services; what am I missing?

I think Drew is referring to composition in terms of API end-user code, not sr.ht code, e.g. making it possible for the user write a single GQL query that combines data from multiple sr.ht services.
Post reply on HN