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

51–60 of 88 posts

Re: Principled GraphQL

#51

Post by dfischer »

avitzurel wrote: post #2

I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).

Access could be limited by authorization. Role in JWT for instance.

You can't control malicious clients so I don't think the access part holds much water.

I think they are advocating a monolith deployment to maintain contracts across ownership and client expectations as a best practice vs the version management of multiple graphs requiring different cross sections of data for each client. It helps keep it consistent.

my 2 cents

Re: Principled GraphQL

#52

Post by dfischer »

Just wanted to throw out that this is cool amongst the critical feedback. Thanks Apollo and GraphQL for pushing the boundaries. It was fun using it when it was needed. Recently moved onto other pastures but solid progress!

Re: Principled GraphQL

#53

Post by judofyr »

PunksATawnyFill wrote: post #49

Why does HN pretend it's posting your comment and show you that it's posted, when this is BULLSHIT and no one else can see it? I posted a simple question about GraphQL and then came back to see if anyone had insights, only to find that no one else could see it. So... the solution is to create a new user ID before every question? Where do these guys get off deliberately wasting users' time?

Sounds like you've been shadow banned. You should contact hn@ycombinator.com and hear if there's been a mistake.

Re: Principled GraphQL

#54

Post by skc »

lopatin wrote: post #18
jcroll wrote: post #14

is graphql something anyone really needs unless they're facebook

While using GraphQL does have some benefits when dealing with a massive amount of users, that's not the reason most people choose to use it. GraphQL is simply a drastically different (and IMO better than REST) model for clients to talk to servers.

Well, I tested it by creating a little sample android app that fetched a collection of images for display in a grid.

For some reason I found this very simple scenario quite a hassle using a native GraphQL client for Android. And the alternative, ditching the client and making simple http requests was rather clunky when poking around what's returned.

Admittedly I only spent an hour or so on it but...REST just seems drastically simpler to get up and running with.

Re: Principled GraphQL

#55

Post by KuhlMensch »

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 with the data, in queries that can be used directly in production.

From what I have seen, the first (only?) ones to feel the pain it solves for are Product/Frontend/Clients.

Hopefully that ^ waves away some of the haze

Re: Principled GraphQL

#56

Post by samblr »

Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST.

I see it's advantages of having auto-documentation for each API. Thumbs up here.

Having said that, the amount of hoops one has to jump before completely adopting it - makes it 'meh'. There are lot of things : cache (clien-and-server), n+1, apollo (why?), deeply nested queries, schema stitching. The amount of patch work one needs to learn is not worth it.

Re: Principled GraphQL

#57

Post by danpalmer »

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…

Agreed. We decided to go with 2 views, an internal and an external. Currently the only GraphQL clients we have are customer facing so we just don’t model any internal details in the API. I expect we’ll introduce an internal one at some point.

Not only do these end up with very different data models, but they are also likely to have different access control (customer facing is basically all open, scoped to user, internal has many different layers and permissions), it’s likely to have different performance concerns, reliability, etc. That’s a lot of complexity you don’t need slowing you down when you’re building the other graphs.

Re: Principled GraphQL

#58

Post by AlecAivazis »

avitzurel wrote: post #2

I disagree with the notion of `One Graph`. We have multiple "gateways" for multiple backend services. We have our main application that has one graph and we have multiple internal applications each owns its own graph. I don't think the main application needs to know about the other internal graphs, nor should it have access to it (it should not even discover it).

One graph does not mean that the different parts have to know about each other. The different parts can be merged together without them knowing and form a single endpoint that the user can query without knowing where that data is coming from.

Re: Principled GraphQL

#59

Post by wawhal »

unleashit wrote: post #43
topspin wrote: post #38

I'm experiencing some frustration with this. Click on this principledgraphql.com site and you find it's 'Apollo.' Nearly everywhere you look on the Internet regarding GraphQL you find 'Apollo' being injected. I'm using GraphQL in production systems. One is Node (graphql-js) and another is Java (graphql-java.) I read the GraphQL specification and adopted the reference implementation and it works great. Am I missing so…

It's called marketing and they're pretty good at it. They do provide some useful tools however if you want to use them and don't just blindly follow the docs (which are selling you on things you may/may not need).

Apollo's marketing game has been ridiculously on point. They are the only GraphQL client in the ecosystem that is fully compatible with any GraphQL compliant server [0]. And since it is pretty good, whenever one has to talk/market/propose anything about GraphQL in the community, they end up cross-marketing for Apollo.

[0] Relay has its own spec and can be used only if the server supports it. Other GraphQL clients are either not well maintained or do not support as many features as Apollo does (caching, subscriptions are two features that come to mind)

Re: Principled GraphQL

#60

Post by miki123211 »

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…

From my (naive) understanding it seems that one graph would not exactly be right, one graph per bounded context might be more likely. I think one graph might fail when one entity means something different for different clients. Imagine a SAAS system where customer means any currently paying user for the main saas, any prospective or current user for marketing and any enterprise user that has signed a deal or wants to sign one for enterprise sales. There's just no way to map those three into a single customer type. Similarly, in a school management system, a student, with all his personal details, might be one entity for a school nurse or the dean, but n different entities for a teacher who teaches that one student n things. How would you map that to one graph?
Post reply on HN