Alternatives to GraphQL Cache logo

Alternatives to GraphQL Cache

GraphQL, MobX, and Ehcache are the most popular alternatives and competitors to GraphQL Cache.
24
35
+ 1
0

What is GraphQL Cache and what are its top alternatives?

A custom middleware for graphql-ruby that handles key construction and cache reads/writes transparently.
GraphQL Cache is a tool in the Cache category of a tech stack.
GraphQL Cache is an open source tool with 325 GitHub stars and 24 GitHub forks. Here’s a link to GraphQL Cache's open source repository on GitHub

Top Alternatives to GraphQL Cache

  • GraphQL

    GraphQL

    GraphQL is a data query language and runtime designed and used at Facebook to request and deliver data to mobile and web apps since 2012. ...

  • MobX

    MobX

    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. ...

  • Ehcache

    Ehcache

    Ehcache is an open source, standards-based cache for boosting performance, offloading your database, and simplifying scalability. It's the most widely-used Java-based cache because it's robust, proven, and full-featured. Ehcache scales from in-process, with one or more nodes, all the way to mixed in-process/out-of-process configurations with terabyte-sized caches. ...

GraphQL Cache alternatives & related posts

GraphQL logo

GraphQL

22.7K
18.4K
292
A data query language and runtime
22.7K
18.4K
+ 1
292
PROS OF GRAPHQL
  • 69
    Schemas defined by the requests made by the user
  • 62
    Will replace RESTful interfaces
  • 59
    The future of API's
  • 47
    The future of databases
  • 12
    Self-documenting
  • 11
    Get many resources in a single request
  • 5
    Ask for what you need, get exactly that
  • 4
    Query Language
  • 3
    Evolve your API without versions
  • 3
    Fetch different resources in one request
  • 3
    Type system
  • 2
    GraphiQL
  • 2
    Ease of client creation
  • 2
    Easy setup
  • 1
    Good for apps that query at build time. (SSR/Gatsby)
  • 1
    Backed by Facebook
  • 1
    Easy to learn
  • 1
    "Open" document
  • 1
    Better versioning
  • 1
    Standard
  • 1
    1. Describe your data
  • 1
    Fast prototyping
CONS OF GRAPHQL
  • 3
    Hard to migrate from GraphQL to another technology
  • 3
    More code to type.
  • 1
    Works just like any other API at runtime
  • 1
    Takes longer to build compared to schemaless.

related GraphQL posts

Shared insights
on
Node.jsNode.jsGraphQLGraphQLMongoDBMongoDB

I just finished the very first version of my new hobby project: #MovieGeeks. It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. This is just the beginning as I am planning to add more features on the lines of sharing and discovery

For the #BackEnd I decided to use Node.js , GraphQL and MongoDB:

  1. Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have

  2. GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach. I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger.

  3. MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website

See more
Nick Rockwell
SVP, Engineering at Fastly · | 44 upvotes · 1.7M views

When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?

So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.

React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.

Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.

See more
MobX logo

MobX

573
449
114
Simple, scalable state management
573
449
+ 1
114
PROS OF MOBX
  • 26
    It's just stupidly simple, yet so magical
  • 18
    Easier and cleaner than Redux
  • 15
    Fast
  • 13
    Automagic updates
  • 13
    React integration
  • 10
    Computed properties
  • 8
    ES6 observers and obversables
  • 7
    Global stores
  • 3
    Flexible architecture the requeriment
  • 1
    Has own router package (mobx-router)
CONS OF MOBX
  • 1
    Maturity

related MobX posts

Dan Robinson

The front end for Heap begun to grow unwieldy. The original jQuery pieces became difficult to maintain and scale, and a decision was made to introduce Backbone.js, Marionette, and TypeScript. Ultimately this ended up being a “detour” in the search for a scalable and maintainable front-end solution. The system did allow for developers to reuse components efficiently, but adding features was a difficult process, and it eventually became a bottleneck in advancing the product.

Today, the Heap product consists primarily of a customer-facing dashboard powered by React, MobX, and TypeScript on the front end. We wrote our migration to React and MobX in detail last year here.

#JavascriptUiLibraries #Libraries #JavascriptMvcFrameworks #TemplatingLanguagesExtensions

See more

We started rebuilding our dashboard components using React from AngularJS over 3 years ago and, in order to have predictable client-side state management we introduced Redux.js inside our stack because of the popularity it gained inside the JavaScript community; that said, the number of lines of codes needed to implement even the simplest form was unnecessarily high, from a simple form to a more complex component like our team management page.

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.

See more
Ehcache logo

Ehcache

102
124
4
Java's Most Widely-Used Cache
102
124
+ 1
4
PROS OF EHCACHE
  • 1
    Way Faster than Redis and Elasticache Redis
  • 1
    Easy setup
  • 1
    Simpler to run in testing environment
  • 1
    Container doesn't have to be running for local tests
CONS OF EHCACHE
    Be the first to leave a con

    related Ehcache posts