Dgraph team is super excited to present v0.7.1 of Dgraph . This version is the biggest step we've taken towards our production aim of v1.0. We've implemented 90% of all the features we had planned in our product roadmap, including replication and high-availability using RAFT protocol, indexing, filtering, sorting, geospatial queries, and backups.
Ever faced the problem of having multiple ports in an application, one for each service? In this post, I'm going to brief about how to run multiple services via the same listener port.
When I started building the initial version of the Dgraph Go client, we were looking for a serialization format which was fast, easy to use and supported multiple language runtimes. We finally implemented our client using Protocol Buffers which gave twice the speed and consumed two-third memory compared to JSON according to our benchmarks.
4 out of 5 interviewers had liked the candidate. I was one of the 4. He had received either above or very close to 3.0, which is a good score. The interviewer who didn't like the candidate had been at Google since early 2004. And he didn't like the candidate's joke question about whether he was very rich because he joined before Google went IPO. I guess he wasn't.
At Dgraph , we aim to build a low latency, distributed graph database. This means our data is distributed among nodes in the cluster. Executing a query means multiple nodes are communicating with each other. To keep our latency of communication low, we use a new form of serialization library called Flatbuffers.