Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Principled GraphQL

principledgraphql.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: Principled GraphQL

#81

Post by arunix »

andrewingram wrote: post #13

The main argument I have against "One Graph", is that it's not that uncommon to have two (or more) quite distinct views of the world. At my last job, we were building a social shopping app. Behind the scenes, products were versioned so that we could deal with disputes related to attempts to defraud customers. This (along with several other things) meant that the logical internal abstraction of the data model for thin…

Which graph technology were you using, and were the graphs maintained separately or via some kind of syncing?

Re: Principled GraphQL

#82

Post by jcroll »

KuhlMensch wrote: post #55
jcroll wrote: post #14

is graphql something anyone really needs unless they're facebook

Well, its a fancier API tool, which smooths out the flow between Backend and API consumers better (at a cost). At its core, it is a project based around a _consumer facing schema_, that can be queried. You put in upfront and ongoing be work to give product/frontend/clients the ability to discuss data requirements around a first-class schema, and then once the resolvers are written, allow them to explore/experiment wi…

I believe it makes life easier for consumers. What about if you have to maintain the api? And if it is that much harder to maintain is it really a smart choice unless the surface area of your api is the size of say Facebook's?

Re: Principled GraphQL

#84

Post by ewittern »

Principle 8 mentions "demand control", including "estimating the cost of a query before performing it". This is very much in line with GraphQL API Management work we are doing at IBM Research. I recently wrote about this: https://www.ibm.com/blogs/research/2019/02/graphql-api-manag...

I wonder about the other proposal for demand control, namely that untrusted users "should only send queries that have been preregistered by the authenticated developer of the app". To me, that seems to somewhat negate a great advantage of GraphQL, namely giving clients more flexibility in deciding (on the fly) what data to fetch/mutate.

Re: Principled GraphQL

#85

Post by tlrobinson »

debergalis wrote: post #28
tlrobinson wrote: post #26

Earlier quoted context omitted.

Is there any reason you couldn't have multiple graphs essentially overlaid on top of each other? With proper tooling you could expose different subsets of the same schema in different scenarios, and still have one unified graph underneath.

Agree. And congrats on the round.

Thanks!

Re: Principled GraphQL

#86

Post by mst »

debergalis wrote: post #31
mst wrote: post #30

There's nothing that says "we're really good at making front end development easier" like a website where even after I click into the main frame it completely fails to respond to up/down/pgup/pgdown ... I understand the whole "should work on mobile" thing but it should also bloody well work on a desktop too :(

Thanks, looking into it. I agree and I hope we're able fix this. We're moving all of the Apollo docs to the same system. It's built on Gatsby, which uses GraphQL under the hood.

Cheers. I get really cranky about my keyboard not working (twitter's web UI manages to break it under a bunch of circumstances, which aggravates me at least once a week) but I'm well aware that there's always a billion things that need doing :)

Re: Principled GraphQL

#87

Post by RussianCow »

danpalmer wrote: post #80
vanwalj wrote: post #68

We should probably add another point which is "you probably don't need Apollo tools". I'm using GraphQL in production since 2015 and I feel like the only Apollo contribution to the ecosystem was pushing lot of marketing content around their hacky tools and "best practices", leading teams to poorly designed backends.

Yeah, I haven't seen a lot that has been particularly useful from Apollo so far. They supposedly have a slightly different recommended way of doing the things Relay tries to do, but it's poorly documented and only compatible with Apollo, whereas the Relay spec is relatively clear (just the spec, I haven't used the Relay library). Also they seem entirely JS focused. Our backend is Python and our frontend so far is Swi…

I'm currently working on building an open source library for building backend GraphQL APIs in Python. I'd love to hear your use cases! My email is in my profile, if you're interested.

Re: Principled GraphQL

#88

Post by tlivings »

Single graph: Large companies often do not have a single graph. Different experiences and use cases require necessary variation in how teams surface data and do experimentation independently from other teams.

Federated implementation. Implementation being spread across many teams is important, but if that is through federated services being reused by multiple teams, it can create brittle dependencies.

Track schema in the registry: It's difficult to have a single source of truth when it is unable to display the variation based on #1 comment. I don't think anyone has solved this well for really large systems. Good principle but hard in practice!

I think it is really hard for a VC backed company selling a product to describe principles without being biased. This feels very biased toward selling their product.

Post reply on HN