All right, this example looks much better. And the ability to use native
variables rather than keys into the session is much more comfortable.
Thanks for the explanation!
Radim
On 02/19/2016 10:53 AM, Galder Zamarreño wrote:
--
Galder Zamarreño
Infinispan, Red Hat
> On 19 Feb 2016, at 10:31, Radim Vansa <rvansa(a)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-ou...
>>
>> Cheers,
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Radim Vansa <rvansa(a)redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev