Node client for RavenDb

[Wayne Douglas]

I can See this being a seriously cool feature

Anyone up for getting on board?

I'm nowhere near good enough at Node, JS or Ravens REST API to tackle
this on my own :)

--
Cheers,

w://

[Itamar Syn-Hershko]

We will be glad to assist should you need any help

I'll prioritize docs for the HTTP API so you have more to go on...

[Chris Sainty]

More REST docs would be nice, it is not too difficult to watch the
console window or fiddler to see what is going on, but can be slow.

I whipped up a quick proof of concept node module this morning that
can query an index.
It was easy enough to get going, grabbing a dependency on the request
module helps.

I think the most difficult step would be defining a good API, there
are a lot of decisions to be made there around whether you try match
the C# implementation, or go your own way and build something that
makes sense for javascript.

On Dec 4, 7:16 am, Itamar Syn-Hershko <ita...@hibernatingrhinos.com>
wrote:

> We will be glad to assist should you need any help
>
> I'll prioritize docs for the HTTP API so you have more to go on...
>
> On Fri, Dec 2, 2011 at 12:15 PM, Wayne Douglas

> <codingvi...@googlemail.com>wrote:

>
>
>
> > I can See this being a seriously cool feature
>
> > Anyone up for getting on board?
>
> > I'm nowhere near good enough at Node, JS or Ravens REST API to tackle
> > this on my own :)
>
> > --
> > Cheers,
>

> > w://- Hide quoted text -
>
> - Show quoted text -

[Matt Warren]

I think the most difficult step would be defining a good API, there
are a lot of decisions to be made there around whether you try match
the C# implementation, or go your own way and build something that
makes sense for javascript.

I agree, a lot of work has gone into the RavenDB C# client so that you can just write LINQ statements. I'm not sure how this would map into JavaScript, maybe some type of fluent api? Also creating indexes will be clunky, because you have to use javascript to create a C# LINQ statement.

I thing the nicest approach would be to have an API that makes sense in javascript, i.e. not just a converted version of the C# api. But I also think that this will be harder.

[Chris Sainty]

Put my little test project up on Github.

https://github.com/csainty/node-raven

 

It currently does almost nothing useful of course, but it has the appropriate node structure and test harness in place.

The readme file explains what is going on, also look at the test.cmd file which you can run to fire off the tests and the test/client.test.js file which shows how to use the thing.

 

It's a big job to take this all the way through to a full featured client, but getting some basic query, read, write scenarios going shouldn't be too difficult.

 

I'll keep fiddling with bits and pieces as it is a good excuse to learn the insides of raven and javascript-sans-jquery better.

[Oren Eini (Ayende Rahien)]

Some comments:

Client.prototype.getDatabaseNames = function(callback) {



	var self = this;



	request(self.constructQuery('/databases'), function(error, response, body){



		callback(JSON.parse(body));



	});


}

This loses the error handling. You should make sure that debugging the client isn't a pure PITA, and losing the error handling like that would do that.


For that matter, you need to handle error handling for the scenario where you can't parse the json, etc.

[Chris Sainty]

Yeah error handling is not touched yet. I did just enough to let me get the whole testing and development process up. First time writing a node module.

 

I need to do some more reading on appropriate error handling techniques in javascript.

For example is it better to throw and assume the caller is catching everything, or build the error conditions into the response object so the users callback is always called and they put their handling into the callback.

[Oren Eini (Ayende Rahien)]

In callback style, you need to pass the errors to the callback.

[Chris Sainty]

Cool, that was the way I was leaning.

 

I am going to encapsulate the request/response process into it's own layer that can handle things like auth, caching, redirects etc and passes back response/error information and the materialised json body. To aid with debugging, some proxying support would be needed here as well, to get it to run through fiddler.

 

Putting all that code together, the client layer can focus on wrapping all that into a nice API and probably intercept and interpret some of the errors with a little more context.

 

I'll make my next focus getting those sorts of basics in place in a wrapper that is of meaningful quality.

[Chris Sainty]

Got a little more time this evening to take another look and have pushed an update.

https://github.com/csainty/node-raven

 

The http traffic has all been put into a raven wrapper around the request module. As discussed before this is where auth/cache etc can be tacked on. In theory without affecting much else in the api except where control hooks are needed.

The request library ships with oAuth support, windows auth might be a little more work, though since node can call out to C libraries, there is bound to be something around.

 

The client.js class is still supposed to be a low level interaction with the server, with a pretty raw api.

 

I would envisage that fluent api wrappers would be created on top of the client which would form the regular api someone would call. I wouldn't head too far down this path just yet, other than perhaps a proof of concept to validate the idea. Querying being the prime candidate.

 

Query API currently looks roughly like this

 

var db = require('node-raven')('http://localhost:8080');

db.queryIndex('Artists', { 'Name' : 'AC/DC' }, function (result,  data) {

  if (result.error || !data) {

    // Somthing went wrong. See result.httpResponse, result.statusCode or result.content

    return;

  }

  console.log(data.TotalResults); // 1

  console.log(data.Results[0].Name); // AC/DC

});