Filed under: Performance Monitoring
Traversing a modern web site programmatically can be a tricky business. Gone are the days of static content, plain HTML forms, and simple web flows where one page transitions directly into the next.
It’s into these treacherous waters that AppView Web boldly wades, with the promise that it will reliably and consistently walk your site, producing a steady stream of synthetic traffic that can be meaningfully compared to snapshots taken days, weeks, or even months before.
Once a path is set up, the script had better not break unless something changes on the customer’s side.
However, to keep up with the rapidly changing face of modern web development, the back end needs to evolve constantly… and it has to do it in a way that has little to no impact on existing paths.
When AppView Web was first getting off the ground, we knew we had to provide API stability, to avoid frustrating customers. But at the same time the technologies we needed to drive the embedded headless-browsers on the appliances were still in their infancy.
There were some tough questions to be asked:
- how do we keep from breaking customer configurations every upgrade?
- how do we deal with constantly evolving technology on the back end?
- how can we release using early-access versions of key third-party software knowing breaking changes are only months away?
The answer, as it often is in software development, was an additional layer of abstraction.
Customers encountering AppView Web Scripting for the first time are often relieved to find what appears to be Selenium on the front end. There are a few small differences, but by and large the scripting language looks, feels, and operates in a way that is familiar to many web developers.
The few who dig deeper are generally surprised to find there is no selenium anywhere in the stack! AppView Web Script is actually a custom grammar developed in house to provide a stable front end for customer scripts to hide the fact the underlying engine has gone through two major overhauls, without breaking a single existing script or requiring a new version (so far all visible changes have been extensions).
The translation layer is the key to compatibility: the script the user writes is completely decoupled from the script that is published to the driver on the appliance. Although the driver software accepts scripts that are human readable, and that the developers expected to be end-user facing, we autogenerate them to ensure we always have control over changes to our exposed API, no matter what happens on the back end.
By rolling our own Antlr grammar, we can provide an interface that is very close to “Selenese” from the user’s perspective and can accept existing scripts with very little modification. At the same time we aren’t tied to any particular toolchain on our appliances, and can implement custom extensions as needed without having to fork thirdparty libraries.