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

131–140 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#131

Post by AsyncAwait »

cnorthwood wrote: post #129
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 see GraphQL as an ORM type solution, I see it more like a replacement for REST.

What would be the advantage of GraphQL over gRPC in a REST replacement scenario?

Re: How and why GraphQL will influence the Sourcehut alpha

#132

Post by karatestomp »

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…

> Are you using an actual GraphDB like Neo4J? Are you putting a graph frontend on Postgres like PostGraphQL? None of the post really makes any sense because GraphQL is a Query Language, not a data store. What are the CAP theorem tradeoffs in the new backend? What does more robust mean? What does more performant mean? This is a source control app. Those tradeoffs are meaningful.

GraphQL isn't particularly "graphy". Its name sucks. But don't worry, plenty of half-techy middle managers are out there making the same mistake and going "we do graph things, why don't you guys look into this GraphQL thing that's getting so much buzz?" It's not a great fit for graph operations, in fact. Not more than SQL, certainly.

As for N4J in particular, don't count on that to improve performance even if you're doing lots of graph stuff. Depends heavily on your usage patterns and it's very easy to modify a query in a way that seems like it'd be fine but in fact makes performance fall off a cliff. OTOH Cypher, unlike GraphQL, is a very nice language for querying graphs.

Re: How and why GraphQL will influence the Sourcehut alpha

#133

Post by StavrosK »

fastball wrote: post #130
StavrosK wrote: post #124

Earlier quoted context omitted.

Oh, I can imagine, ASGI must be immeasurably easier. Where do the async speedup gains come from, though, if your database is still sync? Wouldn't threadpools provide comparable performance before?

Well so actually we have both now. For WebSockets, all of the code is async, so I'm already using `asyncpg` for any database stuff that is happening there. With regards to why are the sync endpoints faster, I think it is a number of things, some of which are userland changes that could've been made under Flask, but all of which are somewhat related to the switch. With regards to things that FastAPI itself has changed…

That makes perfect sense, thank you. I love FastAPI just for the code clarity and ease of working with better type objects (the Pydantic classes) alone, though the speed benefit is nice to have too.

Re: How and why GraphQL will influence the Sourcehut alpha

#134

Post by O5vYtytb »

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…

You can use the async databases[0] library, and there's a guide[1] for it. It's not a full ORM but works pretty well :)

[0] https://www.encode.io/databases/

[1] https://fastapi.tiangolo.com/advanced/async-sql-databases/

Re: How and why GraphQL will influence the Sourcehut alpha

#136

Post by pknopf »

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.

> And I guarantee that a graphql isn't the solution.

I agree. Out of the pan and into the frier.

He had a good idea though.

Re: How and why GraphQL will influence the Sourcehut alpha

#137

Post by pknopf »

vertex-four wrote: post #97
ianamartin wrote: post #26

Earlier quoted context omitted.

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…

The goal here is to generate a typed API across a bunch of microservices (written in some typed language suited for the job) that are consumed by a Python frontend. The current design is a pile of vertically-integrated monoliths that touch the disk, database, perform backend operations and rendering all in one process. Python's single-threaded design makes it difficult to be responsive to small queries quickly while…

> The goal here is to generate a typed API across a bunch of microservices

You are describing gRPC.

Re: How and why GraphQL will influence the Sourcehut alpha

#138

Post by striking »

kasbah wrote: post #78
jorams wrote: post #66

In my experience GraphQL can be much nicer to implement than REST, and it offers a good structure around things that many REST APIs implement in particular ways (like selecting which fields you want). The pain you'll experience depends heavily on your data model and the abuse potential that brings. I think the biggest problem with GraphQL is the JavaScript ecosystem around it, and all of its implicit context. It seem…

I don't think Relay is used that much outside of Facebook. The community seems to have settled on Apollo. Personally I find Apollo over-engineered. When I couldn't delete things from the cache, because of a bug, and was faced with digging into the complex code-base, I ended up just using straight JSON with a HTTP client/fetch and caching in a simple JS object. Other users of my API [1] just use straight HTTP with JSO…

Relay has quite a few users, a partial list of which you can find at https://relay.dev/en/users. I personally prefer it myself.

Re: How and why GraphQL will influence the Sourcehut alpha

#139

Post by karatestomp »

StavrosK wrote: post #83
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.

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.

Do most libraries use static types? Or have something widely-used and well-supported available like the @types project for TypeScript to provide them, fairly seamlessly, to consumers of those libraries?

Re: How and why GraphQL will influence the Sourcehut alpha

#140

Post by StavrosK »

karatestomp wrote: post #139
StavrosK wrote: post #83

Earlier quoted context omitted.

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.

Do most libraries use static types? Or have something widely-used and well-supported available like the @types project for TypeScript to provide them, fairly seamlessly, to consumers of those libraries?

Some projects do, yes. Django, for example, has a library to provide types. In my experience, types are useful even just in my own application, since the libraries I use tend to generally only accept simple/fundamental types anyway. Things could definitely be better when it comes to library type support, though, I agree.
Post reply on HN