It is easy to create a website, but a production-grade website is far more difficult. All of the [app.production] rules apply to production websites, but the following table lists some additional examples of how a robust website can be developed.
| Amateur website |
Production grade web application |
| None of the pages are compliant with W3C standards |
All pages are W3C XHTML standards compliant where possible |
| Parts of the site only work on Internet Explorer |
The site handles most major browsers due to its compliance to W3C XHTML standards |
| The site pushes Javascript to its limits. |
The site uses minimal javascript, only when absolutely neccessary, and when it does so, all browsers are tested and verified. |
| It is impossible to use the web server in a load balanced environment |
The application can be used in a load balanced environment without software redesign |
| A fixed deployment domain or IP address is assumed, so if the site is deployed elsewhere, it won't work |
The site is deployment domain agnostic |
| Site is complex to use because developers invented their own UI |
Site is simple to use because developers consulted with (sensible) UI experts. They created a site that uses common, well-recognized navigation concepts. |
| The site only works if users click on the usual standard options. Please do not click the [Cancel] button. |
Both sunny and rainy day user activities are covered. Every link on every page works. |
| Fatal unexpected errors (such as being unable to connect to a database) result in a crash dump screen or a “page not found” screen that the user sees. |
Fatal, unexpected errors result in a nice user screen with an error reference number or at least a “try again later” message. |
| Each page opens a new database connection for the duration of the request and closes it afterwards. Therefore, it will not scale because it needs a ratio of 1:1 for database connections to concurrent requests. |
The web application uses a connection pool to re-use existing database connections, for performance. Therefore it can have many more concurrent users than there are database connections. |
| Hackers can use a SQL injection attack to obtain data or drop tables without logging in. This is usually accomplished by entering SQL text in login forms. For example they could type.. ' OR ''=' ..in the password field to make the database do a query: SELECT user FROM usertable WHERE username='fred' AND password='' OR ''=''; |
SQL injection is protected against on all fields by explicit detection. |
| Users can modify the record numbers in the URL to gain access to data that does not belong to them. |
URL rewriting is protected against. Permissions are checked on every request, including form submits. Even if it makes the application a little slower. |
| Errors and information messages display differently depending on what screen it is. |
Users get the same kinds of errors and information messages across the entire application. |
| The application relies on the browser back button or javascript back(); for navigating to previous pages. |
A programmatic back button is provided (eg. “<< back to my bills”) |
| Paginated screens hold open result sets in the database between client requests. |
Pagination does not consume database cursors or result sets. |
| The application cannot execute without passing variables through to the web client and back again. Server values can be seen as hidden form fields by selecting “view source” on a web page. |
The session is utilized to persist sensitive information between screens. |
| Javascript is used for navigation. Navigation does not function when javascript is switched off, and. |
All URLs are calculated by the server and are shown as links without javascript where possible. |
| The site has one server. |
The site uses clustering and load balancing with sticky sessions to manage load. |
| The server runs only on WebLogic 6.1, using the specific Weblogic extensions and tools that come free with Weblogic licenses. |
The server runs on any application server with minimal tweaking provided it is a compliant servlet container. |
| User Sessions are loaded full of information. No screen can execute without a session in a finely tuned Session that was created using a number of previous screens. The application memory requirements are huge. |
User Sessions contain hardly any information, perhaps just a flag to indicate if the user is logged in or not. Screens are generally independent, passing small amounts of information back and forth in the request. |
| A single login does two thousand physical database queries in order to display the first screen. |
A single login does five physical database queries in order to display the first screen. |
| Class or JSP files are allowed to be changed directly on the production server without updating the source code or having to do a full release. All developers, even those who joined the company a week ago have full write access to production servers and the database. |
The only way to do a release is by following a defined release process from DEV => TEST => STAGING => PRODUCTION. The test team must approve the release. Senior Developers have read-only access to production servers and the database. |
