For me, Qlik is all about the engine. What you can do with this beautiful piece of engineering is just astounding. Yes, building engaging and useful visualizations is ultimately what users need, but to me, those are just the blossom on the tree. They are seasonal and change with the wind. It is the roots, trunk, and branches that provide all the strength, power, and capabilities. A leafless tree in winter is as strong as in every other season, but – to me – even more gorgeous.
Build the data model and expressions right, and with minimal ongoing effort, your application will grow with your needs without buckling under increased load. Shortcut this stage in development, and it won’t be long before the fragile trunk of your application becomes exposed for what it is – hollow and weak. Do it right the first time. Yes, it takes longer to build an application correctly, but we all should take a level of pride in our work that goes beyond throwing a working model out there quickly. The reality is, when dealing with approximately a million rows of data, you can build a terrible model, and it will still perform very fast. Not good enough! If it works well, usage will spread. What happens when your client/employer wants to triple the data and quadruple the users? Just about anyone can smash together a proof of concept, but when building for a production environment, you should allow time in your estimations to do it right.
In its very first version, Qlik Sense introduced the new Qlik engine, referred to as QIX. The name QIX means Qlik IndeXing, a new name given to the engine with the birth of Qlik Sense.
Granted, the clear majority of my Qlik experience has been in large enterprises, so this is a complete necessity if I am to truly succeed for my clients. However, even if your application will only ever be used by ten people, please consider using these best practices. Be proud of your work. The engine will open doors to possibilities you never knew existed.
OK, that’s quite enough hyperbole. On to the substance.
Allow me to describe what I mean by best practices.
For me, best practices are a set of principles to employ in application development. Principles are not hard and fast rules. They should be adopted to appropriate degrees and adapted for your particular way of working and requirements. I have written them here as I use them – I always employ these practices, and they have served me well, so I encourage you to do the same. Many of these approaches were worked out by myself through a steep learning curve, only to find that they were already a thing. I’ll present my flavors here but will refer to other, more well-known documents where I know of them.