It is possible to use writeback without Vizlib Server – referred to as “serverless” – for your applications, but the only recommended usage is during prototyping. Vizlib Writeback with Vizlib Server should be used for production for accurate, trustworthy data business-wide!
We’ll break down why we created Vizlib Writeback with a Server component.
It is almost impossible to provide a secure solution for writeback without a server component. Without a server, admins will have to give each user access to all data sources the app uses (including, but not exclusively the ones that will be written back to). With the addition of a server solution, all of the passwords, authentication, and access settings can be protected in the server, rather than having all of the sensitive information easily accessible to all users.
For example, if the app is protected with Section Access in a “serverless” solution, that security can be bypassed by any user as they have easy access to the data sources. Another example would be that of using a Representational state transfer (REST) API in a “serverless” environment, which would mean having the password in a plain text format in the Qlik object property panel – a massive security risk.
By using Vizlib Server, we can ensure that individual users use writeback in the most efficient way possible. With this solution, we can do things that may not be possible in other analytics solutions. For example, we could choose to only reload sections of the app when updating data instead of the entire app.
Flexibility & Maintainability
With Vizlib Server we can control access and destinations all in one place. This makes it possible to create complex solutions with different levels of access, combined with many different data sources. Vizlib Server allows an overview of all the settings for Collaboration (Writeback Table, Input Form, and Teamwork) and Finance Comments where we can control access to resources using Qlik Management Console (QMC) attributes.
Concurrency & Access
Qlik only allows one reload of a single app at a time. Allowing multiple users to use writeback at the same time requires additional features and resources. In Vizlib Writeback, we have the options of auto-locking, manual locking, and queued writebacks to better control multiple simultaneous users. With the use of dynamic paths and filenames, we can dynamically write to different destinations depending on the user – this helps to prevent file locking.
When running writeback without a server component, we chose to use a Session Application, which allows for good performance and reasonable security. It is used in simple cases where a proper security setup may be needed.
We do not recommend using any writeback solutions without a server component in production environments unless you are certain that you are in compliance with your company security policy and have properly understood the risks involved.
Do you want to try Vizlib Writeback for yourself?