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

181–190 of 232 posts

Re: How and why GraphQL will influence the Sourcehut alpha

#181

Post by austinpena »

chrisfosterelli wrote: post #149
kabes wrote: post #45

Earlier quoted context omitted.

That's indeed one of its selling points. But most products I see that adopt graphql are exactly 1 database.

I think lots of people here are fixed on GraphQL from a backend perspective and are missing that GraphQL has a fantastic front end development experience using libraries like Apollo. I honestly think the backend benefits are relatively marginal, but on the client being able to 1) mock your entire backend before it even exists, 2) have built in automatic caching on every query and entity for free, 3) use a fully decla…

Plus typescript + auto generating queries from graphql-let is literally heaven.

Re: How and why GraphQL will influence the Sourcehut alpha

#182

Post by geitir »

iso-8859-1 wrote: post #164
geitir wrote: post #116

One thing I've noticed is it seems redux and graphql are solving the same problem in an entirely different way

Redux brands itself as a tool for managing state. How does GraphQL manage state?

The way I see it is Redux is a local normalized store which can then be used via the selector pattern to generate custom objects / views. With GraphQL you are requesting that derived data to be generated for you via the query language.

Regarding managing state I don't see GraphQL helping with that at all.

Re: How and why GraphQL will influence the Sourcehut alpha

#183

Post by rojobuffalo »

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 was developed by Facebook to be used in conjunction with their frontend GraphQL client library called Relay. Most people opt Apollo + Redux because they were more active early on in releasing open source, and people argue it is an easier learning curve. IMO Relay is a huge win for the frontend to deal with data dependencies; and is a much better design than Apollo + Redux.

GraphQL formalizes the contract between front and back end in a very readable and maintainable way, so they can evolve in parallel and reconcile changes in a predictable, structured place (the GraphQL schema and resolvers). And it allows the frontend, with Relay, to deal with data dependencies in a very elegant and performant way.

Re: How and why GraphQL will influence the Sourcehut alpha

#184

Post by carapace »

zwkrt wrote: post #179
baddox wrote: post #38

Earlier quoted context omitted.

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

That sound cool! Is it online anywhere? I'd love to look at it.

Re: How and why GraphQL will influence the Sourcehut alpha

#185

Post by ochoseis »

matt_kantor wrote: post #152
cletus wrote: post #65

So I've now had the opportunity to use both GraphQL and protocol buffers ("protobufs" is the more typical term) professionally and I have some thoughts on this. 1. Protobufs use integer IDs for fields. GraphQL uses string names. IMHO this is a clear win for protobufs. Changing the name of a field of GraphQL is essentially impossible. Once a name is there it's there forever (eg mobile client versions are out there for…

> 3. Protobuf's notions of required vs optional fields was a design mistake that's now impossible to rectify without breaking changes. Can you elaborate on this? I've barely used protobufs, but in thrift I've found optional fields to be very useful.

I think you're on the same page.

The gist is that while you'd hope to have a stable interface, in reality things change. By marking fields required, they basically have to stay that way forever so you can support older clients. In doing so, you create a brittle API that may not be able to evolve with changing requirements.

For this reason, I believe Google got rid of required fields in proto3 (everything's either implicitly optional, or a repeated field which may have 0 elements).

Re: How and why GraphQL will influence the Sourcehut alpha

#186

Post by matt_kantor »

ochoseis wrote: post #185
matt_kantor wrote: post #152

Earlier quoted context omitted.

> 3. Protobuf's notions of required vs optional fields was a design mistake that's now impossible to rectify without breaking changes. Can you elaborate on this? I've barely used protobufs, but in thrift I've found optional fields to be very useful.

I think you're on the same page. The gist is that while you'd hope to have a stable interface, in reality things change. By marking fields required, they basically have to stay that way forever so you can support older clients. In doing so, you create a brittle API that may not be able to evolve with changing requirements. For this reason, I believe Google got rid of required fields in proto3 (everything's either imp…

Ah! I read your comment as "optional was a mistake", not "required was a mistake". We are indeed on the same page.

Re: How and why GraphQL will influence the Sourcehut alpha

#187

Post by hurricaneSlider »

GordonS wrote: post #172
hurricaneSlider wrote: post #121

Earlier quoted context omitted.

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

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 private APIs may not be the best idea, as it could be a sign of certain internal dysfunctions or communication problems within or between engineering teams.

----

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.

Of course you could add something like OData to your REST API which would definitely be a valid alternative, but that also would have its own warts, and is subject to similar criticisms as GQL.

Re: How and why GraphQL will influence the Sourcehut alpha

#188

Post by tomnipotent »

grok22 wrote: post #170
virtue3 wrote: post #148

Earlier quoted context omitted.

the graphql server has a contract (the schema) that it will follow, or 500. So you know what you get back is exactly to spec. Or you get nothing. REST endpoints are usually way more blackbox. You can't claim that REST is better cuz you can look at the server... when you could do the same thing to the graphql server. Graphql will -never- return you unwanted data. Because you wrote in the query exactly what you want. I…

>> Graphql will -never- return you unwanted data. Because you wrote in the query exactly what you want. But couldn't you intentionally or unintentionally write a query such that it returns too much data and borks the system? Un-intentionally is the worrisome aspect.

There is nothing inherent in other systems that prevents this scenario, so why should GraphQL? This is a design decision orthogonal to whether it's REST, GraphQL, SOAP, or what have you.

Re: How and why GraphQL will influence the Sourcehut alpha

#189

Post by tomnipotent »

kodablah wrote: post #158
satvikpendem wrote: post #157

Earlier quoted context omitted.

Yes, as this is the main reason that Facebook created GraphQL, it is expensive for mobile phones to query that much data. Something else interesting is that while you begin to write the tailored server side call, and you optimize it, you will end up with something that looks like GraphQL anyway.

Server-to-server GraphQL seems much more reasonable as both sides are controlled. It's the client-to-server I have less of a justification for compared to targeted calls w/ individual, limited contracts that are quantifiable and optimizable. I have witnessed the costs of allowing highly flexible data fetching from the client once it grows large.

> seems much more reasonable as both sides are controlled

GraphQL has been around for years and people keep making this argument, but where are all the horror stories of unbounded queries being made and systems being hobbled? The argument is beginning to sound anemic.

Re: How and why GraphQL will influence the Sourcehut alpha

#190

Post by tomnipotent »

jayd16 wrote: post #68
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 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?

Post reply on HN