One of our partners asked this question the other day: “I had a customer demo and they asked me if form rules are server side JS or Client Side. I vaguely remember it to be Server side ? Is that correct? Are there any pro’s/con’s?”
The answer, as of now, is that they run server-side.
The main pros are:
- Browser independence. We found it impossible to get these to run reliably in so many versions of so many browsers, especially IE. A bug in your rule (e.g. an infinite loop) will crash the browser and in some cases will require a Windows reboot. On the server, these run in separate threads with lower priority and timeouts so it will not crash the frevvo server.
- The ability for the rule to do server-side things like http:get () to a database connector, invoke a REST service etc. These often reside behind the firewall and are not accessible to the browser.
- The rules are not exposed to the browser at all so any sensitive information in the rule (e.g. a password) won’t leave the server. However, we do not recommend putting any sensitive information in a rule.
- Rules can use information like the currently authenticated subject user id, name, email etc. though technically it would be possible to make this available on the browser if required. However, providing this information in the browser is a potential security hole.
- Rules can also modify a control – in theory, this can cause large-scale changes to the form’s valid state. Think of an optional XML complex type that has a deeply nested data structure inside it with some required and some optional elements. If any element has a value, all the other required elements become required. It’s much easier and efficient to analyze the form on the server although, technically, this is also possible in the browser. It can be extremely slow for large forms, especially in IE or if someone is running on a slower machine.
The main cons are:
- It makes offline use very difficult to implement. We are working on this. It’s not going to be in the next release (v5.1) but it is on the radar especially for tablets.
- Potential for performance bottlenecks. However, this is rare since rules are not compute intensive typically. We think the benefits outweigh the drawbacks here.
We’re working on a rule validator and a rule console to make it easier for customers to validate their script and easily view/fix any runtime errors while testing. More on this coming up.