Possible new feature: Caching remote responses

[Lance Java]

I was thinking about the possibility of DWR caching remote responses. In the case when a remote method is called with the same arguments twice or more, the second and subsequent invocations would not require a serverside call.

 

The config could be something like:

 

Remote.method(arg1, arg2, {

   callback: function(result) { ... },

   cache: true

};

 

When cache is true, DWR would store the results in a javascript variable and when it flags that the method / argument combo has been called before it will serve the content from the local cache instead of making a serverside call.

 

This opens a can of worms including flushing algorithms, max cache capacity etc. etc. etc. Perhaps there's an open source javascript caching library we could use?

 

I'd like to hear peoples thoughts.

 

Cheers,

Lance.

 

[Jose Noheda]

What's the benefit? I would say avoid the conversion but that's very little  for the amount of work required. I would say, leave it to the dev. He can decide if he needs to cache the method logic for some reason

Regards

On Fri, Jan 29, 2010 at 6:12 PM, Lance Java <[hidden email]> wrote:

I was thinking about the possibility of DWR caching remote responses. In the case when a remote method is called with the same arguments twice or more, the second and subsequent invocations would not require a serverside call.

 

The config could be something like:

 

Remote.method(arg1, arg2, {

   callback: function(result) { ... },

   cache: true

};

 

When cache is true, DWR would store the results in a javascript variable and when it flags that the method / argument combo has been called before it will serve the content from the local cache instead of making a serverside call.

 

This opens a can of worms including flushing algorithms, max cache capacity etc. etc. etc. Perhaps there's an open source javascript caching library we could use?

 

I'd like to hear peoples thoughts.

 

Cheers,

Lance.

 

[Frank W. Zammetti]

I personally like the idea A LOT.  I'm in charge of an amazingly complex app at work that in a sense houses a dozen or so other apps, and DWR is at the core.  Recently we've spent a ton of effort tuning performance and I could see where this could help.  I think there are definitely method that can be cached and that could only help performance.

I don't even think it needs to be too complex... Store the response as you said, and also store the date/time of the last request to the server and number of requests... Then give the developer the ability to configure (a) whether a method is cacheable and (b) whether it should refresh after x amount of time and/or number of requests.

So, maybe every 5 minutes the method invocation goes to the server... Or every 20th request goes to the server, all others get served from the local cache.

I'd guess that's how you planned it Lance, and if so count me as really liking the idea!

Frank

--
Frank W. Zammetti
Author of "Practical Ext JS Projects with Gears"
and "Practical Dojo Projects"
and "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects with Java Technology"
(For info: apress.com/book/search?searchterm=zammetti&act=search)
All you could possibly want is here: zammetti.com

---

Jose Noheda wrote:

What's the benefit? I would say avoid the conversion but that's very little  for the amount of work required. I would say, leave it to the dev. He can decide if he needs to cache the method logic for some reason

Regards

On Fri, Jan 29, 2010 at 6:12 PM, Lance Java <[hidden email]> wrote:

I was thinking about the possibility of DWR caching remote responses. In the case when a remote method is called with the same arguments twice or more, the second and subsequent invocations would not require a serverside call.

 

The config could be something like:

 

Remote.method(arg1, arg2, {

   callback: function(result) { ... },

   cache: true

};

 

When cache is true, DWR would store the results in a javascript variable and when it flags that the method / argument combo has been called before it will serve the content from the local cache instead of making a serverside call.

 

This opens a can of worms including flushing algorithms, max cache capacity etc. etc. etc. Perhaps there's an open source javascript caching library we could use?

 

I'd like to hear peoples thoughts.

 

Cheers,

Lance.

 

[Selim Ober-3]

I can't speculate on whether this is a good idea or not, but just to put my two cents in, if this's going to be implemented, I would like to have a server side method to invalidate a client side cache. In this case maybe some named cache.

Selim

On Sat, Jan 30, 2010 at 6:13 PM, Frank Zammetti <[hidden email]> wrote:

I personally like the idea A LOT.  I'm in charge of an amazingly complex app at work that in a sense houses a dozen or so other apps, and DWR is at the core.  Recently we've spent a ton of effort tuning performance and I could see where this could help.  I think there are definitely method that can be cached and that could only help performance.

I don't even think it needs to be too complex... Store the response as you said, and also store the date/time of the last request to the server and number of requests... Then give the developer the ability to configure (a) whether a method is cacheable and (b) whether it should refresh after x amount of time and/or number of requests.

So, maybe every 5 minutes the method invocation goes to the server... Or every 20th request goes to the server, all others get served from the local cache.

I'd guess that's how you planned it Lance, and if so count me as really liking the idea!

Frank

--
Frank W. Zammetti
Author of "Practical Ext JS Projects with Gears"
and "Practical Dojo Projects"
and "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects with Java Technology"
(For info: apress.com/book/search?searchterm=zammetti&act=search)
All you could possibly want is here: zammetti.com

---

Jose Noheda wrote:

What's the benefit? I would say avoid the conversion but that's very little  for the amount of work required. I would say, leave it to the dev. He can decide if he needs to cache the method logic for some reason

Regards

On Fri, Jan 29, 2010 at 6:12 PM, Lance Java <[hidden email]> wrote:

I was thinking about the possibility of DWR caching remote responses. In the case when a remote method is called with the same arguments twice or more, the second and subsequent invocations would not require a serverside call.

 

The config could be something like:

 

Remote.method(arg1, arg2, {

   callback: function(result) { ... },

   cache: true

};

 

When cache is true, DWR would store the results in a javascript variable and when it flags that the method / argument combo has been called before it will serve the content from the local cache instead of making a serverside call.

 

This opens a can of worms including flushing algorithms, max cache capacity etc. etc. etc. Perhaps there's an open source javascript caching library we could use?

 

I'd like to hear peoples thoughts.

 

Cheers,

Lance.

 

[Lance Java]

Jose... my proposal is to cache the results in javascript so as to avoid hits on the server. In the case of two dependent dropdowns (country and city). When the user chooses UK then USA then UK... only two getCity() serverside calls would be made instead of three.

 

Lance.

 

On 30 January 2010 13:51, Jose Noheda <[hidden email]> wrote:

What's the benefit? I would say avoid the conversion but that's very little  for the amount of work required. I would say, leave it to the dev. He can decide if he needs to cache the method logic for some reason

Regards

On Fri, Jan 29, 2010 at 6:12 PM, Lance Java <[hidden email]> wrote:

I was thinking about the possibility of DWR caching remote responses. In the case when a remote method is called with the same arguments twice or more, the second and subsequent invocations would not require a serverside call.

 

The config could be something like:

 

Remote.method(arg1, arg2, {

   callback: function(result) { ... },

   cache: true

};

 

When cache is true, DWR would store the results in a javascript variable and when it flags that the method / argument combo has been called before it will serve the content from the local cache instead of making a serverside call.

 

This opens a can of worms including flushing algorithms, max cache capacity etc. etc. etc. Perhaps there's an open source javascript caching library we could use?

 

I'd like to hear peoples thoughts.

 

Cheers,

Lance.

 

[Jitesh]

Did it finally happen?

No.

On Tue, Dec 13, 2011 at 1:02 PM, Jitesh <[hidden email]> wrote:

Did it finally happen?

--
View this message in context: http://dwr.2114559.n2.nabble.com/Possible-new-feature-Caching-remote-responses-tp4481162p7091229.html
Sent from the DWR - Users mailing list archive at Nabble.com.