search

hasgeek / hasjob

Hasjob, the Hasgeek job board
https://hasjob.co
GNU Affero General Public License v3.0
240 stars 80 forks source link

Cache cards using local storage #56

Open jace opened 11 years ago

jace commented 11 years ago

In Hasjob's new avatar as a rich client app, job cards should be cached locally so that the server only needs to send the newest cards. Reloading the page takes way too long on mobile.

miteshashar commented 11 years ago

Not all browsers would support local storage.

jace commented 11 years ago

Seems to be universally supported: http://caniuse.com/namevalue-storage

shreyas-satish commented 8 years ago

As of https://github.com/hasgeek/hasjob/pull/251, we have switched to loading filtered views through AJAX (and pushState). But, we're still seeing performance issues: loading a filtered view can take anywhere between 800ms to 2s (or even higher on a slow internet connection). We should aim for sub-100ms responses from the server. So, it looks like we would have to test two approaches:

  1. Return only JSON from the server and measure how long it takes. If we do end up taking this approach, we would have to switch the rendering from Jinja to Ractive and integrate Node into our rendering pipeline to render views on the server-side.
  2. Cache the server-generated HTML and see if this improves response times. Basecamp took this approach and it seemed to work well for them. Also, Twitter, experienced significant performance improvements after moving their rendering from the client-side to the server-side.

Given that our use-case is rendering a fairly static section of the page (the list of stickies), my current sense is to go with approach 2. It keeps the architecture simpler (no need to integrate Node) and lets the server optimize the rendering (caching one user's response automatically benefits every other request).