Contribution

[f34nk]

Hey man,
actually I was thinking of the same idea :)

I've just worked on dgraph_ex and implemented support vor Dgraph v1. The issue is still pending. Also my upgrade attempt is still in progress.

I also took some time to check out bolt_sips for Neo4j.
I really like how this project is evolving. Instead of implementing a bunch of macros that implement a DSL like look and feel (that's what dgraph_ex is doing) they focus on performance first. All cypher is created as strings. So its the users choice how to create queries. Great examples: bolt_movies_elixir_phoenix and elixir_ravelry. Not to mention that you still can combine Ecto schemas with Non-Ecto dbs see this example: GoogleCloudPlatform demo

Also bolt_sips implements the db_connection database connection behavior. Which is the Ecto behavior.

I think this strategy is worth considering as a implementation roadmap.

• implement db_connection behavior
• implement db adapters so that the user can decide between html or gRPC connection
• string only queries (*)

What do you think?

Best, f34nk

(*) I have to admit that creating macros for Neo4j's cypher is much harder than creating macros for GraphQL+- which is the Dgraph flavor of GraphQL. So I am not at all against DSL. There should just be a way to submit string queries if the user wants to. IMHO DSL is syntactic sugar and not so important in the beginning.

[ospaarmann]

Hey,

thank you for your input. I think in general performance is more important than syntactic sugar. That is the reason why I went for the gRPC client in the first place.

I also think that clients for graph databases often make the mistake to try to copy Ecto and its DSL. But in many cases this is not fitting for graph dbs since the whole underlying concept is very different. My approach would be:

• Performance first
• Work as closely to GraphQL+ as possible
• Take the Go client for Dgraph as inspiration, not Ecto
• Keep it simple and allow a maximum of flexibility for the user while providing enough syntactic sugar to make it simple to use. Also for people new to Dgraph

Regarding your suggestions for the implementation roadmap:

• Implement db_connection behavior: Agree, especially since Dgraph supports transactions.
• Let users decide between html (sic) or gRPC: I think you mean raw http. I don't see the point here. gRPC is superior to http and there is no point for providing both imo. It just adds to the complexity of the project.
• String only queries: I have a strong feeling that there is something better possible here. Nested maps for a start. We otherwise torture users with string interpolation and unnecessary difficulties.

Looking forward to your reply.

Best, ole

[f34nk]

Agreed 💯
I will have time to look at the db_connection next week, probably.

[ospaarmann]

I have started to implement the DBConnection behaviour and will close this issue for now. Feel free to message me and discuss on how to work together on this.

Thanks!
Ole