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

211–220 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#211

Post by crabmusket »

maddyboo wrote: post #120
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 think Drew is referring to composition in terms of API end-user code, not sr.ht code, e.g. making it possible for the user write a single GQL query that combines data from multiple sr.ht services.

Ah, I think that makes a little more sense. Thanks!

Re: How and why GraphQL will influence the Sourcehut alpha

#212

Post by dmitriid »

gavinray wrote: post #126
dmitriid wrote: post #95

Earlier quoted context omitted.

We're exploring a GraphQL serv(er/ice) for an internal back office system. It needs to combine multiple APIs into a single GraphQL interface. And everything just breaks apart :) (we have PoCs in C# and Java for now).

You can use Remote Schemas in Hasura to combine multiple API's, and Remote Joins to join relational data across data sources: https://hasura.io/docs/1.0/graphql/manual/remote-schemas/ind... https://hasura.io/blog/remote-joins-a-graphql-api-to-join-da... If you need to convert your API's into a GraphQL first, you can wrap the endpoints with resolvers yourself, or use automated tooling: https://github.com/Urigo/graphql…

I took a quick peek, it's no different than writing your own resolvers in any other implementation.

Re: How and why GraphQL will influence the Sourcehut alpha

#213

Post by dmitriid »

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…

This filtering is a custom DSL that really has nothing to do with GraphQL.

You might get away with it in a GraphQL implementation because you can possibly slap it in top a centralized endpoint, but I really question its efficiency in this case.

Re: How and why GraphQL will influence the Sourcehut alpha

#214

Post by goto11 »

jmull wrote: post #169
goto11 wrote: post #141

Earlier quoted context omitted.

I don't see the conflict? If the GraphQL query is translated into SQL on the server, then then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally.

The SQL your graphql implementation’s ORM middleware generates won’t optimize as well as hand-written SQL in many cases. A decent system will provide the hooks you need to hand optimize certain cases somehow, but There are always limitations and hoops to jump through and additional complexity to manage. The extra layers that are meant to make your life easier are getting in the way instead. (May or may not still be w…

But why wont it optimize as well as hand-written SQL? How can the query optimizer even tell the difference? Surely the SQL is transformed into some kind of syntax-independent abstract query tree before it is passed to the optimizer.

Re: How and why GraphQL will influence the Sourcehut alpha

#216

Post by Doxin »

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…

Honestly graphql is a fairly small step up from REST if you squint at it hard enough. You could get pretty much 90% of the effect of graphql with a REST framework and a couple of conventions:

- Have the client specify which fields to return, and return only those fields

- Use the above to allow for expanding nested objects when needed

- Specify an API schema somehow.

All GraphQL does is formalize these things into a specification. In my experience the conditional field inclusion is one of the most powerful features. I can simply create a query which contains all of the fields without paying for a performance penalty unless the client actually fetches all those fields simultaneously.

GraphQL queries tend to map rather neatly on ORM queries. Of course you run into the same sort of nonsense you get with ORMS, such as the n+1 one problem and whatnot. The same sort of tools for fixing those issues are available since your graphql query is just going to call the ORM in any case, with one large addition. Introspecting graphql queries is much easier than ORM or SQL queries. I can avoid n+1 problems by seeing if the query is going to look up a nested object and prefetch it. With an ORM I've yet to see one which allows you to do that.

Lastly GraphQL allows you to break up your API very smartly. Just because some object is nested in another doesn't mean they are nested in source code. One object type simply refers to another object type. If an object has some nested objects that needs query optimizing you can stick that optimization in a single place and stop worrying about it. All the objects referring to it will benefit from the optimization without knowing about it.

GraphQL combines all of the above rather smartly by having your entire API declared as (more or less) a single object. That only works because queries only run if you actually ask for the relevant fields to be returned. It's very elegant if you ask me!

Long story short: yes you run into the same sort of issues optimization wise you get with an ORM, but importantly they don't stack on top the problems your ORM is causing already.

Re: How and why GraphQL will influence the Sourcehut alpha

#217

Post by goto11 »

mixedCase wrote: post #145
goto11 wrote: post #141

Earlier quoted context omitted.

I don't see the conflict? If the GraphQL query is translated into SQL on the server, then then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally.

> then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally ...and other lies we tell ourselves to sleep soundly at night. But just like ORMs, they do work for the simple cases which tend to abound and you can hand-optimize the rest.

> ...and other lies we tell ourselves to sleep soundly at night.

So tell me how the query optimizer could possibly tell the difference between generated and hand-written SQL?

Re: How and why GraphQL will influence the Sourcehut alpha

#218

Post by zimpenfish »

pknopf wrote: post #135

I firmly believe GraphQL is a fad. It will never work, exposing the ORM to your clients. I'm curious, why don't we see more public-facing APIs using gRPC?

Currently working on a public-facing gRPC API and it's much more faffy than a REST API. Browsers don't talk gRPC which means you need to support gRPC-web endpoints. You probably need a gRPC aware proxy too and most of those have their own challenges. Some stuff doesn't like protobufs which means you need JSON transport which means protoc plugins. etc.etc. It's all just more work for (IMHO) little gain.

Re: How and why GraphQL will influence the Sourcehut alpha

#219

Post by mixedCase »

goto11 wrote: post #217
mixedCase wrote: post #145

Earlier quoted context omitted.

> then the query optimizer would optimize that just as effectively as if the query had been written in SQL originally ...and other lies we tell ourselves to sleep soundly at night. But just like ORMs, they do work for the simple cases which tend to abound and you can hand-optimize the rest.

> ...and other lies we tell ourselves to sleep soundly at night. So tell me how the query optimizer could possibly tell the difference between generated and hand-written SQL?

Because the SQL will not be the same. In complex cases, SQL generated by an ORM will do a combination of "more than it needs to" and plain inefficient queries. It can only do so much with what it knows about the database and the API used to call it.

Hand-written SQL gives the author a chance to be more precise in its needs, not only in the SQL but also by pre-generating obvious indexes to be performant from the get-go.

Re: How and why GraphQL will influence the Sourcehut alpha

#220

Post by mixedCase »

goto11 wrote: post #214
jmull wrote: post #169

Earlier quoted context omitted.

The SQL your graphql implementation’s ORM middleware generates won’t optimize as well as hand-written SQL in many cases. A decent system will provide the hooks you need to hand optimize certain cases somehow, but There are always limitations and hoops to jump through and additional complexity to manage. The extra layers that are meant to make your life easier are getting in the way instead. (May or may not still be w…

But why wont it optimize as well as hand-written SQL? How can the query optimizer even tell the difference? Surely the SQL is transformed into some kind of syntax-independent abstract query tree before it is passed to the optimizer.

No such thing. The database interface is SQL. The query optimizer is something run in the database.
Post reply on HN