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

191–200 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#191

Post by nawgszy »

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 would say that you're also completely ignoring the benefits of typing. It's fair to say JS's lack of typing is a deep flaw, and so tools like TypeScript and GraphQL (which pair magically by the way; free type generation!) are ways to lift the typing from the backend to the frontend and give frontends stories around typing and mocking APIs that greatly improve the testability of the code.

Re: How and why GraphQL will influence the Sourcehut alpha

#192

Post by tomnipotent »

stevenjohns wrote: post #64
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…

Where I'm at now is my first foray with GraphQL - Graphene on the Django backend and Apollo on the frontend. I'm not sure if it is the implementation - and it could very well be - but there has been more overhead and complexities than with traditionally accessed REST APIs. I can't see much value-add. This becomes a lot more apparent when you start to include TS in the mix. Perhaps it just wasn't a good use case.

It all depends on whether you expect to 1) use GraphQL as an ORM replacement or 2) use GraphQL as a layer to aggregate multiple disparate services into a unified API.

Most people want #1, Graphene is a bad choice because you still have to write a lot of boilerplate code. It has the added benefit that the current process is responsible for parsing the GraphQL query and directly calling the database, vs. using something like Prisma/Hasura which (may) require a separate process which in turn calls your database (so 2 network hops).

GraphQL was never intended to be an ORM replacement, but many have steered it towards that direction. It's not a bad thing, but it's still the same level of abstraction and confusion that people have wrestled with when using traditional ORM's except now you're introducing a different query API vs. native code/fluent interfaces/SQL.

Re: How and why GraphQL will influence the Sourcehut alpha

#193

Post by carapace »

orf wrote: post #77

The author says that he has soured on Python for “serious, large projects”. While it’s clearly personal opinion, and that’s fair enough , I can’t help but think his choice of framework hasn’t helped him and has likely caused significant slowdown when delivering features. Looking through some of the code for Sourcehut, there’s an insane amount of boilerplate or otherwise redundant code[1]. The shared code library is a…

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 guy who added the code to suppress tracebacks didn't take into account the CLI option. I patched it to not suppress tracebacks but there turned out to be another place where tracebacks were suppressed, and I eventually gave up.

The second incident (although, thinking about it they happened in chonologically reversed order) was when a junior dev came to me with a totally wacky traceback that he couldn't understand.

All he was trying to do was subclass the HTML Form widget, like a good OOP programmer, but it turned out that Django cowboys had used metaclasses to implement HTML Forms, and utterly defeated this poor kid.

I was so mad: Who uses metaclasses to make HTML forms? Overkill much?

(In the event the solution was simple: make a factory function to create the widget then patch it to have the desired behaviour and return it. But you shouldn't have to do that: OOP works as advertised, why fuck with a good thing?)

So, yeah, Django seems to me to be run by cowboys. I can't take it seriously.

FWIW, I'm learning Erlang/OTP and I feel foolish for thinking Python was good for web apps, etc. Don't get me wrong, I love Python (2) but it's not the right solution for every problem.

Re: How and why GraphQL will influence the Sourcehut alpha

#194

Post by tomnipotent »

staticassertion wrote: post #153
kabes wrote: post #42

Earlier quoted context omitted.

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

It's not nearly as complex as paging, which has a similar purpose of limiting single-query complexity.

Anyone use MSSQL before it got ROW_NUMBER and window functions? Paging was a literal nightmare - if you wanted records 101-110, you had to fetch 1-110 and truncate the first 100 rows yourself (either in the DB via stored procedure or in your app code). I wish LIMIT/OFFSET was SQL ANSI standard.

Re: How and why GraphQL will influence the Sourcehut alpha

#195

Post by orf »

carapace wrote: post #193
orf wrote: post #77

The author says that he has soured on Python for “serious, large projects”. While it’s clearly personal opinion, and that’s fair enough , I can’t help but think his choice of framework hasn’t helped him and has likely caused significant slowdown when delivering features. Looking through some of the code for Sourcehut, there’s an insane amount of boilerplate or otherwise redundant code[1]. The shared code library is a…

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 off, that metaclass is completely optional, if you want to create a list of fields and pass it into BaseForm then go for it. Most don’t.

1. https://github.com/django/django/blob/5776a1660e54a951591644...

Re: How and why GraphQL will influence the Sourcehut alpha

#197

Post by tango12 »

tomnipotent wrote: post #192
stevenjohns wrote: post #64

Earlier quoted context omitted.

Where I'm at now is my first foray with GraphQL - Graphene on the Django backend and Apollo on the frontend. I'm not sure if it is the implementation - and it could very well be - but there has been more overhead and complexities than with traditionally accessed REST APIs. I can't see much value-add. This becomes a lot more apparent when you start to include TS in the mix. Perhaps it just wasn't a good use case.

It all depends on whether you expect to 1) use GraphQL as an ORM replacement or 2) use GraphQL as a layer to aggregate multiple disparate services into a unified API. Most people want #1, Graphene is a bad choice because you still have to write a lot of boilerplate code. It has the added benefit that the current process is responsible for parsing the GraphQL query and directly calling the database, vs. using somethin…

(I'm from Hasura)

While Hasura + GraphQL can be used as an ORM (especially for serverless functions!), Hasura is designed to be used directly by clients as well.

Hasura has a metadata configuration system that works on top of an existing database that allows configuring mapping, relationships and most importantly permissions that make the GraphQL feasible to be used by even frontend apps. [1]

Further, Hasura has remote joins that can "join" across Postgres, GraphQL, REST sources and secure them. [2]

[1] https://hasura.io/blog/hasura-authorization-system-through-e...

[2]: https://hasura.io/blog/remote-joins-a-graphql-api-to-join-da...

Re: How and why GraphQL will influence the Sourcehut alpha

#198

Post by andrewingram »

jayd16 wrote: post #174
real_ben_michel wrote: post #155

Earlier quoted context omitted.

Having seen many product teams implement graphQL, concerns were never around performances, and more around speed of development. A typical product would require integrations with several existing APIs, and potentially some new ones. These would be aggregated (and normalised) into a single schema built on top of GraphQL. Then the team would build different client UIs and iterate on them. By having a single queryable s…

I wonder if GraphQL would make more sense as a client side technology. The goals of dev ease seem better served by a graph the client can build (and thus span multiple remote services). Instead of transforming the backend, you simply get a better UI dev experience and the middleware handles query aggregation. You'd want code gen to easily wrap REST services. You could get some of the pipeline query/subquery stuff bac…

I always say that GraphQL is best thought of as frontend code that lives on a backend server. If in your current world you have front-end code that talks to multiple traditional REST endpoints, the frontend is therefore responsible for managing all the relationships between the API data in order to build a coherent object graph which the UI can interpret. GraphQL turns this object graph into a first class citizen that can be consistently queried, rather than something everyone keeps having to reinvent, and moves it closer to the source of truth (the downstream services) for performance reasons (so that each network hop can be measured in single digit milliseconds rather than tens or hundreds).

I've seen GraphQL schemas being implemented on the client, it's certainly doable, but the performance is terrible compared to doing it on a server close to the source of truth.

Re: How and why GraphQL will influence the Sourcehut alpha

#199

Post by andrewingram »

GordonS wrote: post #156
kodablah wrote: post #154

Earlier quoted context omitted.

Pardon my naivete, are the benefits of the flexibility that GraphQL give worth the unpredictability costs (or costs of customizing to add limits) of that same flexibility compared to writing a tailored server side call to do those calls and return the limited data instead?

Yeah, I just don't get it - even if you use GraphQL, you're going to have to do server-side code to make the calls to the different backends. Maybe it's just that the backend devs in my last project werenyevery good, but the backend GraphQL code was ridiculously complex and impossible to reason about.

It's easy to write an incomprehensible GraphQL server the first time you try it, but it's by no means an innate trait of the technology. Assuming your downsteam APIs are done well, it should be possible to write a GraphQL server which is easy to reason about and has predictable performance (largely on par with what you'd get if you built the endpoints by hand).

Re: How and why GraphQL will influence the Sourcehut alpha

#200

Post by andrewingram »

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 a PR problem and i'm not 100% happy with it, but I've been using it since 2015 (never worked at Facebook) and would still choose it over Apollo. Main reason is that Apollo is geared towards getting up and running easier, but this leads to a worse overall experience beyond that point.
Post reply on HN