So this apple/oranges thing is true and addressed in the article.
Have you used GraphQL/Apollo? It can do a lot of the things you're wanting:
- You can combine multiple data sources into a central datastore using GraphQL (REST APIs + DB queries etc.., that's one of the major benefits of it.
- Apollo on the client can manage local state as well as server state in one standardized interface.
- GraphQL is great for MVPs and Hobby projects but is used for a larger projects as well (Shopify, Github, Coursera, Facebook, Pinterest, Product Hunt, I could go on...).
I'd suggest you give it a shot, it's super fun to work with and isn't going anywhere anytime soon.
Re:How GraphQL Replaces Redux
by whalesalad on Tuesday March 13, 2018 @03:09PM
(#16578849)
A lot of the new work we do at FarmLogs is built with GraphQL. We've been running some critical apps with it and in a lot of aspects its a real joy. That being said, nested HoC's and the way it is used on the web is not ideal. Perhaps we are using it incorrectly there, but the documentation hasn't been a lot of help.
> You can combine multiple data sources into a central datastore using GraphQL (REST APIs + DB queries etc.., that's one of the major benefits of it.
Would love to see the docs on this because I have yet to find it!
I think the GP is referring to Apollo Client 2's ability to abstract over the underlying data source. Their intro blog post for the 2.0 announcement gives a good overview: https://dev-blog.apollodata.com/apollo-client-2-0-5c8d0affce...
Re:How GraphQL Replaces Redux
by dbetteridge on Tuesday March 13, 2018 @06:30PM
(#16580462)
I think they're referring to writing your server-side resolvers, there is no difference between requesting data from a database you own vs an API
Re:How GraphQL Replaces Redux
by connorelsea on Tuesday March 13, 2018 @04:23PM
(#16579456)
Currently writing an app that stores graphql data relationally in a redux store. Persists it, makes it available offline, etc. They work well together
This post is like all the others that tout, "moving from X language to Y saved us $3,000 per month on AWS" – it's usually not the transition from one tool to another, it's the fact that you rewrote your application with more knowledge and insight into the problem and have simply done a better job. Or in this case, a misuse of Redux led to a transition to GraphQL which painted Redux in a poor light.
There still isn't a compelling solution to problems like this... Apollo certainly isn't it. I want to feed GraphQL & REST into a central datastore in my application (be-it a Web/SPA/Browser app, or a local app) and abstract away the guts. A lot of devs are leaning on GraphQL for small experimental apps, fetching data in their components and violating every rule in the book on SRP and SOLID. It works for MVP's and hobby projects, but when you have a larger team, userbase, etc... the abstractions become critical.
We, as an ecosystem, need to focus more on those abstractions and not on the one-size-fits-all buzzword tooling. Server <> Datastore <> Application, not Server <> Application with the library of the week bolted in.