coder . cl

Is well known the performance problem with Web Applications. The decision to leave all rendering to the server using the old fashioned server side page rendering, reduces the application throughput heavily. You can enhance the application throughput using some well known tricks to allow the server side application to be really faster than the old fashioned server side rendering application. The server load while you are using embedded code inside templates or similar stuff to render page displays, is heavier than using segmented loads.

We can follow simple rules to build faster Web Applications. We should be using an architecture that allows us to build scalable Web Applications, so is required to use the proper design patterns and architectural patterns. The classical one is MVC, but also you can use PAC as architectural patterns, which will allow you to setup a more abstract implementation of certain components.

If we use a plain Model as indicates the MVC pattern, we are creating a heavy couple with the storage. Instead, if we define the proper design patterns interfacing the Model and even our data storage interfaces, like Adapters, Façades and Delegates. Any direct access to data providing services, such as Models, Web Services, JSON Services, and related stuff should be abstracted, serving a plain DTO objects between your layers, even if it is n-tier or three-tier. With a well defined architecture, we can setup the proper server side cache for certain constructs, because it is easy to plug a third party interface between the data source and the data providing interface.

Data Services Abstraction

So, if we define an abstraction layer like this, we can create a cache interface inside the Adapter interface and under certain conditions, we can use that cache instead of using the data origin directly. For example for parametric tables on databases, where we have a small amount of data, like a table where we store the State, the Province or similar data, we can use a value-key data storage like Redis, and overloading the relational database with that small amount of data.

Cached Application

So, it’s simple to enable a conditions like the following code, but you must be careful on overarchitecting your application. The implementation should be lightweight, and not overloaded of design patterns:

cached_province = redis.get(str(province_id))
if cached_province == None:
    try:
        cached_province = Province.objects.get(pk = province_id)
        cached_province = self.to_dict(cached_province)
        redis.set(str(province_id), cached_province)
    except:
        cached_province = False
return cached_province

Other consideration is to have lightweight communications between the browser and the server load. For those pages using forms, and interactive data, which cannot be indexed by web robots, you can use JSON communications between your browser and your application. This will lead you to more lightweight HTTP requests and responses. Certain pages — specially those that shall not be indexed by web robots — should not be rendered using templates and similar stuff. You can leave that task to the browser, using a JavaScript/JSON template engine, like jQuery jTemplates plug-in. This allows you to omit template conditionals, template loading — which is done in memory — and probably will let you setup certain services based on those JSON rendered request responses.

For all data which is indexed by web robots, you can use templates and template cache. That do not requires too much processing if those contents are rendered for read-only purposes. If you are using a framework to work with templates, I am very sure that your framework is supporting server side cache for rendered templates.

Also, some technologies will allow you to create fancier web applications, like HTML5 and JavaScript frameworks, creating really dynamically driven applications with lightweight loads at the server side :)