I've used both Graph.Cool and Firebase. Guess what? They're both great products.
Firebase is a noSQL backend-as-a-service (BAAS). The value proposition of Firebase is that during app development you can plug in Firebase and forget about back-end development.
Here's how you might query your Firebase database to get a user's information:
const admin = require('firebase-admin')
const getUserData(uid) => admin.database()
.ref(users/${uid})
.once('value')
.then(snap => snap.val()Then you'd call getUserData(uid), supplying the user's id as an argument.
My personal opinion is that Firebase is perfect for prototyping but at scale can become prohibitively expensive.
I'm a little biased toward Graph.Cool because it compliments React nicely.
Firebase is better than Graph.Cool for prototyping because real-time, and authorization come baked in. With GraphQL, you need to integrate with Auth0 and setup subscriptions. The upside is that you have more control with Graph.Cool and performance is better.
Firebase was launched in April 2012, so it's been around for a while. It was acquired by Google in 2014, and isn't going anywhere anytime soon.
Adding Firebase to your app solves three big obstacles in one swoop:
Adding Firebase to a single-page application (SPA) built with React or Angular is straightforward and well-documented.
Firebase supports web sockets, which allows your up to be updated in real time. For example, if you're using React you can just import react-fire and use the syntax firebase.database().ref().on("value").
Graph.Cool is a GraphQL backend for your app. If you're not familiar with GraphQL, it was developed by Facebook to compliment React.
GraphQL solves the problem of nested requests. Let's say you want to display a user's posts in their profile. To get this information, you'd need to issue a get request to /user/{userId} which might return:
{
name: 'Steve',
email: 'steve@apple.com',
uid: 'xxx',
posts: [
'cj5b5nwzl2le601842h3nctbl',
'cj5b5ns2s2lcm01846f4fbmtj'
]
}Then, to get Steve's posts, you'd need to make a request to /posts/{postId}.
The point is you might end up making 3-5 GET requests to get the data that your component needs. This is especially true if groups are highly interrelated.
With GraphQL, you explicitly state your components data requirements. But you leave the rest to GraphQL to reconcile all the requests and bundle them together. With GraphQL, the syntax looks like:
In short, GraphQL really shines with nested queries.
New and shiny.
Less vendor lock-in. If Graph.Cool goes defunct, you can set up your own GraphQL server to use as a backend without reworking front-end code.
Supports both Apollo (simply) and Relay.
Works great with React (Apollo and Relay are kind of like a Redux store connected right to the server).
New and shiny.
More difficult to integrate than Firebase.