Web-based business applications have come a long way in the last decade. Some of them look more like installed applications than something that is actually running inside the browser. As technology evolves, developers have more tools at their disposal to improve their user’s interactive experience without overcomplicating their source code. JavaScript is especially important because it runs where the data is and it does not require an installation. It also gives developers much more flexibility to provide instant feedback without having to make a round trip to the server.
Where Should the Logic Live?
For starters, let’s consider a hypothetical scenario pertaining to a web site for an insurance provider. To insure my new car, I must fill out an online application. The first portion of the application requires me to provide my name and address. The application will validate the data I enter before allowing me to move on to the next page. As developers, the question we face is: where should the business logic that checks the input data live?
There are seemingly endless ways to solve most problems in the web world, but for this scenario there are three common approaches. Let’s look at each from both the developer perspective relative to effort and the end user from the user experience perspective:
- Option 1: Put all of the business logic on server
- Developer: Easiest option. No JavaScript required.
- User: Slow experience due to the fact that every event that relies on logic to run requires a round trip to the server
- Option 2: Put core business logic on server accompanied by light-weight JavaScript helpers on the client
- Developer: Medium effort.
- User: A faster user experience because light-weight logic (e.g. “You must provide a first name”) can execute in the browser without having to round trip to the server. This is an improved user experience, but it has its limits. Complex logic is still very expensive/difficult to create/maintain in JavaScript.
- Option 3: Put core business logic on the server and the client, where the developer decides where the logic lives, allowing for the possibility of the logic living in both places
- Developer: Most difficult
- User: Very responsive application, provides a fast and seamless user experience (due to the fact that most business logic lives in the browser, requiring infrequent trips to the server and thereby reducing server traffic).
Option three is the clear winner for the end user, but what about the developer? As more logic is baked into the client, the required effort increases. This is especially true if there is logic that will live on both the client and the server, where more often than not, the logic will be written in different languages. Maintaining separate code bases is expensive and risky. Wouldn’t it be great if we could provide an amazing user experience without the heavy investment of creating and maintaining large amounts of logic in JavaScript on the client?
Yes it would.
Portability of Logic
With InRule, internal subject matter experts, regardless of their level of technical expertise, can author, maintain and modify business rules. While this model works great, we believe we can provide more value by delivering a meaningful/responsive user experience in the browser without significant developer involvement.
Our engineering team is working on enhancements to the InRule offering that will give rule authors the ability to take their existing rules and render them to JavaScript. The end result will be a JavaScript file that can be deployed with an application to fulfill the browser’s business logic needs. The deployment process is not finalized yet, but our goal is to make it as easy and automated as possible.
Alpha Bits: Not Just for Breakfast
We already have the base rule engine functionality working in JavaScript. If you are interested in discussing this new and exciting feature or if you would like to be included when we ship the alpha bits, please email me at [email protected].
