Honestly is may appear that some of the dev community has given up on GraphQL and just sticking to their RESTful APIs instead. Why is that? Because they don’t know about Dgraph’s Slash GraphQL!
I see the Google Trends and I expect a change in the near future as the word about Dgraph Spreads.
Why post this? Why take my time to even read that article? Because, the more people we can convert to Dgraph the better it will allow the developers to make it serving the rest of us better as well. Let’s get out there and when we see discussions about GraphQL do add in some info about Dgraph and Slash.
@zhenni Have there been any thoughts about doing a referral program for Slash? Even if it is just a small amount off our monthly costs for a paying referral or maybe even some extra transfer bandwidth allowance for that month. Word of mouth is the best kind of marketing especially from some of the trusted developers we have among our ranks.
I will cross post my comment below to add here some of my thoughts around the matter of decline and GraphQL.
I think it is just starting to get the correct kind of traffic and recognition in a way many haven’t realized yet. The problem with GraphQL up to this point has been solving the resolving to an underlying database storage. Most implementations either write their own resolvers or use services such as Hasura to generate these resolvers. If they go this route then the developer still has to add in their middle ware for authorization.
GraphQL does many things well:
No over-fetching
No under-fetching
Single Endpoint
Nested results allowing a single request and single response
Subscriptions
However great these points are though, they are only factually and effective if implemented in the resolvers. Most developers will still find themselves over-fetching and making multiple round trips to an underlying database to perform queries and mutations. And don’t even get me started on the N+1 problem that is a nightmare to resolve.
I was in this above crowd learning GraphQL and writing resolvers and had accumulated 60K lines of code not counting included packages or lock files. And that was just the backend, we had not even started to use it yet. Then I did the unthinkable and don’t regret it.—I deleted my entire GraphQL layer. Yes! I literally deleted all of that code and didn’t regret it. How…
We switched to Dgraph’s Slash GraphQL. It is a whole new take on GraphQL solving all of the above. GraphQL by Dgraph is no longer a layer on a database, but rather an endpoint on a database. Dgraph was built around GraphQL for the world’s first native GraphQL database.
But what about resolvers and middleware and tying together remote scripts and data sources? All a developer has to do is define the types of their schema with a few special directives to guide the GraphQL rewriters and Schema generation. Authentication is added dynamically by a developer writing a directive in the schema providing rules that are… GraphQL queries or RBAC functions on the type. The N+1 is non-existent. The over-fetching problem is gone. To tie into other remote scripts and data sources a developer adds the @custom directive and adds details to what is being fetched, how it is being fetched, and where it is being fetched from. To make this even better, Dgraph has developed a lambda directive that runs a lambda script using JavaScript like developers are accustomed to writing manual resolver for any special case needs such as transforming data to and from the database.
Before anyone gives up on GraphQL, go checkout slash.dgraph.io
Internally, there were discussions around this. We’d love for users to share Slash with their friends and colleagues and we’d like to reward their word-of-mouth. @gja what do you think?
@abhijit-kar That’s great to hear! If there are more requests from the community on this feature, we can definitely re-start the conversation internally and potentially add it to the road map for Slash.
If we roll out the features, we’ll ensure to have all the design assets ready for developers to integrate with their projects/website easily. cc our designer @tsu for this thread.
