GraphQL Cache vs MobX: What are the differences?
Developers describe GraphQL Cache as "A custom caching plugin for graphql-ruby". A custom middleware for graphql-ruby that handles key construction and cache reads/writes transparently. On the other hand, MobX is detailed as "Simple, scalable state management". MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). React and MobX together are a powerful combination. React renders the application state by providing mechanisms to translate it into a tree of renderable components. MobX provides the mechanism to store and update the application state that React then uses.
GraphQL Cache and MobX are primarily classified as "Cache" and "State Management Library" tools respectively.
GraphQL Cache and MobX are both open source tools. It seems that MobX with 20.1K GitHub stars and 1.22K forks on GitHub has more adoption than GraphQL Cache with 228 GitHub stars and 5 GitHub forks.
What is GraphQL Cache?
What is MobX?
Need advice about which tool to choose?Ask the StackShare community!
Why do developers choose GraphQL Cache?
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using GraphQL Cache?
Sign up to get full access to all the companiesMake informed product decisions
By switching our state management to MobX we removed approximately 40% of our boilerplate code and simplified our front-end development flow, which in the ends allowed us to focus more into product features rather than architectural choices.
Frontend choice was basically pre-ordained to be React. Seems like a strong choice on merits alone, plus I needed to learn it to stay current. I never liked Redux.js from the first time I tried to work with it, but a mate had recommended MobX and after watching a few videos I felt like I could fit the mental model of hit in my head. Using Material-UI which is a great timesaver and make sure I throw a few bucks their way every month via the open source collective.
Defaulted to Rails with PostgreSQL just because that's where my past strength as a dev had been. First prototype was in Go but was struggling a bit with the quality of libraries I needed so I went back to old faithful.
As soon as TypeScript was supported by default in Create React App I ported everything over. That combined with swagger code gen has given me really good type safety from the API boundary and above. I semi-regret the Go/Rails decision because I miss the type safety despite pain points with libraries.
I will probably look to flip back to Go gradually (probably via lambda) at a point where it makes sense for the business.