PerfectForms Geek - Architecture

PerfectForms Architecture

This is not intended to be a detailed architectural document but it should give some interesting insights into important parts of the PerfectForms system.

There were many architectural objectives when designing PerfectForms but the following ones were at the top of the list

Performance
Scalability
User-Friendliness

A great deal of thought and several proof-of-concepts were built before we ever wrote a line of production code. PerfectForms had to meet the following goals

Be truly multi-tenant
Support an unlimited number of users
Very low response times
Provide near real-time reporting without any performance impact on the core system

Keys to Performance : Flex

PerfectForms has a beautiful user interface which is almost as responsive as a desktop application. PerfectForms is a Flex application which means that the majority of processing is done on the user's browser and not the server. In most cases, the PerfectForms web servers receive a simple request, get Form XML or Form Data XML from a single database field and pass it out to the browser. That results in very little load on the server. The PerfectForms application gets the XML, decrypts it and renders it without any assistance from the main servers.

A major advantage of our approach is that when a user moves between screens when building forms or filling them in, there is minimal or no interaction required with the server except as actual form or form instance data is needed. The UI as a whole makes no demands on the server. Most web based systems either require lots of Javascript or HTML to be generated on the server before being sent to the browser.

Keys to Performance : XML

PerfectForms stores its data as compressed XML. This means it is fast to transfer from server to browser and really fast to store in and retrieve from the database. As a result, all Form building and form filling operations pretty well appear to be running locally rather than on a remote server.

Keys to Performance : Loosely Coupled Reporting

Another crucial design goal was to offer all users near realitime reporting in a way that results in no deterioration whatsoever to the core system (form building, filling, dashboard etc) irrespective of reporting load.

As a result, PerfectForms stores its reporting data away from the main form data. Whenever form data is submitted, the XML data for that Form Instance is queued in the reporting system, where it is then processed into a special multi-tenanted reporting table. This reporting system is then accessed by PerfectForms Reporting, API and integration components.

For PerfectForms On Premise, both the core and reporting web applications as well as the core and reporting databases can all be installed on one physical server if you need.

For larger installations, such as our own PerfectForms On Demand, you can partition the overall system into load-balanced web server farms. The reporting database can also be split from the main core database, and it can in turn be easily partitioned to provide more and more performance.

Where are the limits?

As you will be able to see from the Load Tests addressed below, PerfectForms can support really big loads. The actual numbers of users an On Premise system will be able to support depends entirely on the types of applications and forms you have built but PerfectForms will respond very well to your DBA adding basic horsepower and using partioning and other standard scaling techniques shouldit prove necessary.

Load Testing