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.<p>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 things like dispute dashboards was considerably more complicated compared to an abstraction that made sense for the clients (apps and website).<p>If we only had one graph, all the clients developers would have to develop around a data model that was far more unwieldy than they needed. But with two graphs, the world was a lot simpler (at the cost of having to maintain two graphs).
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.<p>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 some enormous value by naively just using GraphGL without involving Apollo?<p>That is a sincere question. What is the deal here?
Let's admit it - GraphQL is NOT simple-and-simply an easy replacement to REST.<p>I see it's advantages of having auto-documentation for each API. Thumbs up here.<p>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.
I disagree with the notion of `One Graph`.<p>We have multiple "gateways" for multiple backend services.<p>We have our main application that has one graph and we have multiple internal applications each owns its own graph.<p>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 question I have is with the "One Graph" idea. I get the principle, and it does seem like it would be nice. However, it's hard for me to imagine what this looks like in practice.<p>I haven't done anything with GraphQL in a few years. But when I did, we basically had several teams in a part of our organization (one of many in a huge giant megacorp) which built an API with GraphQL. We shared that code base and did the changes in it we needed for different parts of the graph. Sometimes it was fine, and sometimes it didn't go so well (unexpected issues, unexpected deployments when a team didn't prepare properly, etc). So it was an OK idea, but it caused some friction.<p>A decent of the problems were communication between teams of course. But even if communication was as good as one could imagine, it seems like this model would cumbersome at some point. And I can't imagine it spanning our entire organization, much less our entire megacorp across the board.<p>So assuming what we did wasn't good, what is a way you might make this work? Do you have a single code base like we did and just be more disciplined? Do you have a project whose job is to stitch together other schemas and pull in submodules? A monorepo for the entire company? Do you actually limit what the idea of the company is at some point to limit what the scope is that this should cover?<p>This turned out to be more of a ramble than anything. Oops.
Summary: have one company graph, implemented as federated implementations from different teams, with a registry for tracking the (iteratively evolving) schema. Use per-client access permissions and structured logging, incrementally improving performance as usage grows. Data graph functionality should be a separate tier rather than baked into every service.
We should probably add another point which is "you probably don't need Apollo tools".<p>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.
We've been working on doing something similar to create "one graph" at my job (though using our own library instead of graphql [1]).<p>There are definite difficulties to doing this, you need some strong cohesion between teams. If you try to do it in an agile manner, you're going to end up with a lot of duplication with minor differences. You'd need a way to flag existing similar data when trying to add new branches and nodes.<p>Our hope is to make our graph explorable and interactive so teams we don't have direct contact with, often in other countries, are able to find the data they would be interested in and see immediately how to read it out.<p>[1] <a href="https://dwstech.github.io/muster/" rel="nofollow">https://dwstech.github.io/muster/</a>
I think the single graph idea is impractical in any large organization. Every centralized model deteriorates over time due to many reasons: time pressure, carelessness and bigly varying competence levels in federated teams. A couple of years down the line everyone will hate it, and it'll be too big to discard.<p>Independent team structures and microservices based architectures are acknowledging that such monoliths are impossible to build and maintain.
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 :(
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.<p>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.<p>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!<p>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.
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: <a href="https://www.ibm.com/blogs/research/2019/02/graphql-api-management/" rel="nofollow">https://www.ibm.com/blogs/research/2019/02/graphql-api-manag...</a><p>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.
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!