Serialization type Uint8/base64 as a DgraphClientStub() option

[pmualaba]

The dgraph-js documentation qoutes: "You will need to deserialize it before you can do anything useful with it."
Since we are completely in JavaScript land when using dgraph-js, we as node/js developers only deal with JavaScript objects. Why would we then still need to imperatively do the serialization and de-serialization (Uint8/base64/JSON) in our JavaScript code. This imperative repetitive task is a great opportunity to be handled completely by dgraph-js. Data fetching libraries like axios do the same thing: you give it a JavaScript Object (axios does the JSON.stringify internally) and it returns a JavaScript Object (axios does the JSON.parse internally). Suggestion: implementing serialization type Uint8/base64 as a DgraphClientStub() option? so that dgraph-js accepts plain JavaScript Objects and returns plain JavaScript object and does the correct serialization/de-serialization intenally based on the chosen DgraphClientStub() serialization option ('Uint8' or 'base64' ) so we "don't need to deserialize it before you can do anything useful with it." ;-)

[smkhalsa]

I was about to open this same issue. This is important.

[gpahal]

Currently, all the grpc types are auto-generated using protoc and that's why the interface is a bit complicated. To encapsulate the serialization/deserialization, we would have to create wrapper classes and keep the generated classes and the wrapper classes in sync.

I will have a look as to how we can implement this.

[gpahal]

I have published a new release (v1.0.1@next). It doesn't require serialization/deserialization!

Just use Mutation#setSetJson(jsonObject) or Mutation#setDeleteJson(jsonObject) on a mutation or Response#getJson() to get a json response from a query.

Please try the new release and report any bugs that you find.

[pmualaba]

Super, Big, Big Big thanks for this one! I'll try it out. :-)