Anatomy of a web application project

21-11-2019

A web application can broadly be divided into three components or layers:

  • A top presentation layer: What the user experiences.
  • A bottom data layer, The data and information (processed data) that you are producing or collecting.
  • The logic that lies between the data and presentation layers: All the functionality that you are going to apply to the data in order to make it useful for the user.

One may be tempted to start from the top and work downwards or start from the base and work upwards, but it probably makes most sense to start both places and build the logic to connect them. As the project owner YOU should have a good feel for the top and bottom of this system. But you are probably less interested in the middle section which can more or less be treated as a black box, as long as it delivers the functionality you need.

Another common pattern seen in IT systems is referred to as Service Oriented Architecture or SOA, but it is not antithetical to the layered pattern. It primarily concerns how objects and data are transferred between different parts of the system, which can overall still be described by the layered hierarchy described above.

Data

Data is the basic resource that you are going to capture, manipulate and present to your customers. During this process data passes through three phases roughly as follow: 1) Primary Data - the raw material you obtain from mining the internet, by tapping into a public or commercial database, or collect from your customers or business activity. It is like a raw resource that may or may not be in a user friendly format. 2) Information - data that has been organised into a format that is directly useable for solving your specific problems. It is probably raw data that has been filtered, sorted, prioritised etc. 3) Knowledge - information that has been transformed into something that solves real life problems. It is all the added value that you have given to the original data, and which people are willing to pay for.

With these definitions in mind the development tasks that need to be addressed are:

  • Data capture:
    • Public database accessed by an API. In the nutritional example on this website it is the US Dept. of Agriculture food database, but it could equally be any of hundreds of accessible databases on the internet such as Government statistics or one of Google's many information services.
    • Direct data scraping from the internet, using precise keywords to search for updates on specific topics.
    • Building your own datasource from customer surveys, sales statistics or any other direct data capture initiated by you.
  • Data storage:
    • A relational database is most likely used for serving data within the application, but this area also covers how the data is backed up, and whether it resides on disk in serialised forms (for example text files/xml).
  • Policies for data maintenance and validation.
  • Data model: a critical foundational activity that will affect the whole future development of your project.

Application logic

This part of the system probably contains the largest part of the actual coding. Logic can be divided into presentation logic, which is closely linked to supporting the presentation layer of the web application, and the pure business logic, which manipulates data and should deliver it without a need to consider how it will ultimately be presented. The important point here is to try and keep the business logic well isolated from the remainder of the system so that it can easily be extracted and plugged into another framework without the need to rewrite the code internally.

There are several parts within the logical layer that can be modularised and reused in different contexts. The area of user management covering authentication, sign-ups, user-profiles etc. is one such example.

Presentation

Presentation determines what the user directly experiences and covers broadly two things: Firstly the user flow, which is how the user navigates through the application, and the design itself, which furthermore has both functional and aesthetic aspects that can be equally important in creating a good user experience.

The rapid development cycles available in frameworks such as Django provide a good way to really test user flow so that the application appears logical and intuitive. There are a lot of details that need to be iron-out here including how the user avoids getting lost or confused. For example one should build things so that there are no adverse effects if the user clicks on the browser's back-button.

In discussing this part of the system one will have to decide how much functionality occurs in the back end, and how much is taking place within the browser using various front-end frameworks based on Javascript. There are lots of different views on this but it really depends on what type of application you have, and what kind of organisation you are. I think that sites with very sophisticated front-ends can work as long as they are supported by a highly competent developer team . If you have a small team and you need to keep things as reliable and maintenance free as possible then I would favour more emphasis on back-end functionality, and I would certainly recommend making sure that anything mission-critical is processed on the server side.

Finally it is worth pointing out here that although you may need to employ expensive UI and UX specialists at some stage to help perfect things, don't forget that you are also highly qualified to carry out a lot of this work simply because you are a human being who knows what you like and hate about the web sites you have used. You may be puzzling as to why some of them are so annoying, but with a little thought you can pinpoint the problems and avoid them in your own project.

Deployment

You may have heard the word DevOps used in IT circles. It simply means the practices that ensure good integration between the development process and the deployment and maintenance in the production environment. It means that developers and system administrators can't each sit in their own world isolated from each other - I can't imagine that any other approach would be adopted today, given that most applications are under constant development and improvement. Although this term may sound rather grandiose for smaller applications there nevertheless needs to be a well define procedure for test and deployment. It is also a fact that even for completely stable applications, updates in basis software and browsers mean that periodic review and reconfiguration are unavoidable.

SEO, Privacy, and GDPR

An SEO and digital marketing strategy is essential for the success of any project and should probably be specified early as it affects many aspects of the front end programming in particular. Part of this is choice of website analytics and configuration of various webpages such as robots.txt and sitemap.xml. GDPR and privacy policies also impact the technical implementation. The site owner needs to be able to document that privacy policies are upheld at the technical level so there needs to be a specification that defines how personal data protection is implemented . Online privacy statements and cookie acceptance banners are details that need to work to provide user confidence in the site.

See all articles