This memo is a public version (with slight edits) of an internal memo which was circulated among Dgraph employees a while back.
TL;DR: The service is now launched as https://dgraph.io/slash-graphql . If you’re interested, add yourself to the waitlist and we’ll get back to you within an hour.
To Dgraph team,
We’re working on building and launching a GraphQL cloud service, named Slash GraphQL.
What is Slash GraphQL?
Slash GraphQL is a managed GraphQL cloud service, run by us (Dgraph Labs), using Dgraph to store and serve the data. As suggested by the name, it uses GraphQL API for all interaction.
The name derives from the fact that we provide /graphql as the home endpoint for developers’ application data on the internet.
Why are we building Slash GraphQL?
We believe that the way developers build backends is fundamentally complicated. We believe that backends should enable application development, not hinder it.
We believe in speed, iteration and evolution. Data models today are none of those. We set out to create a technology which can simplify data models and enable a fast evolving product.
We believe in clean, lean codebases. We think with the right technology, most codebases can be cut down significantly. We believe in providing incredible developer experience and enable them in providing an exceptional user experience. We believe in fast, real-time applications. We want to enable developers in building smarter applications.
Dgraph is unique in that it is the only native GraphQL database. It does not run on top of another database like PostgreSQL or MongoDB. We have designed a database which stores and distributes the data in a way most optimal for executing GraphQL traversals, joins and retrievals. On top of that, Dgraph natively parses and executes a GraphQL query to achieve great performance and scale.
Slash GraphQL makes that technology accessible to any developer, frontend or backend. They don’t need to know about how to set up a cluster, how to run k8s, how many machines they need, or how much RAM / disk space they require.
With Slash GraphQL, they click a button and are presented with /graphql endpoint. They can set their schema and immediately start to query and mutate data into the backend, without any coding required, whatsoever.
How is this different from alternatives?
None of the alternatives provide such an easy, simple experience. Largely because they did not build an entire database for GraphQL. They built a GraphQL layer on top of an existing database. So, their users need to set up the tables correctly in their underlying databases first, before they can then set up the GraphQL schema.
Moreover, if the GraphQL schema needs a change, they must first change the underlying table structures – which depending upon the relationships involved, can be hard and require migrations.
Slash GraphQL allows a user to solely operate on their GraphQL schemas and know nothing else about their database. Not only that, they are not giving up on speed, peformance and scalability. That’s incredibly powerful. We are creating the most amazing development experience for a GraphQL user.
Where does Slash GraphQL exceed its competitors?
- Zero learning curve. Because all you need to know is GraphQL (and nothing else) to start building your app. Slash GraphQL provides pure GraphQL experience.
Slash GraphQL in fact can be a great way for new developers to learn about GraphQL. We can provide training clusters, which automatically shut down after a week, and do not require any sort of commitment from the users.
-
Iterative. They need to change the data type of a field? They need to make a single object a list? They need a new index for full-text search? No problem. Slash GraphQL will take care of all that, on the fly, without any downtime.
-
Horizontally Scalable. Slash GraphQL benefits from all the effort we have put into building Dgraph. We built a great DB which can scale and perform well first, then exposed GraphQL. And that means it works well for a one-person project, and it works well for a Google-scale project.
-
Fast. The internal workings of how Dgraph is designed make it really fast for queries of any depth.
-
Zero management required. Don’t make a developer think. They need to build the next Instagram, Pinterest, Airbnb, Dropbox.
Why should a GraphQL developer care?
Because they don’t want to write a GraphQL backend. They don’t want to learn about resolver patterns and deal with N+1 problem. They want to run whatever queries come to mind – complex, multi-hop, deep queries – unmarred by performance issues.
They don’t want to think about the database and how it works with GraphQL. And how GraphQL scales.
They just want to use GraphQL to build their apps. And it better be fast. And it better keep working when their data size increases, or their query volume increases. Or when they get on the front page of Hacker News.
Slash GraphQL gives them just that: /graphql. Easy to use, Fast, Scalable. In seconds, not days or months. It would almost feel like they cheated.
Bigger Narrative
Developers are learning about GraphQL. They are realizing the power of storing and accessing their data as a graph, with first class support for interlinking and relationships. They are drawn to the ease of use and rapid iteration provided by the language.
For the first time, the frontend controls the conversation. It can ask the backend for as much or as little data that it needs.
We are building Slash GraphQL because we want to make it so easy for developers to use GraphQL, that in a year, they would wonder why they were spending effort trying to write their own GraphQL system.
Building a performant and scalable graph system is a hard problem. We at Dgraph know that better than anyone else. The GraphQL community might not realize that they are in the business of servicing graphs now, but they get to know it when they start to hit performance issues with their favorite GraphQL backend. They could be running it on their favorite flavor of SQL database, but they are no longer servicing flat data.
How would we charge our users?
We don’t want our users to have to think about machines, RAM, disk, network, cluster. They should just care about one thing: /graphql. And it is OUR job to ensure that Slash GraphQL runs fast 24x7. That means, we aim for zero downtime.
This leads me to believe that charging users by queries performed is the only way to achieve that goal. The more they use, the more they get charged. The less they use, the less they get charged.
There is one caveat. In a typical NoSQL DB, there is a linear match between number of keys accessed and queries. Graph queries don’t work like that. They can access lots of data and execute a lot of operations to run just a single query. A single lookup query cannot cost the same as a query which access millions of records. Therefore, our pricing should be aligned with the cost of running this query.
We introduce an idea of query cost. We can keep track of how many records were accessed or operations performed, run them by a log scale, and come up with a query cost in integers (not float, to keep things simple). Over time, we will iterate over the query cost to determine their actual dollar value. But, the messaging around the pricing should be consistent and aligned with query cost.
Where do we want to be?
One year from now, Slash GraphQL should become the default way to learn GraphQL and launch GraphQL services. It should be used by devs new to GraphQL, devs who want to build GraphQL apps, and devs in big companies who need a GraphQL service which scales.
The name of Slash GraphQL should be known by every GraphQL user. Big companies should be using Slash GraphQL and so should startups.
Slash GraphQL is our gift to the GraphQL community. GraphQL is a great query language. And we are making it possible for any developer to build GraphQL applications easily and quickly.
– Manish
Founder/CEO
Dgraph Labs, Inc.
P.S. This is now launched as https://dgraph.io/slash-graphql .
