Client-Side View Caching – Part 1

March 2nd, 2015

I’ve been building a web-app call Chordin for a while now. It’s a work in progress and it has been letting me scratch an itch that I have related to programming an isomorphic app. There’s plenty of Google juice on what an isomorphic app is (in case you don’t know) and how it differs from a single-page app. The main draw for me is to be able to serve fully-formed HTML from the server for performance and SEO, while retaining the speed and flexibility of client-side application logic (paraphrased from Airbnb’s article on the topic).

To start, I decided that I wouldn’t use any tools that are already out there, tools like Meteor.js, Node.js, React, Angular, etc. Yes, I am crazy, but my main goal was to force myself to learn concepts, not rely on tools. I wanted to experiment with my own theories, even if they might fail. In the end I hoped to have a better understanding of the problems that these various tools are trying to solve. I by no means know what I’m doing, I’m definitely in way over my head, but it has been a lot of fun throughout the process.

The speed of an isomorphic app was my main concern. I knew that Chordin would be used on all devices and various internet connections and therefore it needed to be fast. As I said above, I purposely limited myself to what I could use, but I also had my own limitations as to what I knew. On the server side I decided to use PHP (it’s what I know, don’t hate), Memcached (for caching SQL queries) and ElasticSearch (for near instant song searches of large amounts of database data). This server setup gave me all the speed for the requests being made.

On the client-side of things I rolled my own Javascript to handle view loading, caching and uncaching. The code interfaces with the server and has its own layer of view caching. I was most interested in solving client-side caching as it can provide some of the best results in speeding up a user experience. Another reason is that caching on the client-side is a very complex beast, and unless I’m mistaken, Javascript frameworks don’t address this particular issue. There’s a lot of room to explore viable solutions. Most solutions that I’ve seen try to make the client → server, server → client communication as fast as possible. But in the end, there is still an exchange taking place somewhere. The logical next step in my mind is to eliminate those exchanges all together.

In subsequent posts I plan on describing in more detail the ideas that I have implemented in Chordin, as well as more conceptual ideas I hope to implement. Stay tuned for more!