Live data from Hacker News

How and why GraphQL will influence the Sourcehut alpha

sourcehut.org

1–10 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#3
Im a Sourcehut user and all I care about is that I can host my public Mercurial repositories, and that web frontend is somewhat usable (it currently is). I dont care what languages is ised to build it nor do i care about apis and other features. If i where to chose I would like an api that i could use with curl, eg. Dont complicate things.

Re: How and why GraphQL will influence the Sourcehut alpha

#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.

Re: How and why GraphQL will influence the Sourcehut alpha

#6

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.

what do you feel the problem is?

Re: How and why GraphQL will influence the Sourcehut alpha

#7

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.

I didn't read the post that way. I feel scaling is a small issue more so organization. Graphql does make sense for something like source hunt.

Why not use type hints in python? Isn't that a good enough substitute?

I wonder why go instead of rust if he wanted static typing, long term ease of maintanence and performance. Go's type system is not great especially for something like graphql. Gqlgen relies heavily on code generation. Last time I used it, I ran into so many issues. I ditched go together after several painful clashes with it that community always responded with: oh you don't need this.

(yeah except they implemented all those parts in arguably worse ways and ditched community solutions in the next few years)

One major benefit the GP fails to mention is that with graphql, it is easy to generate types for frontend. This makes your frontend far more sane. It's also way easier to test graphql since there are tools to automatically generate queries for performance testing unlike rest.

There is no need to add something for docs or interactivity like swagger.

Re: How and why GraphQL will influence the Sourcehut alpha

#8

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 significantly improve performance. If I were writing this service, I would go all in on GraphQL and have the frontend talk to the GraphQL services directly rather than routing the requests from Python through to a GraphQL service then presumably to PostgreSQL.

Perhaps I am missing something. Indeed good luck to Drew here.

Re: How and why GraphQL will influence the Sourcehut alpha

#9

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.

I didn't read the post that way. I feel scaling is a small issue more so organization. Graphql does make sense for something like source hunt. Why not use type hints in python? Isn't that a good enough substitute? I wonder why go instead of rust if he wanted static typing, long term ease of maintanence and performance. Go's type system is not great especially for something like graphql. Gqlgen relies heavily on code…

>One major benefit the GP fails to mention is that with graphql, it is easy to generate types for frontend. This makes your frontend far more sane.

By GP (grandparent?) do you mean the article / blog post?

Because if so I see no indication that Drew plans to adopt a SPA architecture -- he seems intent on continuing to use server side rendering with little javascript, which would make "frontend types" sort of irrelevant.

Re: How and why GraphQL will influence the Sourcehut alpha

#10

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.

I didn't read the post that way. I feel scaling is a small issue more so organization. Graphql does make sense for something like source hunt. Why not use type hints in python? Isn't that a good enough substitute? I wonder why go instead of rust if he wanted static typing, long term ease of maintanence and performance. Go's type system is not great especially for something like graphql. Gqlgen relies heavily on code…

Code generation (of types and clinet/server stubs) can be done with any IDL (interface definition language). OpenAPI, GRPC, Thrift etc etc all support it. No reason to choose GraphQL only because of this.

The power in GraphQL comes from the graph and flexibility in fetching what you need. Usefull in general purpose APIs (like GitHub has).

Post reply on HN