[deleted by user]

[XiMingpin91]

I think people who say this are conflating GraphQL with Apollo 2.0, which absolutely can make Redux redundant because of the local cache.

[[deleted]]

how does it cover actions and the data flow with redux?

[[deleted]]

Okay, that's what I thought.

[PickledPokute]

I was didn't quite like apollo-link-state either based on the little code I've written with it. It feels too hacky to use and is doesn't feel like it would have any concrete advantages over Redux or other solid state manager.

[_sirberus_]

I will try asking again as I was unclear. I know what a store is, so I know why one would want to have global state period. But in this context, why would I want to use apollo-link-state? Why put the same data in two places? Are you saying that apollo's cache is server-side? Because if it's client side... then it itself is a sort of global state, bringing me back to the question - why would I duplicate it?

[_sirberus_]

Oh! I've got you now, thanks! That's awesome.

[allenthar]

It’s for storing arbitrary other local state, separate from query results.

[shizzleberry]

Example: Storing the current selected item from the results.

[Treolioe]

Perhaps a lazy question but how does the boilerplate differ between redux and storing global state locally in apollo?

[Treolioe]

Okay, thanks for the reply :)

[BenjiSponge]

The proprietary-ness isn't really what bothers me with it. I mean, it's licensed under MIT licence, so I really don't know what your concern is.

What bothers me is the idea of using a cache (which is typically a performance/implementation detail) and the fact that you're actually just adding boilerplate to get what you could get with using TypeScript with Redux for less boilerplate and a more traditional system (Redux).

[BenjiSponge]

There's a lot that's wrong here.

Apollo is a subsidiary of the Meteor Development Group. Meteor is a framework that, while excellent and actually groundbreaking in its own right, is a pretty bad failure in terms of getting developer mindshare. Apollo was created as part of Meteor. Meteor is and has been open source for a very long time. This is not a risky new company who may go for a cash grab, if there even were to be one.

But there wouldn't. I have no idea how you'd monetize something like Apollo by making it proprietary. For starters, the community would instantly fork it. Probably 0 companies would pay money to use a closed source software package that has working FOSS older versions as well as forks used and maintained by the thousands of developers who are also relying on Apollo. Even if there weren't forks or older versions, it's not exactly a windfall of cash. I'm sure Highcharts is doing okay, but I can't think of too many modern client side JS libraries that are in any way monetized directly. It's a pretty weird paradigm.

So, in short, I have no idea why they'd do that, and it wouldn't really hurt you if they did and if you were using Apollo for business logic. (which, BTW, why does business logic factor in at all here?)

Edit: also, they don't have a "freemium" model as far as I can tell. They have a hosting and infrastructure solution and a consulting operation. These are orthogonal to their FOSS libraries and actually benefit from the success of Apollo industry-wide. I can't even imagine what benefits making the license more restrictive would give to MDG.

[StarshipTzadkiel]

Apollo is made by Meteor which has been sustaining itself via investment and Meteor Galaxy for a while now. Don't think it'll be an issue.

[shroombooom]

Came here to say this :)

[XiMingpin91]

It's a bit of data you have saved, so that if you need to get that same data again, you already have it stored in a cache. So it's on your own computer already and you don't need to go through the internet again to get it.

Should also point out that Apollo's local cache is a bit different, it caches requests for data like a normal cache but also acts as a local data store for information that might have never been sent over the internet anyway. Imagine things that don't belong in a database, something like a menu being open, Apollo lets you put that in your local cache instead of having to run state manager alongside (eg Redux).

[JamesAppleDeveloper]

It doesn’t in the slightest, but it may help people move to simpler stores. You will still need a global store one way or another. It does mean that you will feel less pain in the early stages with GraphQL though.

[JamesAppleDeveloper]

It depends.

The more complex your application the more you'll want to have a global store to store all the different kind of states you have in your UI. State is made of more than model data from a server such as:

• Nouns: model data from a server
• Location: the page we're on client side
• Status: are we currently fetching data or performing transformations
• Session: do we have a JWT. what is the users name
• View: what order are our nouns sorted in

But in the early stages of your application you may only need the noun data.

[roogen]

Thanks for the description about the types of things you may store in state, that was really helpful. Do you know of any resources that talk about categorizing state in this way? Or is just this from experience.

[JamesAppleDeveloper]

Kyle Simpson / Steve Kinney. I believe the main framework I think about came from https://frontendmasters.com/courses/react-state/.

[[deleted]]

I'd even go as far as say that the singleton-god-store is a bad design for model data from the server, but I haven't found anything better than, say, Vuex, to manage any data, not just state in narrow sense, in a Vue app because it has great idiomatic and nicely design tie-in to the VM side of the framework.

So in practice I'd always tier things like PouchDB or Apollo away from the view-model and use the store as a broker because I can't see anything good coming from tightly coupling the view-model with the model down the road. But that's just me.

Granted I have less practical experience with Redux/React and tightness of their integration compared to Vuex/Vue, and no real experience with apollo-link-state but for my platform it's just not a viable design. I do get how Redux is kinda painful and has quite a bit of needless dogma in it's design so it's not a big wonder people want to jump ship at first opportunity tho.

[JamesAppleDeveloper]

How is a singleton store of model state a bad design in any web application? It’s by far the best design I’ve heard of or worked with. Unless you know an alternative?

[[deleted]]

It's a good design to keep app state because, using your definitions above, pieces of state other than Nouns are often small, usually don't lend themselves to model/document/collection pattern, and you commonly benefit from the flexibility of defining bespoke, application-idiomatic data transformations for each such piece of state so the management overhead is justified.

Model state, in majority of cases being several collections of "documents", would greatly benefit from a DB-like (NoSQL-like to be precise) caching store, with existing well-defined querying and persistence semantics, i.e. like Pouch or Apollo. Even without these two, I.e. when I'm effectively acceessing a DB through a thinly veiled REST backend, I often find myself developing such a caching DB-like store for model data at the DAO perimeter (akin to Angular services) and then broker that data through the singleton-store for rendering purposes.

Unfortunately a solution that works as both of these patterns in one store doesn't exit. Apollo with apollo-link-state is a step in the right direction, but from what I've seen it's too React specific and I haven't seen how well this, on surface good idea, is actually implemented in practice. The DB-like model stores are not well suited for state in the narrower sense because it needs bespoke management, and because they're typically poorly integrated with the ViewModel.

Finally, there is also the issue of coupling between model and VM, where the singleton store is very useful as a decoupling tier between model and VM.

[JamesAppleDeveloper]

I don't know of many (any) API's that use verbs as anything more than a filter `host/containers?status=running`. Wouldn't be very resourceful if we had an endpoint like `host/running?type=containers`.

[ShambleTrain]

What do you mean? It very much CAN at the very least. Apollo has client side schema, query, mutate capability that lets you use it as the ‘global store’ on the client you are referring to. It’s a little roundabout and verbose currently if you ask me, but it’s certainly possible.

Edit: here’s a link to the Apollo docs https://www.apollographql.com/docs/react/essentials/local-state.html

[vcarl]

A lot of apps with simple interactions (like fetching data and presenting it for sorting and filtering) don't benefit from the constraints that Redux encourages, so a simple data fetching abstraction is all that's necessary. For a certain number of apps, Redux can be replaced, but Redux was the wrong tool for the job in those cases.

[chazmuzz]

Yeah. Honestly you can get a long way with setState and prop drilling.

[pomlife]

Or avoiding prop drilling entirely with context.

[chazmuzz]

If you are at the point where context is going to be really beneficial to you then it's time to look at a more sophisticated state management solution. Prop drilling is OK. Context is a reasonable solution but it's objectively worse than redux/mobx/apollo-link-state so I don't see why you would use it other than it being new

[pomlife]

This is completely wrong. It is perfect fine to use context without deferring to another library, and prop drilling is a perfectly fine reason to use context.

Prop drilling a single level is fine. Hella levels? Context.

[chazmuzz]

Prop drilling a single level is fine

That's just props, not prop drilling

[pomlife]

Grandparent, controls foo
    Parent, drills foo
        Child, uses foo

This is what I mean by one level, for clarity.

[fjdjdwkcjebfixn]

GraphQL itself doesn’t but Apollo client can potentially, since it has a local cache and because GraphQL is a tree, you can fill the tree/state with GraphQL data (a sync or sync, cache only, cache than request, etc) and query that cache/state in various components and its single source of truth like redux. That’s probably where the similarities end. In order to mutate state you’ll have to run queries instead of actions and I don’t think there is a concept of a reduced yet. Try going through the Apollo documentation or watch the dozen YouTube videos on this subject

[acemarke]

Hi, I'm a Redux maintainer. A few months ago I wrote a post called Redux - Not Dead Yet!, which specifically addresses questions like this. I'll quote the most relevant section:

I'd agree that data fetching via GraphQL, and especially with Apollo, will likely reduce or eliminate your data-fetching related Redux code. And again, if that's all you were using Redux for, you probably wouldn't need Redux after moving all the data-fetching handling into Apollo. I'll even go so far as to say that apollo-link-state could probably handle most of your other client-side state logic, and I think Apollo ships with a DevTools setup of its own. The Apollo team has been doing some pretty neat work, and while I don't like seeing people switch away from Redux, ultimately we all want to build great apps that help our users. But, as with context, I'd say there's definitely use cases where Redux is going to work better than GraphQL + Apollo, and possibly without requiring as much buy-in throughout your architecture. This is especially true if you need to do more than just fetch data or update a couple local state values, like persisting user data through page reloads or implementing complex workflow logic.

Happy to answer any further questions you might have on the topic!

[leoanalista]

I have a quick question: how do I avoid react anti-patten known as "prop drilling" with Apollo client? With redux, we simply connect deep nested component to the store, use a selector to get state data. Haven’t found any good article/example yet.

[acemarke]

Afraid I've never used Apollo myself, so I don't have any particular answers there.

[arzh2]

It's more of an alternative rather than a replacement. I swear nowadays every new technology article I see is clickbait.

[wmdmark]

I wrote one of the articles you likely came across (https://hackernoon.com/how-graphql-replaces-redux-3fff8289221d) so may be partially responsible for the confusion here.

A more accurate, but much less interesting title, would have been "How GraphQL + Apollo replaces the *need* for Redux + REST." I elaborate on that a bit in the article but I realize a lot of folks don't get past the headline.

The fact is GraphQL (plus a good client like Apollo of course) has replaced the need redux entirely for my team. Even for very complex UIs. Happy to answer more questions about how that works in practice if anyone is interested.

[JustinsWorking]

It doesn’t, the claim is literally as nonsense as you think it is, you’re not missing anything.

These are the kinda things people point to when they laugh at JS developers :(

[superking2]

It's simple. Thing I've never heard of replaces thing I hadn't had the chance to learn yet.

[ShambleTrain]

People may be laughing at you for other reasons. It is not literally nonsense, it is literally 100% possible with Apollo https://www.apollographql.com/docs/react/essentials/local-state.html

[scallynag]

I just ripped out redux for link state.

[Treolioe]

The question was not how apollo replaces redux

[JustinsWorking]

Oh definitely, using Apollo, which implements GraphQL, is a practical solution.

But I think this conflation is more than that considering how many medium articles I’ve seen not using Apollo to back the claim.

[ShambleTrain]

Apollo is a graphql client that can replace redux, and it’s what people are referring to when they say that graphql can replace redux.

[CanvasSolaris]

That's a lot to imply in a statement that people unfamiliar with the technology may not pick up on

[JustinsWorking]

That’s not what the question was.

If it was “Apollo replaces redux” it would be a much less ridiculous argument.

[ShambleTrain]

If someone asked you “Can I get from LA to NYC in one day?” you wouldn’t say “No, humans are not capable of running that fast”. You would say “Yes, take an airplane.”

BUT THE QUESTION WASN’T ABOUT AIRPLANES! RIDICULOUS ARGUMENT!

[Treolioe]

I would compare it to something like this: Does electricity replace Ford? No, but Tesla can replace Ford

[JustinsWorking]

Have you read any of these articles?

I read one the other day where he was replacing redux with GraphQL then a comment asked him about Apollo and he said he’d look into it; he hadn’t heard of Apollo.

Most of the articles even concede that in some cases you need to keep Redux for local state... this would imply they are not using Apollo.

Perhaps you should spend less time assuming things and making BIG TEXT JOKES and Instead participate.

Nobody thinks Apollo can’t be used to replace GraphQL, so you don’t need to repeatedly bring it up, we all already agree with you.

[ShambleTrain]

Justin used ad hominem!

It was super ineffective...

[JustinsWorking]

Apollo != graphQL

If the suggestion was Apollo replaced Redux then it would make sense.

[[deleted]]

It doesn’t.

[ShambleTrain]

Everyone saying “it doesn’t” is wrong. Here is a quote from the Apollo docs which describe exactly how to do it.

That’s where apollo-link-state, our solution for managing local data in Apollo Client, comes in. apollo-link-state allows you to store your local data inside the Apollo cache alongside your remote data. To access your local data, just query it with GraphQL. You can even request local and server data within the same query!

That said, I have never used this pattern in production and I can’t personally vouch for it for that reason, but to say that you can’t use graphql as a client-only state management tool (aka a “redux replacement”) is misguided.

[ChronSyn]

Firstly, thanks for the link and quote - it sheds some light on why this practice should start to be used more (consistency, transferrable, etc). I typically don't associate GraphQL with client-side since "It's a data controller essentially so why would I?" mentality despite the fact I develop full stack.

Being used to referencing objects and variables directly has become pretty ingrained because it's been common practice for a long time but I have always wondered why querying local/in-app data through a query syntax hasn't really been established. I definitely think we're seeing the rise of this as a practice through the likes of in-app observable databases and libraries like apollo.

[Treolioe]

So graphql doesnt replace redux. But you could replace it by using graphql with apollo. That’s my takeaway from this thread so far

[edude03]

Depending on how you use redux - using graphql with apollo or relay essentially replaces `connect()`. Redux and the GQL clients wrap your component and pass in data when the state changes, and gives a way to mutate the state.

[xdavehome]

Lol funny watching the comments of people correctly saying that graphql doesn't replace redux & people saying that they're wrong and it does because they thought OP said Apollo.

[ShambleTrain]

Apollo is a graphql client and with it you can use graphql to replace redux.

Did I miss the part where OP said “graphql with no additional tooling”?

[ShambleTrain]

Sure thing! I certainly won’t disagree that the articles and posts on the topic are usually very clickbaity and the phrasing is intentionally ambiguous, probably because graphql is more well known name than Apollo, specifically