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

171–180 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#171

Post by orf »

Scarbutt wrote: post #168
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…

Some devs prefer clear, flexible and performant/unambiguous code to 20 layers of abstraction.

They do indeed. But then they realise that copy-pasting repetitive authentication and validation boilerplate everywhere leads to inconsistencies, bugs and at worst security issues.

Then they build their own abstractions. And then, congratulations, they’ve spent longer than they should have to end up with a worse version of Django, that nobody but them finds “clear” or “unambiguous”.

If only we could capture these common, repetitive and important patterns and put them in some kind of library. A “framework”, if you will. That way you don’t need to copy-paste this stuff over and over again, and anyone who knows the library will find it clear and unambiguous!

In fact this is such a good idea that I’m going to do it myself. I’ll call the library Franz, after a famous pianist.

Re: How and why GraphQL will influence the Sourcehut alpha

#172

Post by GordonS »

hurricaneSlider wrote: post #121
dmitriid wrote: post #56

Earlier quoted context omitted.

> I don't understand the attraction to Graphql. It's attractive primarily to frontend developers. Instead of juggling various APIs (oftne poorly designed or underdesigned due to conflicting requirements and time constraints) you have a single entry into the system with almost any view of the data you want. Almost no one ever talks about what a nightmare it becomes on the server-side, and how inane the implementations…

> usable only for internal projects where you have full control of who has access to your system, and can't bring it down because you forgot an authorization on a field somewhere or a protection against unlimited nested queries. As someone who is building a public facing GraphQL API, I would disagree with this. Directives make it easy to add policies to types and fields in the schema itself, making it amenable to eas…

> 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 that needed to be written to handle filtering.

I've never seen this problem with REST backends myself, but I work with a typed language, C#. Again though, this is more of a framework thing than a REST/GraphQL paradigm thing.

Re: How and why GraphQL will influence the Sourcehut alpha

#174

Post by jayd16 »

real_ben_michel wrote: post #155
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…

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 back (and lose caching) by setting up a proxy running this service or fallback to client side aggregation to span services not backed by the graph system (and maybe keep caching).

Maybe we're back to SOAP and WSDLs, though.

Re: How and why GraphQL will influence the Sourcehut alpha

#175

Post by iooi »

I wanted to learn GraphQL recently and I wrote a small library to automagically generate GraphQL schemas from SQLAlchemy models. [1]

It's inspired by Hasura, the schema is almost the same. It's not optimized at all, but it's a nice way to quickly get started with GraphQL and expose your existing models.

[1] https://github.com/gzzo/graphql-sqlalchemy

Re: How and why GraphQL will influence the Sourcehut alpha

#176

Post by GordonS »

DrFell wrote: post #118
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…

GraphQL is instant API to frontenders. Their justification for needing it is that the API team takes too long to implement changes, and endpoints never give them the data shape they need. The silent reason is that server-side code, databases, and security are a big scary unknown they are too lazy to learn. A big project cannot afford to ask for high standards from frontenders. You need a hoard of cheap labor to crank…

> Their justification for needing it is that the API team takes too long to implement changes, and endpoints never give them the data shape they need.

I've certainly seen timing issues between frontend and backed teams; actually, I don't think I've ever been on a project where that wasn't an issue!

But on my last project, which had a GraphQL backend, this was still a problem. The backend integrated with several upstream databases and REST APIs, so the backend team had to build the queries and implementations before the frontend could do anything. At least with REST they would have been able to mock out some JSON more easily.

Re: How and why GraphQL will influence the Sourcehut alpha

#177

Post by jbreiding »

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…

Graphql is generally referred to as be4fe, meaning backends for frontend.

Not exactly client side, but the main consumer is the client and s2s or service to service isn't intended target.

Re: How and why GraphQL will influence the Sourcehut alpha

#178

Post by GordonS »

crabmusket wrote: post #119

> Another (potential) advantage of GraphQL is the ability to compose many different APIs into a single, federated GraphQL schema. If anyone else can share experiences of this sort of problems and solution, I'd be really interested to hear it. I've written non-GQL APIs before that back onto other internal and external services; what am I missing?

I've mentioned my (negative) experience elsewhere in this thread. It wasn't actually me doing the implementation, but the result was a horrendous, unmaintainable and slow code base. Ultimately, no part of the team benefited from the use of GraphQL instead of REST.

To be fair, the same devs that built it using GraphQL would likely have made many of the same mistakes with a REST API, but I do feel it would at least have been easier to reason about the code.

Re: How and why GraphQL will influence the Sourcehut alpha

#179

Post by zwkrt »

baddox wrote: post #38
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…

GraphQL is quite similar to SQL. They’re both declarative languages, but GraphQL is declaring a desired data format, whereas SQL is declaring (roughly) a set of relational algebra operations to apply to a relational database. GraphQL is really nothing like an ORM beyond the fact that they are both software tools used to get data from a database. You might use an ORM to implement the GraphQL resolvers, but that’s cert…

For a fun hack-week project I created a graphql server that would automatically create any necessary SQL tables to support a query given to it. So if you made the query

    query {
        user {
            name
            email {
                primary
                secondary
            }
            posts {
                body
                karma
            }
        }
    }
It would create an entire database schema with users, emails, and posts, and the correct indexes and fk relations to support the graphql query. It would also generate mutations for updating the entities in a relational, cascading manner, so deleting a user would also delete their email and posts.

Re: How and why GraphQL will influence the Sourcehut alpha

#180

Post by GordonS »

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 your example or a multiple-REST workflow. I presume your point was that the workflow could be implemented by a single GraphQL query/mutation/whatever - but just the same, you can put as much code and logic as you like behind a REST call?

Post reply on HN