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

101–110 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#101

Post by runawaybottle »

zapf wrote: post #57

I like my front end team to not write queries. I have seen too many front end developers write queries equivalent to "select * from users, t1, t2, ... tn, left outer join on users.id = t1.user_id... etc etc etc". I think that is just bullshit. I prefer to tell the frontend people - these are the endpoints that backend team provides, go live with it. If you really have issues, talk to them, and they might just add a n…

I think Frontend has the right to take over certain domains of the backend. A very clear example of this is templating. Templating used to be a backend task, but it became very clear it was the frontend developers that needed power over this domain. Going over to a backend dev to make adjustments to the templates is an inefficiency that had to be solved, period.

I agree with you that writing optimal queries or data modeling should not be shifted over to the frontend. With that said, there are basic aspects of this equation that can be factored out. There should be a layer where frontend can at the very least pick or mix the data they need. That doesn’t necessarily mean Graphql, but could also mean a simple middle stack layer where one can do this basic thing without being able to shoot themselves in the foot.

There’s a responsible way to do this, and most likely will be an ongoing discussion.

Re: How and why GraphQL will influence the Sourcehut alpha

#102

Post by gbear605 »

say_it_as_it_is wrote: post #73

Where are the GraphQL lessons learned? The author hasn't even implemented a solution with it yet, but that hasn't stopped him from declaring it to the world. I don't find an announcement useful. Maybe GraphQL adopters aren't sharing their experiences with it in production because they're realizing its faults? People are quick to announce successes and very reluctant to own, let alone share, costly mistakes. Also, peo…

The reason this post was written was for users of Sourcehut, especially for people writing to its API. This post isn’t particularly relevant or explanatory for other audiences, but I don’t think it’s supposed to be so that’s fine.

Re: How and why GraphQL will influence the Sourcehut alpha

#103

Post by GordonS »

square_usual wrote: post #70
kabes wrote: post #45

Earlier quoted context omitted.

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

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.

Re: How and why GraphQL will influence the Sourcehut alpha

#104

Post by macca321 »

devit wrote: post #92
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…

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.

This all came up years ago with OData.

Re: How and why GraphQL will influence the Sourcehut alpha

#105

Post by GordonS »

dmitriid wrote: post #56
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 understand the attraction to Graphql. It's attractive primarily to frontend developers. Instead of juggling various APIs (oftne poorly designed or underdesigned due to conflicting requirements and time constraints) you have a single entry into the system with almost any view of the data you want. Almost no one ever talks about what a nightmare it becomes on the server-side, and how inane the implementations…

> - good for frontend

I'm not even sure about this part.

I worked on a project recently where the mobile front end team hated working with GraphQL. They were far more used to working with REST/HTTP APIs, and in this particular project they only communicated with a single backend.

The team saw it as extra layers of complexity for no benefit.

The GraphQL backend was responsible for pulling together data from several upstream systems and providing it to clients. But the architect never was able to convince me of a single benefit here compared to REST.

Re: How and why GraphQL will influence the Sourcehut alpha

#107

Post by ddevault »

ianamartin wrote: post #5

Well, that's too bad. I always thought this was a cool project. But if you can't dev your way into decent performance for a small alpha project using python/flask/sql, I don't think your tools are the problem. And I guarantee that a graphql isn't the solution. So, I mean, good luck.

Performance is a secondary concern. SourceHut already has the best performance in the industry, built on Python:

https://forgeperf.org

But I think it could be even better, and this work will help. It will make it easier to write performant code without explicitly hand-optimizing everything.

There are more important reasons to consider GraphQL than performance, which I cover in detail in TFA.

Re: How and why GraphQL will influence the Sourcehut alpha

#108

Post by ddevault »

CameronNemo wrote: post #8
ianamartin wrote: post #5

Well, that's too bad. I always thought this was a cool project. But if you can't dev your way into decent performance for a small alpha project using python/flask/sql, I don't think your tools are the problem. And I guarantee that a graphql isn't the solution. So, I mean, good luck.

This quote stuck out to me: >Today, the Python backends to the web services communicate directly with PostgreSQL via SQLAlchemy, but it is my intention to build out experimental replacement backends which are routed through GraphQL instead. This way, the much more performant and robust GraphQL backends become the single source of truth for all information in SourceHut. I wonder how adding a layer of indirection can s…

It will be performing this indirection over localhost. I don't see it as much different from the indirection of SQLAlchemy. Yes, there is the question of parsing the GQL and so on, but I think that they're surmountable and fit well within our desired performance budget.

Performance is also just one of many reasons why this approach is being considered.

Re: How and why GraphQL will influence the Sourcehut alpha

#109

Post by ddevault »

Author here. Wow, there is a ton of "didn't RTFA" comments here. It seems like half of this thread saw GraphQL in the title, it knocked two gears into place in their head, and they started writing up their own little essay about how bad it is.

I evaluated GraphQL twice before, and discarded it for many of the reasons brought up here. Even this time around, I give a rather lackluster review of it and mention that there are still many caveats. It's not magic, and I'm not entirely in love with it - but it's better than REST.

Query optimization, scalability, authentication, and many other issues raised here were part of the research effort and I would not have moved forward with it if I did not feel that they were adequately addressed.

Before assuming some limitation you have had with it in the past applies to sr.ht, I would recommend reading through the code:

https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/api

https://git.sr.ht/~sircmpwn/gql.sr.ht

If you're curious for a more detailed run-down of my problems with REST, Python, Flask, and SQLAlchemy, I answered similar comments last night on the Lobsters thread:

https://lobste.rs/s/me5emr/how_why_graphql_will_influence_so...

I would also like to point out that the last time I thought a rewrite was in order, we got wlroots, which is now the most successful project in its class.

Cheers.

Re: How and why GraphQL will influence the Sourcehut alpha

#110

Post by fastball »

StavrosK wrote: post #80
orf wrote: post #77

The author says that he has soured on Python for “serious, large projects”. While it’s clearly personal opinion, and that’s fair enough , I can’t help but think his choice of framework hasn’t helped him and has likely caused significant slowdown when delivering features. Looking through some of the code for Sourcehut, there’s an insane amount of boilerplate or otherwise redundant code[1]. The shared code library is a…

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 via `asyncpg`, as SQLAlchemy ORM is not async and that causes a bunch of extra switching in the backend that certainly doesn't help eek out more perf, but at the moment it's a bit too much effort and users are happy.

Scaling is handled by just throwing more instances of the application at the problem, behind a load-balancer.

[0] https://supernotes.app

Post reply on HN