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

51–60 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#51

Post by searchableguy »

ianamartin wrote: post #48
frou_dh wrote: post #37

Earlier quoted context omitted.

Python has a better static typesystem than Go does: https://mypy.readthedocs.io/en/stable/kinds_of_types.html#un... https://mypy.readthedocs.io/en/stable/kinds_of_types.html#op... https://mypy.readthedocs.io/en/stable/generics.html https://mypy.readthedocs.io/en/stable/protocols.html

Even though I like Python a lot, I clicked on a reply to this comment because I was absolutely certain I was going to have to disagree with you. That just didn't seem possible. But . . . I was wrong. That third link with generics makes me cry when I think about the go code I've written.

Are those tears result of overflowing with joy or sadness?

Re: How and why GraphQL will influence the Sourcehut alpha

#52

Post by ianamartin »

searchableguy wrote: post #51
ianamartin wrote: post #48

Earlier quoted context omitted.

Even though I like Python a lot, I clicked on a reply to this comment because I was absolutely certain I was going to have to disagree with you. That just didn't seem possible. But . . . I was wrong. That third link with generics makes me cry when I think about the go code I've written.

Are those tears result of overflowing with joy or sadness?

Can it be both?

Re: How and why GraphQL will influence the Sourcehut alpha

#53

Post by jamil7 »

tannhaeuser wrote: post #49

Tbh I'd expected a little better than framing this question in a "REST vs GraphQL" discussion coming from sourcehut.org. If you control your backend, you can aggregate whatever payloads you please into a single HTTP response, and don't have to subscribe to a (naive) "RESTful" way where you have network roundtrips for every single "resource", a practice criticized by Roy Fielding (who coined the term "REST") himself a…

I like GraphQL but if you're just serving a single SPA I wonder about all this busy work we still have to do. Why haven't we gone a step further and just abstracted all the networking and serialisation steps away and our models are synced for us in the background. Maybe the apollo team is heading in this direction but their offline story isn't great yet.

Edit: I remember now that the Apollo team is made up of members of the former Meteor team which worked in a similar way using a client side database.

Re: How and why GraphQL will influence the Sourcehut alpha

#54

Post by searchableguy »

jamil7 wrote: post #53
tannhaeuser wrote: post #49

Tbh I'd expected a little better than framing this question in a "REST vs GraphQL" discussion coming from sourcehut.org. If you control your backend, you can aggregate whatever payloads you please into a single HTTP response, and don't have to subscribe to a (naive) "RESTful" way where you have network roundtrips for every single "resource", a practice criticized by Roy Fielding (who coined the term "REST") himself a…

I like GraphQL but if you're just serving a single SPA I wonder about all this busy work we still have to do. Why haven't we gone a step further and just abstracted all the networking and serialisation steps away and our models are synced for us in the background. Maybe the apollo team is heading in this direction but their offline story isn't great yet. Edit: I remember now that the Apollo team is made up of members…

You can use rxdb for replication and offline support.

Re: How and why GraphQL will influence the Sourcehut alpha

#55

Post by jamil7 »

searchableguy wrote: post #54
jamil7 wrote: post #53

Earlier quoted context omitted.

I like GraphQL but if you're just serving a single SPA I wonder about all this busy work we still have to do. Why haven't we gone a step further and just abstracted all the networking and serialisation steps away and our models are synced for us in the background. Maybe the apollo team is heading in this direction but their offline story isn't great yet. Edit: I remember now that the Apollo team is made up of members…

You can use rxdb for replication and offline support.

Yeah good point, WatermelonDB, rxdb and pouchdb all fit this model. This to me feels like the future for web and mobile.

Re: How and why GraphQL will influence the Sourcehut alpha

#56

Post by dmitriid »

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 are. And how you have to re-do so many things from scratch, inefficiently, because you really have no control of the queries coming into the system.

My takeaway from GraphQL so far has been:

- good for frontend

- usable only for internal projects where you have full control of who has access to your system, and can't bring it down because you forgot an authorisation on a field somewhere or a protection against unlimited nested queries.

Re: How and why GraphQL will influence the Sourcehut alpha

#57

Post by zapf »

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 new endpoint for you.

If you let frontend developers dictate backend queries, all you will get is a big master cluster fuck. I am talking average joe developers that we usually find to work on startups.

Re: How and why GraphQL will influence the Sourcehut alpha

#58

Post by searchableguy »

jamil7 wrote: post #55
searchableguy wrote: post #54

Earlier quoted context omitted.

You can use rxdb for replication and offline support.

Yeah good point, WatermelonDB, rxdb and pouchdb all fit this model. This to me feels like the future for web and mobile.

Hopefully not. In an ideal world, this would be the responsibility of the browser given the widespread web apps.

Re: How and why GraphQL will influence the Sourcehut alpha

#59

Post by zapf »

tannhaeuser wrote: post #49

Tbh I'd expected a little better than framing this question in a "REST vs GraphQL" discussion coming from sourcehut.org. If you control your backend, you can aggregate whatever payloads you please into a single HTTP response, and don't have to subscribe to a (naive) "RESTful" way where you have network roundtrips for every single "resource", a practice criticized by Roy Fielding (who coined the term "REST") himself a…

If you don't like REST, don't use it.

Whatever you do, don't even think that GraphQL will solve your problems. You were on the right track staying away from it till now.

I can't also advise enough to stay away from a typed language (Go in this case) serving data in a different typed language (gql). You will eventually be pulling your hair out jumping through hoops matching types.

After my last web project that require gql and go, I did some digging around, thinking, there has to be a better alternative to this. I have worked with jQuery, React, GraphQL.

My conclusion was that next time I will stick to turbolinks (https://github.com/turbolinks/turbolinks) and try stimulus (https://stimulusjs.org/).

Re: How and why GraphQL will influence the Sourcehut alpha

#60

Post by zapf »

ianamartin wrote: post #26
CameronNemo wrote: post #8

Earlier quoted context omitted.

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…

That quote is sort of exactly what's conceptually wrong with what's goin on in my opinion. Yes, I know, armchair quarterback and I'm not the one out there building stuff like this for free, etc., etc. But claiming some nebulous backend that's more performant and robust than Postgres is like, WTF? Are you using an actual GraphDB like Neo4J? Are you putting a graph frontend on Postgres like PostGraphQL? None of the pos…

Well said! Couldn't agree more.

The GraphQL confusion is one more bullshit in the world of web dev.

Post reply on HN