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 ''=' 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.

blog comments powered by Disqus