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

41–50 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#41

Post by WhatIsDukkha »

kevan wrote: post #35
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…

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…

Yeah as you say """(there's definitely non-GraphQL ways to achieve these too)."""

These are largely matter of architecture design and graphql doesn't really fix those problems (my sense is it will make those problems harder actually).

Re: How and why GraphQL will influence the Sourcehut alpha

#42

Post by kabes »

searchableguy wrote: post #33
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…

That is upto the graphql framework and the consumers of them. Graphql is just a query language. You need to have data loader (batching) on the backend to avoid n+1 queries and some other similar stuff with cache to improve the performance. You also have cache and batching on the frontend usually. Apollo client (most popular graphql client in js) uses a normalized caching strategy (overkill and a pain). For rate/abuse…

"You have to calculate the burden of the query before you execute it so you don't end up crashing your database."

This sounds like disaster waiting to happen.

Re: How and why GraphQL will influence the Sourcehut alpha

#43

Post by [deleted] »

philosopher1234 wrote: post #25
CameronNemo wrote: post #22

Earlier quoted context omitted.

On several occasions I have gotten panics (segfaults), many times without using CGo. This is not something I would expect from a "high level" language that has a garbage collector. The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be?…

>The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be? how would the library/codegen-tool author know all the permutations of business logic that might be out there?). Not sure what you mean here. Is there a particular codegen tool you…

[deleted]

Re: How and why GraphQL will influence the Sourcehut alpha

#44

Post by ianamartin »

xrisk wrote: post #24
ianamartin wrote: post #15

Earlier quoted context omitted.

There are lots of production sites that serve 10,000x as much traffic as sourcehut that are built on Python/flask/sqlalchemy serving RESTful APIs. If you can't make that combination work well, there's another place to look for problems besides your tool kit. You might need to ask yourself if you really understand the tools you're trying to use. But like I said, this has always been a very cool project. My "good luck"…

What are some production websites that run Python stacks? I’m curious. On a tangential note: if anybody has blog posts on scaling Flask/SQLAlchemy or Django stacks I would appreciate it.

Reddit is one you might have heard of.

pypi.org is another that's familiar. You know, every time you type `pip install x` yeah, that's pypi.

Although I think those are both powered mainly by Pyramid rather than flask. Still, same concept.

As others mention, large parts of google and youtube are still python. Dropbox was so invested in python that they employed Guido van Rossum for a while. Instagram, a lot of Yahoo! back when they were a thing, Spotify, Quora, Pinterest, Hipmunk, Disqus, and this really obscure satire site called The Onion that totally never gets any traffic at all.

All of them powered by python at their core, many of them Django, some Pyramid, and some Flask.

Yes, getting that big does require big teams. Becoming one of the top 100 or so sites on the internet always requires some special sauce as well as dedicated teams. But most of these companies started with Python and a framework and got to massive web scale along the way and never changed the core platform because there really wasn't a need. Handling scale isn't about your core language or framework. It's about dozens of other things that you can offload to other things if you're smart. But let's be real: sourcehut isn't close to any of that level of traffic.

My negativity on this isn't about stanning a particular language. I'm an agnostic in multiple ways. I'll use whatever tool seems like the best fit. I'm down on this because the explanation is tool-blaming, murky, unclear, and doesn't provide a lot of the detail I would want to have if I were depending on this service.

On the other hand, the guy has always said this is an alpha project and you should expect major changes. That's all fine. It's just weird to me to see a "why I'm changing from X to Y" post that doesn't really explain anything other than "I might be bad at this."

Re: How and why GraphQL will influence the Sourcehut alpha

#45

Post by kabes »

kevan wrote: post #35
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…

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.

Re: How and why GraphQL will influence the Sourcehut alpha

#46

Post by procinct »

searchableguy wrote: post #27
xrisk wrote: post #24

Earlier quoted context omitted.

What are some production websites that run Python stacks? I’m curious. On a tangential note: if anybody has blog posts on scaling Flask/SQLAlchemy or Django stacks I would appreciate it.

Dropbox is a notable one born here.

Especially considering they employed the BDFL.

Re: How and why GraphQL will influence the Sourcehut alpha

#47

Post by [deleted] »

kabes wrote: post #42
searchableguy wrote: post #33

Earlier quoted context omitted.

That is upto the graphql framework and the consumers of them. Graphql is just a query language. You need to have data loader (batching) on the backend to avoid n+1 queries and some other similar stuff with cache to improve the performance. You also have cache and batching on the frontend usually. Apollo client (most popular graphql client in js) uses a normalized caching strategy (overkill and a pain). For rate/abuse…

"You have to calculate the burden of the query before you execute it so you don't end up crashing your database." This sounds like disaster waiting to happen.

[deleted]

Re: How and why GraphQL will influence the Sourcehut alpha

#48

Post by ianamartin »

frou_dh wrote: post #37
RcouF1uZ4gsC wrote: post #16

> My work on SourceHut has, on the whole, really soured my opinion of Python as a serious language for large projects. A lot of the things thank make Python great for small projects, really bite you on a large or long-lived project. For me, the two biggest are lack of types and indentation for scoping. It is really easy to mess up white space during an edit or refactor. In many languages you would just reformat. In p…

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.

Re: How and why GraphQL will influence the Sourcehut alpha

#49

Post by tannhaeuser »

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 and rooted in a mindset I'd call based more on cultural beliefs rather than engineering. That said, a recent discussion [1] convinced me there are practical benefits in using GraphQL if you're working with "modern" SPA frameworks, and your backend team can't always deliver the ever-changing interfaces you need so you're using a backend-for-fronted (an extra fronted-facing backend that wraps your actual backend) approach anyway, though it could be argued that organizational issues play a larger role here.

[1]: https://news.ycombinator.com/item?id=23119810

Re: How and why GraphQL will influence the Sourcehut alpha

#50

Post by searchableguy »

tptacek wrote: post #32
CameronNemo wrote: post #22

Earlier quoted context omitted.

On several occasions I have gotten panics (segfaults), many times without using CGo. This is not something I would expect from a "high level" language that has a garbage collector. The constant use of generated code is another real pain point, particularly when I am writing business logic that needs to operate on generated types for which there is no interface available that does what I need (and why would there be?…

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...
Post reply on HN