Find out why every Firebase developer needs to checkout Slash GraphQL
TL;DR
Don’t wait for the nightmare of migrating away from Firebase one day when it doesn’t scale anymore for your application. Use Slash GraphQL — just work with GraphQL, no strings attached.
Okay, before I share my view on this, here is an honest disclosure — I work as a front-end engineer at Dgraph Labs but the view expressed in this article is totally personal and based on my own experience of building apps.
The Firebase Spark
No doubt that Firebase is great! I was an early adopter and have seen firebase evolving from a real-time database as a service to the popular app development ecosystem it is now.
Firebase is popular among developers because it’s very easy to onboard and integrate your app with its services. The developer doesn’t need to worry about setting up infrastructure & can iterate on the app faster than ever before. That’s what makes firebase so attractive amongst the app developer community.
GraphQL Explosion
GraphQL came into the picture recently & there is a lot of excitement in this space. I have written a case for GraphQL before as well. For the first time, a language is being conceived for APIs. That lead inception to a bunch of powerful tools & libraries for client applications that can talk GraphQL. Apolo client is definitely one of the most favorite open-source GraphQL libraries out there with more than 15k stars on GitHub.
But one thing which all frontend developers get frustrated with is— Resolvers
That's a big bummer. Nobody wants to write more code just to enable GraphQL.
Taking the leap forward
The good news is Slash GraphQL was launched recently this year. In a nutshell, it gives you a production-ready GraphQL hosted backend. All you need is to define a GraphQL schema and you get a /graphql endpoint like magic with no resolvers!
Now that’s super powerful, with a GraphQL backend you can not only query & mutate data but with GraphQL subscriptions, you can get real-time updates. Pretty much all the things that Firestore does.
So what's the deal-breaker?
Let's says you prototyped an app using Firebase. In the first 3 months of the application launch, the app got 5k users! Everything is great!
Until after 6 months, the traffic spiked by 500%. The load gets high and Firebase didn’t scale as you expected. You eventually decide to set up your own infrastructure & plan to architect services to solve your problem. But wait, what happens to all the nice firebase code that went into the app?
This is a nightmare for any engineer. Migrating away from a third party library is not the most exciting part of the job.
That's where Slash GraphQL trumps over firebase by making GraphQL the language to talk to the backend. No strings attached!
Imagine the same scenario now — you prototyped your app using Slash GraphQL, you used apollo client. And let's say one day you get adventurous & wish to set up your own infrastructure. No problem!
You can write your own GraphQL service, take the pain of writing resolvers, OR host Dgraph’s open-source GraphQL database for the same GraphQL schema you defined in Slash GraphQL.
This makes Slash GraphQL so interesting, with built-in auth & custom logic, Slash GraphQL is the fastest way to build apps.
Yes, there are a bunch of services out there that enable you to set up a GraphQL backend. To all which my answer is — The underlying database for Slash GraphQL is Dgraph which is open source & speaks GraphQL natively. No tables. No DB management. Only GraphQL. Why settle for a translation layer?
Give it a spin maybe? Literally, you can launch a backend in autopilot mode & experience the new way of building scalable apps.
