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

81–90 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#81

Post by ramraj07 »

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…

I maintain a fairly complex flask application and cannot see a better tool for that job. Our code looks similar as well. It's boilerplate repeated often for sure, but there will always be that one endpoint where you need that flexibility to do something a highly opinionated framework just won't let you. In the end it's deciding whether you write some extra code with flexibility or some extra code fighting the framework.

Can you show me a comparable codebase in django and how it looks? I'm genuinely curious how people deal with edge cases.

Re: How and why GraphQL will influence the Sourcehut alpha

#82

Post by StavrosK »

CameronNemo wrote: post #13
xvilka wrote: post #4

Does this mean that SourceHut will become completely written in Go? Amazing news if so!

Why? I am currently converting a Flask/SQLAlchemy application to Go and gRPC. Go has not been that much of a win from my perspective. Lots of rough edges and missing functionality in libraries available, a lackluster type system that does enough to get in the way but not enough to properly express programmatic intention, and an atypical non-ideal error handling model have left me with little reason to champion Go. No…

I have had a very pleasant experience using types in a FastAPI project (detailed here): https://www.stavros.io/posts/fastapi-with-django/

I quite like Python's type system, it's not very mature yet but it's definitely good enough to already catch a lot of bugs.

Re: How and why GraphQL will influence the Sourcehut alpha

#83

Post by StavrosK »

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.

I'm really liking Python static types to the point where I don't write new programs without them. Give them a shot, they really help.

Re: How and why GraphQL will influence the Sourcehut alpha

#84

Post by ramzeus »

square_usual wrote: post #75
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…

> People who talk about auto-generating GraphQL wrappers for Postgres database schemas (not the author of this post, to be clear, but it's common enough) are missing the point entirely. The whole point of GraphQL is to span heterogeneous and independent data sources; I don't think they are missing a point; rather, they have a completely different point: eschew a backend and use GraphQL on a DB + a frontend that gets…

I think the problem with this approach becomes apparent when the database model changes, suddenly the API doesn't match the model anymore or the API needs to change. Both can be difficult problems leading to braking changes in the client(s). Of course, for some rapid testing and simple personal projects this doesn't matter so much but for most other projects I think this might bite you hard in the future.

Re: How and why GraphQL will influence the Sourcehut alpha

#85

Post by odensc »

square_usual wrote: post #74
zapf wrote: post #59

Earlier quoted context omitted.

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

> stimulus ( https://stimulusjs.org/ ). And here I thought Basecamp was still 100% rails. Interesting to see that they're also developing backend JS frameworks.

Stimulus is a frontend framework.

Re: How and why GraphQL will influence the Sourcehut alpha

#86

Post by dgellow »

rhlsthrm wrote: post #79
dmitriid wrote: post #56

Earlier quoted context omitted.

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

As a full-stack dev, I'm going to always reach for things like Hasura for building my backend from now on. It auto generates a full CRUD GraphQL API from my Postgres DB schema. Most of the backend boilerplate is eliminated this way. If I need to add additional business logic, I can use serverless functions that run between the GraphQL query from the front end and the DB operations (actions in Hasura). Most of the hea…

What about authentication, authorization?

Also, how do you handle transactional logic?

Re: How and why GraphQL will influence the Sourcehut alpha

#87

Post by osrec »

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 couldn't agree more. While GraphQL does allow you to be explicit about what you want from your backend, I've yet to see an implementation/solution that gives you back your data efficiently. If anything, the boilerplate actually seems to introduce inefficiency, with some especially inefficient joins.

And when you are explicit about how you want to implement joins etc, you pretty much have to hand code the join anyway, so I don't see the point.

In almost all use cases that I've come across, a standard HTTP endpoint with properly selected parameters works just as well as a GraphQL endpoint, without the overhead of parsing/dealing with GraphQL.

Re: How and why GraphQL will influence the Sourcehut alpha

#88

Post by rhlsthrm »

dgellow wrote: post #86
rhlsthrm wrote: post #79

Earlier quoted context omitted.

As a full-stack dev, I'm going to always reach for things like Hasura for building my backend from now on. It auto generates a full CRUD GraphQL API from my Postgres DB schema. Most of the backend boilerplate is eliminated this way. If I need to add additional business logic, I can use serverless functions that run between the GraphQL query from the front end and the DB operations (actions in Hasura). Most of the hea…

What about authentication, authorization? Also, how do you handle transactional logic?

They have great recipes for authentication/authorization. It's much better IMO because it actually provides per-request authorization. There is also great support for transactions using the GraphQL mutations. I'm not affiliated with Hasura in any way, it's just changed the way I view backend development. Backends (in most cases, my day job is actually not part of this generalization) should basically be a thin wrapper around your database, and any work you can outsource to the database, you should do that rather than building business logic.

Re: How and why GraphQL will influence the Sourcehut alpha

#89

Post by dgellow »

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 author isn’t the one who shared the link on HN.

Re: How and why GraphQL will influence the Sourcehut alpha

#90

Post by tome »

Kuinox wrote: post #69
erk__ wrote: post #17

Earlier quoted context omitted.

As for the reason to use Go instead of Rust it is probably just down to the creator of Sourcehut he has multiple times expressed that he dislikes rust quite a bit. He has written a blog post about how he chooses programming languages as well https://drewdevault.com/2019/09/08/Enough-to-decide.html

It's the first time I hear that haskell has awful package management...

It used to a few years ago, before Cabal v2-style. Nowadays package management is rather good, but its reputation hasn't caught up yet.
Post reply on HN