Figure 1 - Separation of Front Office and Back Office applications
When I tell people that I develop web applications, specifically administrative web applications, they immediately assume that I develop web sites, and they cannot understand it when I tell them that they are not the same. For example, an application built with the Radicore product is not the same as the http://www.radicore.org web site which is used to advertise the product.
Most people know the difference between a desktop application and a web site, so it is sometimes easier to understand if I say that a web application is equivalent to a desktop application with a web interface. As a web site does not have an equivalent desktop version it should therefore follow that there are differences.
I sometimes refer to a web site as the Front Office or Showroom software and the web application as the Back Office software. Other people may use Front End and Back End. The front office is where visitors come in to browse and sometimes make a purchase. The back office is there to provide support services for the front office, such as processing customer orders and maintaining, issuing and replenishing inventory. While the front office is open to anyone, access to the back office is restricted to authorised personnel only. While the front office software is web only, the back office software can be either desktop or web, or a mixture of the two.
It is possible for a web site (front end) to have a companion web application (back end), as shown in the following diagram:
Figure 1 - Separation of Front Office and Back Office applications
Here you should notice that the only shared resource is the database. Because of this it is, or has been, common practice to have the back office system implemented as a desktop application, which usually means that it is developed in a different programming language.
The front end/web site is where visitors go to make purchases. The back end/web application is used by the back office staff to deal with all aspects of order fulfilment, such as validating the customer's payment, picking the product from inventory, dealing with outgoing and incoming shipments, customer returns, stock replenishment (which may involve sending purchase orders to suppliers) and performing stock checks. A back office application is not necessarily the same as a Content Management System (CMS) as it does much more than simply maintain the information that is displayed on the web site.
It is possible for a web site to exist without a companion web application. Some web sites do not need support from a back office application, or that support may be provided by a desktop application.
It is possible for a web application to exist without a companion web site. For example, an organisation may have a web application which allows employees to enter their timesheets and expenses, but this application does not have a web site which is open to casual visitors.
The only similarity between a web site and a web application is that they both access HTML documents using the HTTP protocol over an internet or intranet connection. However, there are some differences which I shall attempt to identify in the following matrix:
| Front End Web Site | Back End Web Application | |
|---|---|---|
| 1 | The primary function is to attract visitors, so its emphasis is on the purely visual using fancy fonts, colours and imagery. | The primary function is to make data available to members of staff so that they can perform their duties as quickly and efficiently as possible. Functionality is therefore more important than looking good. |
| 2 | Will usually be available on the internet, but may be restricted to an organisation's intranet or extranet. | Will usually be restricted to the intranet or extranet owned by a particular organisation, but may be available on the internet for employees who travel beyond the reach of that intranet. |
| 3 | Can never be implemented as a desktop application. | May have exactly the same functionality as a desktop application. It may in fact be a desktop application with a web interface. |
| 4 | Can be accessed by anybody. | Can be accessed by authorised users only, usually members of staff. |
| 5 | Can contain nothing but a collection of static pages although it is possible to pull the page content such as product details from a database. | Contains dynamic pages which are built using data obtained from a central data store, which is usually a relational database (RDBMS). |
| 6 | May be updatable by a single person with everyone else having read-only access. For example, a web site which shows a pop star's schedule can only be updated by that star's agent, but anyone can visit the site and view the schedule. | Any authorised user may submit updates, subject to his/her authorisation level, and these updates would immediately be available to all other users. |
| 7 | May have parts of the system which can only be accessed after passing through a logon screen. | No part of the system can be accessed without passing through a logon screen. |
| 8 | Users may be able to self-register in order to pass through the logon screen. | Users can only be registered by a system administrator. |
| 9 | All users may have access to all pages in the web site, meaning that there may be no need for any sort of access control. | The application may cover several aspects of an organisation's business, such as sales, purchasing, inventory and shipping, in which case users will usually be restricted to their own particular area. This will require some sort of access control system, such as a Role Based Access Control (RBAC) system. |
| 10 | May need URLs that can be bookmarked so that users can quickly return to a particular page. | Bookmarks are not used as each user must always navigate through the logon screen before starting a session. |
| 11 | Has no problems with the browser's BACK and FORWARD buttons. | The use of the browser's BACK and FORWARD buttons may cause problems, so may need code to detect their use and redirect to a more acceptable URL. The Radicore approach is documented in Back Button Blues. |
| 12 | It is not possible to have more than one browser window open at a web site and to maintain separate state for each window. State is maintained in session data on the server, and the session identity is usually maintained in a cookie. As multiple browser windows on the same PC will by default share the same session cookie they will automatically share the same session data and cannot be independent of one another. | It may be beneficial to allow separate windows to have separate state as this follows the standard behaviour of most desktop applications which allow multiple instances, each with different state, to exist at the same time. This will allow the user to access one part of the application in one window and another part in another window. The Radicore approach is documented in Client Clones and Server Sessions. |
| 13 | Execution speed may need to be tuned so that the site can handle a high number of visitors/users. | As the number of users is limited to those who are authorised then execution speed should not be an issue. In this case the speed, and therefore cost, of application development is more important. In other words the focus should be on developer cycles, not cpu cycles. |
| 14 | May need special handling to deal with search engines. | As no URLs can be bookmarked (see above) then all aspects of Search Engine Optimisation (SEO) are irrelevant. |
| 15 | May need to include code for affiliate marketing. | This is not relevant in a back end application. |
| 16 | May need to include code for banner advertising. | This is not relevant in a back end application. |
| 17 | May need to include code to interact with social media sites. | This is not relevant in a back end application. |
The fact that there is a difference between the two is not apparent to most of today's script kiddies who manage to cobble together what passes for a web site for an organisation, then, when asked to build a back office application to support what is used by the front office they continue with the "this is a website" mentality. Speaking as someone who has developed and used administrative applications on the desktop for several decades I can safely say that such a mentality does not deliver a quality product. When moving from the development of desktop applications into the development of web applications I made a conscious effort to carry across those features to which I had become accustomed, and these are the features which my current users have come to appreciate.
Although the Radicore framework has been specifically designed for the development of back-office applications, it is possible to reuse some of its components in a front end web site. Please refer to Using Radicore components in a front-end website for more details.