[infinispan-dev] Infinispan Javascript client 0.1.0 is out now!

[Galder Zamarreño]

--
Galder Zamarreño
Infinispan, Red Hat

> On 19 Feb 2016, at 10:31, Radim Vansa <rvansa at redhat.com> wrote:
> 
> Just checked the readme, and TBH I wouldn't be too enthusiastic about 
> the deep nesting of chained operations (basically each follow-up 
> operation requires further level of nesting). Is that the way async 
> handlers are usually written in JS?

I think the README I've produce is a bit confusing, I'll work to improve for future versions. In the mean time, let me explain this:

The reason Promises are used instead of callback parameters is precisely to avoid this kind of deep nesting.

The code below shows 4 (but could be N really) operations which are chained only 2 levels deep:

connected.then(function(client) {
   ... <- Do something with the client
   var putCall = client.put('key', 'value');
   var getCall = putCall.then(function() {      
	return client.get('key');
   });
   var containsKeyCall = getCall.then(function() {      
	return client.containsKey('key');
   });
   var removeCall = containsKeyCall.then(function(contains) {
	return client.remove('key');
   })
});

The key aspect of this is that no matter how many operations you want to chain together, the nesting levels are constant. You could have 100 operations chained together, you would still only have 2 levels deep.

The README file might not make this so obvious and hence I'll work to improve on that.

Also, the API above is using Promise API which will be standard in ES6. Even though Infinispan JS Client is based on ES5, the `promise` module sticks to the forthcoming standard Promise API, and hence we're using something that in a few years will be standard, which is a good thing. Conceptually, Promise API is similar to Scala's Future or Java's CompletableFuture.

The other alternative that's used in Node.js is passing callbacks as parameters to each put/get call... and that does cause very deep nesting, because if you want to chain 100 operations together, you need 100 nested calls! Plus not centralised error handling, and many other disadvantages.

> 
> Last few weeks I am working with Gatling and the syntax to describe 
> scenarios = chained operations is quite nice (though it's Scala). Would 
> it be possible to have a syntax like this?
> 
> connected
>     .then(function(client) {
>         client.put('key', 'value');
>     .then(function(client) {
>         client.get('key').use(function(value) {
>             console.log(':get(`key`) = ' + value);
>         }).save('p0'); // this would be the same as use(function(value) 
> { client.save('p0') })
>     }.
>     .then(function(client)) {
>         client.remove('key', client.load('p0')).use(function(success) {
>             console.log(':remove(`key`) = ' + success);
>         });
>     }).exec();

Independent of the correctness of the syntax, this API can be split in several concepts:

1. The first one is that for those operations that have not a return, e.g. a put, you're passing on the client instance. I think that sounds fine.

2. For your API to work, get() would need to return something other than Promise that has a use/save methods. I'm very reluctant to do anything like that since it's not standard and would require more upfront understanding from the user. Right now, we provide a Promise, a concept that's very well understood in the JS community and that will become standard in ES6.

> Note that I've used conditional remove to demonstrate load of previously 
> saved value. Also, I am mixing the concept of client = cache and 
> session, but maybe these could go to single object.
> 
> Just my 2c
> 
> Radim
> 
> On 02/18/2016 12:04 PM, Galder Zamarreño wrote:
>> Hi,
>> 
>> Following on Tristan's anouncement, we've also released Infinispan Javascript client version 0.1.0. You can read all about it here:
>> http://blog.infinispan.org/2016/02/infinispan-javascript-client-010-is-out.html
>> 
>> Cheers,
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> 
> -- 
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev