First lets talk about their significance. A big step has to taken towards this direction.
- Unless application developers are enabled and their needs are catered it’ll be hard to see applications built using DGraph, If thats not made easy it’ll hurt the adoption severely.
- We gotto do the tough job behind the screens to make it really easy and intuitive for application developers across languages to be able to make use of DGraph. If not this will hinder enterprise adoption too. This is to be prioritized highly.
- Its important to be in the shoes of a programmer who has just learnt the primitives of a language and who doesn’t know anything about Graphs or Graph databases, If the client libraries are made so easy to use, the adoption will go a long way and will become a huge contributor towards achieving the the larger objective of enabling everyone with power of Graphs and making Graph Databases part of everyday application stack.
- Again, to get there easy to use and intuitive API’s has to designed and example apps has be published for each of the language drivers demonstrating the power and ease of Graphs in modelling an objective and also the ease of use of the client libraries. Easy to use language drivers also serve as evangelists for the server, it’ll attract the huge communities behind them to get introduced to the server. That’s when the role of ease of setting up the server and getting started kicks in, this could be a different thread of discussion on its own.
- Python, NodeJS, Ruby, PHP, Go, Java are the popular choices for building backend for full stack web/mobile applications. Its very important to enable all of them with really simple API’s to take the request and bring back the response from server. Utmost care has to be taken during design prioritizing their usability.