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

11–20 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#11

Post by searchableguy »

TeeWEE wrote: post #10
searchableguy wrote: post #7

Earlier quoted context omitted.

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

I never said it was the only reason. I said it is one of the benefits that GP failed to mention in the post. Other benefits that GP mentioned still applies.

You can of course do this with other standards but ime, it's easier to do this with graphql since you only have to build the api. There is less overhead overall since type information is part of the standard, not necessarily something people add afterwards or choose to. Introspection, graphiql and all the tooling is easier to use and doesn't need integrating something like swagger.

It comes setup by default on most solid graphql frameworks.

Re: How and why GraphQL will influence the Sourcehut alpha

#12

Post by searchableguy »

CameronNemo wrote: post #9
searchableguy wrote: post #7

Earlier quoted context omitted.

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

You don't need spa to take benefits of the generated types from graphql. If you use something like typescript on the backend (SSR app), the types will be stripped out in the end so it doesn't affect your bundle size.

Re: How and why GraphQL will influence the Sourcehut alpha

#13

Post by CameronNemo »

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. Not that it is a terrible language, I just do not see the value add compared to even Python (let alone Kotlin or Rust).

Re: How and why GraphQL will influence the Sourcehut alpha

#14

Post by CameronNemo »

searchableguy wrote: post #12
CameronNemo wrote: post #9

Earlier quoted context omitted.

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

You don't need spa to take benefits of the generated types from graphql. If you use something like typescript on the backend (SSR app), the types will be stripped out in the end so it doesn't affect your bundle size.

You must understand my confusion when your original comment explicitly states that frontend types can be generated, but your reply here seems to be talking about a javascript/typescript backend service.

Re: How and why GraphQL will influence the Sourcehut alpha

#15

Post by ianamartin »

ghoshbishakh wrote: post #6
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.

what do you feel the problem is?

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" was meant more as actual good luck than a Morgan Freeman You're-trying-to-blackmail-batman kind of good luck.

Re: How and why GraphQL will influence the Sourcehut alpha

#16

Post by RcouF1uZ4gsC »

> 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 python, you have to be careful that a statement suddenly did not end up outside or inside an if block.

Re: How and why GraphQL will influence the Sourcehut alpha

#17

Post by erk__ »

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

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…

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

Re: How and why GraphQL will influence the Sourcehut alpha

#18

Post by searchableguy »

CameronNemo wrote: post #14
searchableguy wrote: post #12

Earlier quoted context omitted.

You don't need spa to take benefits of the generated types from graphql. If you use something like typescript on the backend (SSR app), the types will be stripped out in the end so it doesn't affect your bundle size.

You must understand my confusion when your original comment explicitly states that frontend types can be generated, but your reply here seems to be talking about a javascript/typescript backend service.

Sorry by backend, I mean your SSR app.

Re: How and why GraphQL will influence the Sourcehut alpha

#19

Post by philosopher1234 »

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…

Could you name some specific rough edges and missing functionality that have frustrated you? I'm a big fan of Go and have a good experience with it, so I'd be very curious to hear from someone with an opposite experience.

Re: How and why GraphQL will influence the Sourcehut alpha

#20

Post by [deleted] »

CameronNemo wrote: post #8
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.

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…

[deleted]
Post reply on HN