Application architecture
A web application can implement the same rule in several places. A field can be hidden by JavaScript, rejected by server validation, or constrained by the database.
The best location depends on the responsibility of the rule. A useful principle is: put the authoritative rule where it cannot be accidentally bypassed. PHPRunner exposes browser, server, and database integration points, but they should not be treated as interchangeable.
Immediate interaction: show or hide fields, enable controls, calculate display hints, improve form usability.
Authoritative workflow and validation: permissions, state changes, integrations, business decisions.
Data integrity and shared data rules: keys, constraints, relationships, reusable calculations close to the data.
Quick answer: Use browser code for responsive UI behavior, server-side code for authoritative application rules, and database rules for integrity that should hold regardless of which application writes the data. Duplicate a rule across layers only when each copy has a clear purpose.
“Show this field only when Type = Other” is different from “Type requires a description.”
The first rule improves the interface and belongs naturally in the browser. The second protects data quality and should still be enforced when the record reaches the server.
Keeping that distinction clear prevents large JavaScript files from becoming the only place where important rules exist.
Some constraints should survive every application and integration.
Primary keys, unique relationships, valid foreign keys, and other structural rules are strongest when enforced by the database. If two different applications write the same tables, database-level integrity is especially valuable.
Not every business rule belongs in a trigger or constraint, however. Complex workflow decisions may be easier to test and explain in application code.
Sometimes the rule should be stored as data rather than hard-coded in dozens of forms.
Your 2025 blog article demonstrates a useful pattern: store form triggers and actions in database tables, then use shared application and JavaScript logic to interpret those rows. The result is a configuration-driven system rather than a separate block of custom code for every field.
This approach works well when many forms follow the same class of rules and administrators or developers need one place to review the configuration.
The goal is to keep the architecture understandable while reducing repetitive application work.
PHPRunner exposes all three layers: client JavaScript, server-side events and APIs, and the underlying database, so rules can be placed according to responsibility rather than tool limitation.
| Need | PHPRunner approach |
|---|---|
| Browser behavior | Use JavaScript and Control APIs for interactive field and page behavior. |
| Server rules | Use events, validation, Security API, Database API, and custom business logic. |
| Database integrity | Use keys, constraints, views, stored logic, and SQL where the rule belongs with the data. |
| Data-driven configuration | Store repeatable rules in tables and have shared code interpret them when that reduces duplication. |
The strongest architecture makes it obvious which copy of a rule is authoritative.
Use the browser to help the user, the server to protect the business process, and the database to protect the data itself.
When a rule appears in more than one layer, document why. One copy may be for instant feedback while another is the real enforcement point.