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

201–210 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#201

Post by AmericanChopper »

GordonS wrote: post #180
AmericanChopper wrote: post #112

GraphQL as a query language is simply better than REST in most cases imo. REST has too much client side state, which not only has the potential to make things harder for clients to consume, but also has all the inconsistent states to handle where your consumer gets part way through a multiple-REST method workflow, and then bails. REST also absolutely sucks for mutating arrays. Really I just look at GraphQL as a nice…

> GraphQL as a query language is simply better than REST in most cases imo. REST has too much client side state, which not only has the potential to make things harder for clients to consume, but also has all the inconsistent states to handle where your consumer gets part way through a multiple-REST method workflow, and then bails. How much client state you maintain seems to me to be orthogonal to GraphQL/REST. Take…

You could do that, but if you start creating endpoints for transactions rather than method -> resource endpoints, then you’re not really making a REST interface anymore. But even ignoring REST purity, I’d argue that GraphQL is better suited to that design pattern in general.

Re: How and why GraphQL will influence the Sourcehut alpha

#202

Post by jayd16 »

tomnipotent wrote: post #190
jayd16 wrote: post #68

Earlier quoted context omitted.

I agree with you but I do wish for something that can improve on rest in ways GraphQL at least purports to. Query chaining/batching and specifying a sub-selection of response data seem like solid features. The graph schema seems to make good on some of the HATEOS promises. I like the idea of GraphQL but the downsides have me worried.

> but the downsides What do you consider the downsides?

No caching. Not enough benefit at the present to warrant throwing away all the restful tooling we currently have.

Re: How and why GraphQL will influence the Sourcehut alpha

#203

Post by GordonS »

AmericanChopper wrote: post #201
GordonS wrote: post #180

Earlier quoted context omitted.

> GraphQL as a query language is simply better than REST in most cases imo. REST has too much client side state, which not only has the potential to make things harder for clients to consume, but also has all the inconsistent states to handle where your consumer gets part way through a multiple-REST method workflow, and then bails. How much client state you maintain seems to me to be orthogonal to GraphQL/REST. Take…

You could do that, but if you start creating endpoints for transactions rather than method -> resource endpoints, then you’re not really making a REST interface anymore. But even ignoring REST purity, I’d argue that GraphQL is better suited to that design pattern in general.

When most people refer to REST APIs, they really mean "HTTP APIs". I really don't think we should reach for GraphQL just because of the ideological notion of daring to not adhere 100% to REST.

Re: How and why GraphQL will influence the Sourcehut alpha

#204

Post by GordonS »

hurricaneSlider wrote: post #187
GordonS wrote: post #172

Earlier quoted context omitted.

> A restful API also has the problem that if you want fine grained auth, you'll need to remember to add the policy to each controller or endpoint, so not that different. This is dependent on the framework, just as it is with GraphQL - for example, with ASP.NET Core you can apply an auth policy as a default, or by convention. > Despite efforts to ensure that filtering was fairly generic, there was a lot of adhoc code…

The transport API I was referring to was written in .NET Core. I think .NET core is great at what it does, but runs into the same kinds of problems that GraphQL tries to address from the start once your API becomes sufficiently featured, which is likely to happen if you're offering an API as a service. I actually think that unless your company is massive or has a lot of expertise in GraphQL already, using it for priv…

> An example, however of the kind of filtering I was referring to, and why I still think it would be non trivial to do, even in something like ASP.NET, is the following: https://www.gatsbyjs.org/docs/graphql-reference/#filter. This of course isn't something you get out the box in GraphQL either, but the structure of the system made this (relatively) easy to do.

Ah, then I misunderstood; I was thinking along the lines of dotnet's authorisation filters.

Filtering might require some reflection, expressions or funcs, which aren't necessarily "everyday" things for some devs, but they shouldn't pose any real trouble for seasoned dotnet devs. If you really want a standard that works OOTB for Entity Framework (and I assume EF Core), you have the option of OData too.

Re: How and why GraphQL will influence the Sourcehut alpha

#205

Post by carapace »

orf wrote: post #195
carapace wrote: post #193

Earlier quoted context omitted.

I haven't used Django in years, so maybe things have changed, but I recall two incidents that stick in my mind and prevent me from taking the whole project seriously. The first was when they removed tracebacks. Singularly useless thing to do IMO. But there's a --show-tracebacks option (or something like that, it was a long time ago) to show tracebacks, but it didn't work. I dug into the code for this one. IIRC, the g…

I appreciate your reply, but Django never “removed tracebacks” and I would love to see a declarative form that didn’t use metaclasses in some way. Here’s the ~20 lines of cowboy code you’re referring to[1] - collecting the declared fields and setting an attribute containing them. Not exactly the kind of thing that should make you mad, and rather than overkill it’s exactly the use case for metaclasses. And to top it o…

> I appreciate your reply

Cheers!

> Django never “removed tracebacks”

I don't want to get into a juvenile back and forth, but I must insist that Django did so suppress tracebacks. I don't know what it does today but I remember clearly patching the server code to re-enable them and that the '--traceback' CLI switch didn't do it.

> I would love to see a declarative form that didn’t use metaclasses in some way.

Here you go: https://pypi.org/project/html/

Clever design, elegant code, under 20k (including docs and tests), no metaclasses.

> Not exactly the kind of thing that should make you mad, and rather than overkill it’s exactly the use case for metaclasses.

There is no use case for metaclasses. GvR called that paper "The Killing Joke" for a reason. ( https://www.python.org/doc/essays/metaclasses/ https://www.youtube.com/watch?v=FBWr1KtnRcI ) I read it for kicks, because I'm that kind of freak, but it's not the kind of thing that you should ever use in production code.

What made me mad is that Django's gratuitous use of metaclasses broke my junior dev. The kid was doing the right thing and it was exploding in his face with an inscrutable error message: that's on Django.

Re: How and why GraphQL will influence the Sourcehut alpha

#206

Post by AmericanChopper »

GordonS wrote: post #203
AmericanChopper wrote: post #201

Earlier quoted context omitted.

You could do that, but if you start creating endpoints for transactions rather than method -> resource endpoints, then you’re not really making a REST interface anymore. But even ignoring REST purity, I’d argue that GraphQL is better suited to that design pattern in general.

When most people refer to REST APIs, they really mean "HTTP APIs". I really don't think we should reach for GraphQL just because of the ideological notion of daring to not adhere 100% to REST.

If you’re going to abandon REST design principles, then you’ll eventually end up with something that pretty much does what GraphQL does. At that stage why not just adopt a more fit-for-purpose set of design principles?

Keep in mind that I’m only really advocating for it as a query language for HTTP APIs (which as a side benefit has some nice existing tooling which you may or may not find useful).

Re: How and why GraphQL will influence the Sourcehut alpha

#207

Post by kupaka »

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

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

jfyi, The Onion hasn't run on Python for a few years now. In 2017, they migrated over to Gizmodo's Scala stack.

Re: How and why GraphQL will influence the Sourcehut alpha

#208

Post by orf »

carapace wrote: post #205
orf wrote: post #195

Earlier quoted context omitted.

I appreciate your reply, but Django never “removed tracebacks” and I would love to see a declarative form that didn’t use metaclasses in some way. Here’s the ~20 lines of cowboy code you’re referring to[1] - collecting the declared fields and setting an attribute containing them. Not exactly the kind of thing that should make you mad, and rather than overkill it’s exactly the use case for metaclasses. And to top it o…

> I appreciate your reply Cheers! > Django never “removed tracebacks” I don't want to get into a juvenile back and forth, but I must insist that Django did so suppress tracebacks. I don't know what it does today but I remember clearly patching the server code to re-enable them and that the '--traceback' CLI switch didn't do it. > I would love to see a declarative form that didn’t use metaclasses in some way. Here you…

> Here you go: https://pypi.org/project/html/

That’s not even the same thing - it’s a (horribly old) library for generating HTML.

We’re talking about forms: sets of typed fields including validations that can be optionally rendered to HTML. Think wtforms[1]

> There is no use case for metaclasses.

There are, that essay (about Python 1.5 no less) does little to dissuade people from using them, going so far as to offer concrete code samples.

It’s also hopelessly outdated: nobody uses metaclasses like that at all, especially not for tracing! It’s hard to blame it though, this document was written before even decorators where introduced.

And let’s not ignore the call to authority by pointing out that GvR uses metaclasses extensively while working on type hints, GaE libraries, and even in his early asyncio code.

In actual fact metaclasses a few use cases, including the most common: syntactic sugar. Like anything this can be heavily abused and is most useful when creating libraries rather than used within traditional application code. In any case, shunning it wholesale is stupid.

Half remembered issues with junior developers are not great arguments against a useful part of a language. Who’s to say that it was even related to metaclasses, and your apparent allergy to them isn’t colouring your memory?

1. https://wtforms.readthedocs.io/en/2.3.x/crash_course/#gettin...

Re: How and why GraphQL will influence the Sourcehut alpha

#209

Post by camgunz »

A lot of places have a hell of a time dealing with very nested graphql queries that effectively DoS your app servers, or a resolver that’s very slow. Caching is also an open question. But for the simplest systems, I’d hesitate to recommend graphql at this point.

Re: How and why GraphQL will influence the Sourcehut alpha

#210

Post by carapace »

orf wrote: post #208
carapace wrote: post #205

Earlier quoted context omitted.

> I appreciate your reply Cheers! > Django never “removed tracebacks” I don't want to get into a juvenile back and forth, but I must insist that Django did so suppress tracebacks. I don't know what it does today but I remember clearly patching the server code to re-enable them and that the '--traceback' CLI switch didn't do it. > I would love to see a declarative form that didn’t use metaclasses in some way. Here you…

> Here you go: https://pypi.org/project/html/ That’s not even the same thing - it’s a (horribly old) library for generating HTML. We’re talking about forms: sets of typed fields including validations that can be optionally rendered to HTML. Think wtforms[1] > There is no use case for metaclasses. There are, that essay (about Python 1.5 no less) does little to dissuade people from using them, going so far as to offer…

I really don't want to argue about this.

You're not going to convince me that Django isn't an overblown toy. I'm not going to convince you that it is.

Same with metaclasses, you're not going to convince me that they're a good idea (despite what GvR does with them) and I'm not going to convince you that using them is irresponsible.

So what are we left with?

> That’s not even the same thing

But html.py (would have) solved the problem we had. without the nasty surprise.

> In any case, shunning it wholesale is stupid.

No, it's conservative. That's a different thing.

I want to be able to hire someone who can modify a form. The more complex and obscure the the code is (even if it's only twenty lines long) the smaller the pool of folks who can use it with mastery.

Think about it.

Anyway, I'm off learning Erlang/OTP now and it really makes Python's runtime look like a joke in comparison. Web-app backends are Erlang-shaped, not Python-shaped. Not using it sooner makes me feel stupid.

Post reply on HN