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.
Hey, Just felt like my opinion could have sounded too strong. Just wanted clarify,
I’m coming from a strong Free Software/ Open source background. Having involved in developing communities from over 7 years by being Part of Free Software Movement Karnataka (FSMK) I’ve seen the challenges of adoption of open source softwares. Also the experience of being a core developer for Caddy and seeing it grow to over 6000 stars has given me a great experience on the challenges taking forward a open source software and what to expect from the community for wider adoption, professionally now being involved with bunch of free software hackers I share lot of love and passion towards a success of any open source technology.
Graphs and Distribute systems in general has always been my area of interest. And Now combining them with my strongest passion that is open source I’m excited about the project and I want Dgraph to get into hands of every application developer. I always found modelling on Graphs were more intuitive to design applications compared to table joins, I’m one of those few who always wondered why doesn’t the world give Graphs the respect and adoption it deserves. Neo4J was a disappointment. 2 years ago when I just started developing web applications I used Neo4J, I never wanted scale, but I was disappointed because It was not easy to build applications using any host languages. And Now I’m so happy that Dgraph is trying to do that, It was with this passion and intention I made my point. I want Dgraph to be very successful and willing to do my bit in contributing wherever I can
Agree with what @hackintoshrao is saying here. Simplifying the usage of Dgraph would help make adoption easier. We should identify what client side API’s would make this possible @hackintoshrao?
We are also trying to bundle the rocksdb dependency and that should help us take another step in this direction.
@pawan: With my experience of being part of building full fledged client libraries for Minio in Golang/Javascript/.NET/Python/Ruby/Rust/Java, I would like to share some of my experience.
Its easy to get started, design, implement and set a standard if the client library is first built in the language which everyone in the team are comfortable with and the server is written in. So in this case Golang client library could be a good choice to begin with. Because once a particular language driver is complete it’ll be relatively easier to then translate the logic into other languages.
Once Go driver is built, priority can be given to languages which are widely used on server side by backend developers. Python, NodeJS and Java are the most widely used to develop full stack web/mobile applications today. Later lesser popular (but still very relevant) languages like Ruby/PHP/.NET (They have huge adoption in enterprises) can be chosen.
