Yes, we will definitely have a post about it. Probably on discuss.
1 Like
As I mention ^^ā the library is not ready for production yet which is sadly 
@pawan It has definitely been decided to use just Grcp to communicate with Dgraph? Just to be sure and begin to build something to Elixir ^^
1 Like
@WolfDan I think this library is worth looking into and bringing up to date with 0.9: GitHub - elbow-jason/dgraph_ex: A database wrapper and http client for dgraph
1 Like
Weāre planning to add HTTP endpoints to allow queries and separately, mutations. They wonāt be transactional in nature, but would at least give most of the current functionality.
2 Likes
Sure @sunny-g I already created a PR to improve a little bit the library ^^ still waiting to merge 
Thatās a great notice @mrjn ! This allow us to have more time to get done a more native solution with Grpc in Elixir
1 Like
@pawan is building the HTTP interface and looks like it would also allow transactions ā He can expand more when heās close to done on this thread.
3 Likes
Man you guys move fast. I admire what youāre able to do with a small team. Would be cool to hear your advice on building a small, high performance dev team if you guys feel you have taken any novel approaches worth calling out specifically.
Anyway, loving this constant stream of great features!
Thanks for the kind remarks! Iāll explain with an analogy, the centerpiece of our hiring strategy.
Thereās this particular strategy in Dominion, the popular board game. While the goal of the game is to have the highest valued deck, you trash out all the copper cards, as early as possible. Then, youāre able to draw more silvers and golds in every turn; which then lets you buy more powerful cards each turn and win the game swiftly.
The way I think about developers is the same. In an early stage startup, when you want to move fast and be thrifty, you should get rid of any engineer who is not able to get things done. This then leaves you with a few engineers who are solid performers ā which sets the stage for speed being a part of the culture of the team. The team members are then able to feed off each other and keep building the momentum.
Conversely, having a few slow engineers would cause an otherwise fast engineer to also take it slow; the weak-link in the chain. Additionally, there is a significant communication overhead per engineer, which also takes away from the speed of execution; so its very important to select then only keep strong performers.
Also, I believe strongly in the power of individuals. While teams are very important for projects, single developers have been the driving force behind the most important technical projects. So, giving big chunks of work to one dev is something we do naturally.
2 Likes
I have updated the original post. We will have full transaction support using http. We will put up the docs mentioning in detail how to use the new API to do transactions.
Quoting from the original post.
3 Likes
Thanks @mrjn, this makes sense and is helpful.
Couple more questions:
- Do you guys keep an official ācoding standards / guidelinesā doc, or is it informal?
- How aggressive are you about adopting new technology in the codebase where there is a new, demonstrably better solution, versus keeping the existing solution so as to not destabilize the existing code?
@mrjn are subscriptions still a part of the product roadmap? I could have sworn at some point in the recent past that subscriptions were slated for a v0.8 (or v0.8 maybe) release.
1 Like
Before v1.0 is released, weād go with the best solution to the problem, which sometimes means significantly modifying our APIs. You see that happening right now with transactions, etc.
After v1.0, weāll maintain the current branch, and if we have a much better solution, weāll just cut a new major release to avoid breaking changes.
We used to have a doc, itās still online somewhere. We have strict code reviews before anything gets submitted, and weāre constantly trying to refactor our code and simplify our solutions. Given weāre all sitting next to each other, we donāt feel the need to keep an up-to-date guidelines doc.
No one showed support for it, so we just delayed it. Once we cut v0.9, we could build it, so it would be there in v0.9.x. Iāll tag it as such.
3 Likes
No one showed support for it, so we just delayed it. Once we cut v0.9, we could build it, so it would be there in v0.9.x. Iāll tag it as such.
@mrjn Please do, you have a +1 from me! Real-time GraphQL queries on a distributed graph database is too enticing to ignore 
5 Likes
Yes agree, subscriptions would be an awesome feature! It was the main selling point for Rethink DB and it got a lot of traction because of it (notwithstanding the ultimate outcome of Rethinkā¦).
4 Likes
Embedded Dgraph goes away
We havenāt seen much usage of this feature. And it adds unnecessary maintenance overhead to the code. If there are clear reasons for its benefits, let us know (Remove support for embedded dgraph (and client_test) by peterstace Ā· Pull Request #1734 Ā· dgraph-io/dgraph Ā· GitHub).
Iām not using it.
In the upcoming release, will unique indexes be included as part of transactions, or will we still need to manage that outside of Dgraph?
Also, Iām looking to go live with a new app shortly, but it seems like 0.9 will be a fairly major change, so might be worth waiting. Any updated view on when it might be available (no worries if not)?
Had to be away for a few days as moving to a new country but guys, Iāve never been so happy to see a feature back. These HTTP endpoints mean the world to me, ha! Will look at how to implement upserting with these as soon as I can get back on my code.
Thank you again, you guys really rock.
3 Likes
@calummoore, we expect to release v0.9 today, so not long to wait now
3 Likes
Iām not sure what you mean by unique indexes. So, my guess is that youāre asking about enforcing single edge nodes? Thatās not built yet.
With v0.9, we really want to push v1.0 out the door, so depending on how well it goes, we might release v1.0 in a month or so, and push all feature requests to after v1.0 release.
Iām really glad that you liked it. You can thank @pawan who found a good way to integrate transaction metadata into the HTTP endpoints .
Struggling to get a mutation to work in 0.9 using HTTP, I have a feeling that everything is going into a transaction (which I may have inadvertently created when I first started a server), but Iāve restarted the server and dropped the DB so I would be surprised if the transaction is still open.
-
Start with a clean build (not attaching a data volume in case that leaves something behind)
docker rm diggy
ā¦
docker run -it -p 8080:8080 -p 9080:9080 --name diggy dgraph/dgraph dgraph zero --port_offset -2000
ā¦
docker exec -it diggy dgraph server --memory_mb 2048 --zero localhost:5080
ā¦
localhost:8080/alter -> {"drop_all": true} -
Add a schema
localhost:8080/alter -> name: string @index(term) . -
Add Bob and Alice
localhost:8080/mutate
{
set {
<_:bob> <name> "Bob" .
<_:bob> <balance> "70" .
<_:alice> <name> "Alice" .
<_:alice> <balance> "100" .
}
}
{
"data": {
"code": "Success",
"message": "Done",
"uids": {
"alice": "0x2",
"bob": "0x1"
}
},
"extensions": {
"txn": {
"start_ts": 2,
"keys": [
"AAAHYmFsYW5jZQAAAAAAAAAAAg==",
"AAAHYmFsYW5jZQAAAAAAAAAAAQ==",
"AAAEbmFtZQAAAAAAAAAAAg==",
"AAAEbmFtZQAAAAAAAAAAAQ==",
"AAAEbmFtZQIBYWxpY2U=",
"AAAEbmFtZQIBYm9i",
"AAALX3ByZWRpY2F0ZV8AAAAAAAAAAAI=",
"AAALX3ByZWRpY2F0ZV8AAAAAAAAAAAI=",
"AAALX3ByZWRpY2F0ZV8AAAAAAAAAAAE=",
"AAALX3ByZWRpY2F0ZV8AAAAAAAAAAAE="
],
"lin_read": {
"ids": {
"1": 11
}
}
}
}
}
- Query for bob and alice (seems like the mutation hasnāt been committedā¦)?
{
balances(func: allofterms(name@en, "Alice")) {
uid
name
balance
}
}
{
"data": {
"balances": []
},
"extensions": {
"server_latency": {
"parsing_ns": 21874,
"processing_ns": 193677,
"encoding_ns": 1124903
},
"txn": {
"start_ts": 3,
"lin_read": {
"ids": {
"1": 13
}
}
}
}
}
Iāve not sent any headers on any of this.