0

Currently working on a web application. One particular area/page of this application performs certain time taking DB operations. The current structure of this page is:

1) DWR call from the front end to the backend
2) Front end waits for the backend to return data
3) When data is returned, the callback function is executed in the 
   front end and data is displayed to user in the format needed.

During step #2, backend takes a lot of time to process and send data back. During this entire time, the application is unusable.

The change that should be made is:

1) Let the user use the application after sending the request in step #1
2) Front end will be populated with data after the backend processes the data and 
   send the details back.
3) When user revisits the page, information from previous request is available.

I am looking for ways to make this possible. Not sure if there is a DWR or Spring mechanism to achieve this. Please point me in the right direction so that I can research more for the correct code needed.

user811433
  • 3,999
  • 13
  • 53
  • 76

1 Answers1

0

The main question is - what technology you're using for the pages, and how much of a "wait" is required.

  1. Easiest case is if the browser can keep an open connection during the wait: this happens when the wait isn't too long, and the user remains on the same page. In that case, the server exposes REST while being oblivious to who's consuming it. Most of the work would be on the client side which needs to perform asynchronous ajax - if it's DWR see here , if it's spring then it doesn't meddle on the client side and you can use any javascript helpers you like, e.g. JQuery

  2. It becomes more complicated if the wait is long, or if the user should receive a 'push' notification even if he navigated to another page in the meanwhile. In that case I'd suggest looking into websockets or server-sent events , or long-polling mechanisms (google it - there are lots of examples and products, some free, some costly). Anyway, be prepared for some learning curve here.

  3. As to requirements 3 (speedy way to see the data when re-visiting the page), I don't have any magic solutions, just good old caching... your cache could be located on various locations - from client to server through some caching proxy in the middle. Obviously one needs to consider the cache refreshing policy - easiest case being if you can live with the same data "for X minutes/hours", complex case being if you need to refresh on specific business actions.

Community
  • 1
  • 1
Pelit Mamani
  • 2,321
  • 2
  • 13
  • 11