Slash GraphQL - a fully managed GraphQL backend service
GraphQL & Dgraph
One of those tools is Dgraph, which I mentioned in part three of my overview of GraphQL tools and libraries. It's the highest rated graph database on GitHub and has over a million pulls on Docker. I highlighted some of its advantages like horizontal scalability and ACID transactions, but obviously nothing is perfect and it had some drawbacks. It used its own query language, GraphQL +-, which as the name suggests, had some bits of GraphQL and didn't have some others. For example, it didn't work with GraphQL GUIs like GraphiQL or the Apollo React client.
Slash GraphQL enters the scene
Now the creators of Dgraph have launched Slash GraphQL, the first GraphQL-native database backend-as-a-service. Well, that was a bit of a word salad, let’s try and make it a bit less convoluted. To put it simpler, Slash GraphQL is a fully managed GraphQL backend service powered by Dgraph. Let’s take a look what that means:
It's GraphQL native - unlike other tools which run on top of another non-native database, Slash GraphQL has a GraphQL native database, which greatly impacts performance and scaling by handling GraphQL traversals, joins, and retrievals in the most optimal way possible.
It's compatible - another plus of it being native is that it takes full advantage of GraphQL. No more problems with React or GUIs, Slash GraphQL works with everything in the GraphQL ecosystem, you can even create your own instance with GraphQL.
It's really fast and simple - remember that obstacle I mentioned before? With Slash GraphQL it’s as simple as specifying the schema and pressing the deploy button. That’s how quickly and easily it will provide you with a production-ready backend for your app.
A different approach
The main draw here is the native GraphQL database. Other tools set up a GraphQL layer on top of an existing database which acts as a bottleneck in terms of performance, and scalability and creates compatibility issues. On top of that users need to make sure to set their tables correctly according to the underlying database before they begin working on a schema, which creates unnecessary hassle. Then with every change to the schema they have to again make changes to the underlying table, which depending on the structure can be quite complicated and time-consuming, ie. even more hassle. With Slash GraphQL you avoid all of that, all you need to work on is the schema and it will create backend for you with a simple click of a button.
Looking at GraphQL’s rising popularity it's hard not to see Slash GraphQL might be a game-changer for the GraphQL ecosystem and will be gaining popularity alongside it. As mentioned previously, it practically eliminates what most said is the biggest obstacle in getting into GraphQL, building and maintaining the backend. Simplifying the process really changes the learning curve, you don't need to write backend, know resolver patterns, or think about the tables and the database. All you need to know is GraphQL and you can get right to building your app. Looking at that 51% of devs who want to learn GraphQL, there's plenty of people who’ll do just that. Will Slash revolutionize the world of GraphQL? We need to wait a bit more to see.