Create a website for amultinational retailer

Bogdan Simirad

University of Manchester

Degree: Computer Science BSc

Supervisor: Dr. Andy Carpenter

April 28, 2016

This report was written for my third year project in the School of Computer

Science at The University of Manchester

Create a website for a multinational retailer

Abstract

This project is an ecommerce web application designed to change and grow to meet

today's technical demands. The main emphasis is on performance, technology and

scalability. Some of the main functionality includes: full text search, sorting by

different product criteria, a basket, user account with personal information customi-

sation, product comments, product ratings and an administrator panel. The project

is built on top of the MEAN stack, new technologies that improve performance and

minimise server load. The application will be able to accept and sort products with

any number of new properties without writing any extra code if a new kind of prod-

uct is sold.

This report will present a top-view design and implementation of such application

and the techniques used.

Acknowledgements

I would like to thank my supervisor Dr. Andy Carpenter for his constant support

and advice throughout the year.

I would also like to thank my second marker Dr. Carole Janet Twining for her

constructive feedback received during my presentations.

Finally, I would like to thank my family for their encouragement and support.

Without them the project would not have become what it is today.

Contents

Abstract ii

1 Context 1

1.1 Project Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Description of a Domain Problem . . . . . . . . . . . . . . . . . . . . 1

1.3 Aims and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Development Process 3

2.1 Development environment . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Chosen technologies and architecture . . . . . . . . . . . . . . . . . . 4

2.2.1 Mean Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1.1 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1.2 ExpressJS . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1.3 AngularJS . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1.4 NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1.5 Summary: MEAN vs LAMP . . . . . . . . . . . . . 6

2.3 Front-end structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.2 Single Page Website . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.3 Client side rendering . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Back-end structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Project Components . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1.1 End-user functionality . . . . . . . . . . . . . . . . . 10

2.4.1.2 CMS functionality . . . . . . . . . . . . . . . . . . . 11

iv

Contents

2.5 Database Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.6 REST Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.7 Products API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Evaluation 15

3.1 Optimisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Requests compression . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.2 Resource minification . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Testing and feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Performance Testing . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.2 Cross Browser Testing . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Reflection and Conclusion 22

4.1 Project Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.1 Project functionality . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.2 Knowledge Acquired . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 Future Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

References 25

Appendix 28

A A closer look to the DB structure 28

B A closer look at project planning 36

v

List of Figures

1 DigitalOcean server: OS version and some of the used technologies. . 4

2 Mean stack and MVC pattern applied in my project's architecture. . 7

3 Top-View of the database structure. . . . . . . . . . . . . . . . . . . . 12

4 How a connection is established to MongoDB. . . . . . . . . . . . . . 12

5 GZIP compression in NodeJS. [15] . . . . . . . . . . . . . . . . . . . . 16

6 Uncompressed CSS [16] . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7 Compressed CSS. [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8 Plotted average speed based on the requested resource. . . . . . . . . 19

9 Homepage screenshot of the completed project rendered on a Mac-

Book Pro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

10 Shopping Cart screenshot rendered on an iPhone 7. . . . . . . . . . . 21

A.1 Top-View of the database structure . . . . . . . . . . . . . . . . . . . 28

A.2 Category structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

A.3 Images structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

A.4 Orders structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

A.5 Products structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

A.6 Shopping Cart structure . . . . . . . . . . . . . . . . . . . . . . . . . 34

A.7 User Account structure . . . . . . . . . . . . . . . . . . . . . . . . . . 35

B.1 Project Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

B.2 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

B.3 Homepage sketch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

B.4 Product page structure . . . . . . . . . . . . . . . . . . . . . . . . . . 38

B.5 Category Search sketch . . . . . . . . . . . . . . . . . . . . . . . . . . 38

vi

Chapter 1

Context

In this chapter I will give an overview of my application and the goals it achieved

by the end of the development process.

1.1 Project Proposal

The project consists of a website built for a multinational retailer that deals with the

online selling of various items. This webstore should contain the following features:

• Browser products by category

• Filter products by size

• Display product imagery in product listings

• Change the sorting of products based on attribute values.

The system should be designed to be able to support a large number of users

accessing the website at the same time and it should be reliable. It has also been

suggested that the website should be built with advanced tools. My decision about

which tools would be the best for my project will be discussed in chapter 2.

1.2 Description of a Domain Problem

Online shopping has been growing rapidly in the last few years, along with the need

for a reliable platform to sustain this growth. The ability to shop without leaving the

house, and avoiding queues, are just two of the reasons why more and more people

1

Chapter 1. Aims and Objectives

prefer to do their shopping online. The average site's response time has increased

from last year's 7.36 seconds to 8.56 seconds because of this online revolution. [1]

Companies estimate that they lose, on average, 25% of their revenue due to

poor customer experience, or if the page takes longer than 4 seconds to load (blank

page). [2] This is why my project introduces a modern web approach to ecommerce

applications in order to try to improve customer experience by offering a fast, scal-

able and easy-to-use platform that addresses some of these issues.

1.3 Aims and Objectives

The main objectives of the system from a functionality point of view are:

• Allow the user to browse products and filter/sort them

• Allow the user to add products to the basket

• Allow the user to purchase the items and display various payment methods

• Allow the user to view past invoices

• Allow the user to change personal details such as password, address, etc.

• Allow the system administrator to update orders, add products, modify prod-

ucts

• Pull product information from an online API (described in section 2.7)

These objectives are required by the project but some of them are a personal

aim in order to improve the project functionality as well as expand my knowledge

further.

Another important objective of this project is to show how a modern web ap-

proach is applied in this domain and what the benefits of it are in terms of perfor-

mance and scalability.

2

Chapter 2

Development Process

This chapter presents the development process and the multi-layered software archi-

tecture of the project: Front-end, Back-end and the Storage. The communication

between these layers is done in a uniform manner using JSON documents. I will

also present modern tools, approaches and techniques that are different from the

traditional approach, and will explain why they are better for my project.

2.1 Development environment

IntelliJ IDE has been used for the implementation on the local side. All the files have

been saved to GitHub, a version control platform. I bought a server on DigitalOcean

that hosted my project. On it, I installed Ubuntu and the MEAN technologies

described in the next section. This acted as my deployment server where the stable

version would be running. The deployment would only happen after a full iteration

was achieved and until then I would be working on the local copy. I also bought

a domain name for the server to ease the accessibility. In Figure 1, the server

characteristics along with some of the used technologies are shown.

3

Chapter 2. Chosen technologies and architecture

Figure 1: DigitalOcean server: OS version and some of the used technologies.

2.2 Chosen technologies and architecture

This section discusses the background of the technologies used for the development

of the system and why they have been chosen. A comparison is drawn between the

modern web approach and a typical approach, as a summary, in order to reveal the

benefits of these technologies applied to my project.

2.2.1 Mean Stack

My project has its core based in the MEAN stack, a collection of JavaScript based

technologies used to develop new, modern web applications. MEAN is an abbrevi-

ation of four new technologies: MongoDB, ExpressJS, AngularJS and NodeJS. This

is the new, modern web approach, alternative to the popular LAMP stack (Linux,

Apache, MySQL, PHP). In this sub-section, I will describe each of these technologies

and why they are a viable choice for my project.

2.2.1.1 MongoDB

MongoDB is a popular NoSQL, document-orientated database that allows docu-

ments to be stored in a JSON format. It provides flexibility, as the database schema

can be entirely defined on the coding side. Due to the nature of my project, many

products do not have a rigid database schema and MongoDB supports data insertion

without this definition, which makes it easy to be scaled horizontally. In opposition

to vertical scaling that eventually adds more CPU and storage, MongoDB offers

sharding functionality (horizontal scaling). [3] The advantage of this is that it re-

4

Chapter 2. Chosen technologies and architecture

duces the number of operations each server has to handle as well as the amount of

data each unit must store. It is fully distributed with no main server and the data

is duplicated on multiple identical servers. In the event of failure in one or more

servers, others can act like a live backup which allow the web application to continue

running without any special attention required other than recovering the server(s)

that failed. Considering the products stored in my database I believe MongoDB

is a good decision because of the points stated above, but also because it provides

a fast way of indexing. This, along with the support for ad hoc queries, allows a

rapid search through millions of items, which improves the overall performance of

the system.

2.2.1.2 ExpressJS

Express is the back-end part of the MEAN stack that helps with organising the

application into a MVC (Model-View-Controller) architecture on the server side.

It simplifies development and makes it easier to write secure, modular and fast

applications. [4] The main purpose of it is to deal with routes and to handle requests

and views. When a user wants to see a specific webpage, Express points to that

resource. Likewise, we can hide resources from the web by not providing routes to

them, which proves to be useful for an admin page, for instance, where it could

be limited so that only a specific IP address range can access it. In regard to my

application, ExpressJS is responsible for mapping all the static content, such as

HTML, JS, CSS and Images, and providing specific routing of the requests to the

specific REST service implementation.

2.2.1.3 AngularJS

AngularJS is an open-source, relatively new framework, written in JavaScript and

designed to improve the front-end development process. [5] It implements MVC

(Model-View-Controller) that supports the idea of a single page website by refreshing

or updating only specific components instead of the whole page. Angular extends

HTML by allowing behaviour to be triggered by directives based on the syntax

written. This allows conditional blocks and block repetition that HTML normally

does not support. One block can be repeated any number of times, consisting of

5

Chapter 2. Chosen technologies and architecture

different content, without the need to define the structure of the block (just like a

for-loop). This is specifically useful for displaying products, as between them only

textual information changes. It reduces the number of lines written and time spent

coding, which improves the overall readability and the size of the code.

An important component is AngularJS Filters, that deal with sorting, conver-

sion and data removal before the data is displayed on the page. This allows less

information to be processed by the client, and therefore provides a better browsing

experience for the user, as the data is never displayed unless it is what the user

requested. This is particularly useful, as performance is one of the key aspects of

my project.

2.2.1.4 NodeJS

Node.js is the core of my application. It is an incredibly fast server-side platform,

much faster than Ruby or Python. [6] The event-driven architecture of Node allows

asynchronous I/O and, because of its design decisions, it is able to optimise scalabil-

ity of web applications. In regard to my project, Node allows me to use JavaScript

on both server and client side, reducing the number of differences between the two

programming environments. Due to the nature of my application, thousands of users

would be able to access the website at the same time. This technology allows me to

handle all these requests with minimal overhead.

2.2.1.5 Summary: MEAN vs LAMP

This section shows why a modern web approach is necessary (MEAN ) to my kind of

project and why a traditional approach (LAMP) does not meet today's requirements

as effectively. LAMP stack (Linux, Apache, MySQL, PHP) is primarily focused on

Linux, whilst MEAN has no such restrictions, which allows diversity and a wider

testing environment. MEAN uses NoSQL which naturally provides flexibility, while

LAMP forces the use of tables, which would be an issue with the products that have

to be added in my database, as they do not have a defined, fixed structure. Due

to the fact that the website has to support thousands of users, Apache HTTP web

server is not viable; NodeJS would be a preferable approach as it is asynchronous

and event-driven, allowing the same number of users to be sustained, but at a lower

6

Chapter 2. Front-end structure

cost. [7] On all levels that the developer works, by using MEAN, only JavaScript will

be used. This means there is no unnecessary context-switching between writing the

back-end and front-end. Due to these factors, the MEAN approach is the new web

approach but also a better choice for my project as it allows it to be more scalable

in all directions. Figure 2 represents how these four components are connected and

how they interact with each other.

Figure 2: Mean stack and MVC pattern applied in my project's architecture.

2.3 Front-end structure

A traditional, classic website is focused on server-side page generation. The approach

I have followed, including the MEAN stack, allows me to focus on making the

website a Single Page Application. This change involves shifting the Model-View-

Controller artefacts from the server side to the client side. Doing this also improves

server balancing and uses some computational power from the user while improving

server load. In this section I will explain the decisions made during the front-end

development iterations.

7

Chapter 2. Front-end structure

2.3.1 Bootstrap

Bootstrap is an open-source framework written in JavaScript and developed by Twit-

ter. It increases the speed of development by providing a set of building blocks that

help the developer get started with the project and also aid its development. The

decision of using Bootstrap is based on the extensive list of components and bun-

dled JavaScript plugins it provides, along with the fact that it provides responsive,

mobile-ready websites. [8] Being a website that deals with customers and a variety of

products, it is important not to narrow the accessibility of the website by preventing

users from using mobile phones or by providing a bad experience. Overall, in a real

world environment this decision would boost the number of sales and increase the

profitability of the business while improving the scalability of the website itself by

allowing a larger range of supported devices.

2.3.2 Single Page Website

A traditional website is a website formed of links that, once clicked on, refresh the

page and load the new content. In this modern era, this approach is not the best,

especially not for my project. An example of why this is inefficient is if a user were to

add a product to the basket, and the whole page would have to refresh just for this

action to be sent to the server. This would require everything to be unnecessarily

rendered again. The approach used in a Single Page Website is to have a single

page with multiple containers that change according to the user interaction. In the

example above, with the new approach, instead of refreshing the page it just sends

a direct message with the user's action to the server, without the need to refresh

the entire page's content. This reduces the traffic sent between the user and the

server, which allows the website to hold even more users at the same time. [9] It

also promotes simplicity and engages the user by having a simple and powerful user

interface. This approach is possible because of the chosen architecture, MEAN,

which means it is really easy to be coded with AngularJS containers. An example

of this approach applied to my project is when the user logs in while on a product

page. The comments and the ability to rate the product are dynamically loaded

without a page refresh and the user gets immediate access to more functionality.

8

Chapter 2. Back-end structure

This is also applied to most of the user actions such as adding a product to the

basket. A notification in the top-right corner is displayed from the server, showing

whether the action was successful or not, along with the extra information in order

to update the DOM.

2.3.3 Client side rendering

Allowing the rendering to happen on the server-side is a concern from a traffic and

performance point of view. [10] Usually, on a new page request, the header and

the footer stay the same, which requires computation power to be wasted on the

server-side by rendering it again. The idea behind the client-side rendering is that,

instead of a full round-trip page refresh, we only initially request the basic layout

which we defined as static such as CSS, images, footer, header, etc. At this stage, we

will only update the page with relevant information via the REST service described

in section 2.6. Allowing the rendering to happen on the client-side empowers the

idea of obtaining a fast, performant platform as a smaller payload is required for all

further requests. [10]

2.4 Back-end structure

The back-end layer of my application is created using ExpressJS and NodeJS. One

of the responsibilities of this layer is to provide a secure set of REST services. The

back-end is split into two major systems: the admin and the end-user platform. By

separating the resources, we obtain two simpler, more manageable platforms that

allow the code to be scalable in two different approaches.

2.4.1 Project Components

In total, my project contains seven modules for the end-user: Main Page infor-

mation, User Account, Orders, Registration/Login, Product Information, Shopping

Cart, Searching (in all the modules). For the CMS (Content Management System)

there are four modules that deal with: Main page, Categories, Products, Orders.

9

Chapter 2. Back-end structure

2.4.1.1 End-user functionality

The main page module deals with displaying trending and discounted products. It

is meant to capture the user's attention on different products and it is used for

marketing purposes.

The user account module deals with managing user information: changing pass-

word, updating personal details, changing email address.

The past orders module deals with displaying a list of orders. Each of them can

then be viewed in detail with the possibility to download a receipt as a PDF file.

The registration/login module deals with handling a secure authentication with

the server, such as logging in, logging out and assigning the user to the default group.

This can be manually changed in order to make the user an administrator, which

allows further functionality, as described in section 2.4.1.2.

The product information module will display all product-related data and deal

with product rating and comments. Rating a product and leaving a comment is only

possible if the user is logged in. It will also display the product image files that are

locally stored. It will display the appropriate image size for the product depending

on the context it appears in. For instance, if the product is displayed in the basket,

a lower-resolution version of the image will be displayed.

The shopping cart module deals with displaying and updating product quantity

and showing the total sum the user has to pay. It also deals with the selection of a

delivery method, payment, and updating user account with address details, if these

are not already saved. This module is also used in the header by displaying a smaller

version of the basket page.

The searching module is the most complex one. It includes searching for a prod-

uct title or any keyword that could be found anywhere in the product information

(description, property) in order to return the most relevant information to the user.

It also supports searching by multiple filters so a user can sort by colour and size,

for instance. These filter values can differ depending on the product itself or the

category. For instance, a user can search for an actor name in the films category

and, if the films contain this actor, they will be returned as a result if the system

believes it is relevant. In order to obtain this functionality, the Product Controller

10

Chapter 2. Back-end structure

is an essential module, as it has the role of displaying the list of products based on

product category, filtering, free text search, paging and bookmarking. The filtering

was a challenge because each category has a set of dynamic filters, based on the prod-

ucts. In order to populate the filters correctly, I first had to retrieve the category

in which the search is done and add a set of predefined list of filters (Availability,

Media Type, Promotion). When all the requests are completed the data-table can

be rendered.

An example for a URL that can be bookmarked is the following:

http://127.0.0.1:3000/category.html?id=5724ca819f481afe9c0824db&q=

this%20is%20a%20search%20example&s=0&l=10&sb=0&qf[Media]=MP3%20Download

Using this example, we can find a category ID marked by “id”, which points to

which category the search has been done in. This ID will be empty if a search over

the whole database is made. The query is marked by “q”, an escaped string, in this

case, “this is a search example”. The last parameters specify from which element

from the database we start rendering (0 being the first element in the table) and the

length of the page. At the end of this URL, a list of filters, if the user enabled any, will

be written, such as qf=[Media]=MP3, qf=[Availability]=true, qf[Year]=1994. The

structure is qf[FilterName]=FilterValue. This URL, when accessed from bookmarks

or simply by direct access, will tell the server where exactly the user was in the

data-set and it will display the same resources. The URL can contain any number

of valid parameters and it is not limited to this example.

2.4.1.2 CMS functionality

This is the admin panel from where authorised users can modify data stored on the

server. The main page will display all the possible actions a user can take: manage

categories, products and orders.

The category component allows the user to add or modify categories but at the

same time to add any number of sub-categories.

The products component allows the user to add or modify products such as the

category they belong to, product title, description, proprieties, product discount and

product image(s).

11

Chapter 2. Database Structure

The orders component allows the user to add or modify orders placed by cus-

tomers. These orders can be reviewed, marked as dispatched (the user gets a notifi-

cation and they can see the order marked as delivered as well) or cancelled.

2.5 Database Structure

MongoDB is used for the storage of data in a few MongoDB collections, such as Cat-

egories, Images, Orders, Products, ShoppingCarts and Users, that can be observed

in Figure 3.

Figure 3: Top-View of the database structure.

The way I have built the application is so that only the REST service will have

a direct connection with the database for data retrieval. An example of such a

connection is when a category is displayed along with its products (Figure 4).

Figure 4: How a connection is established to MongoDB.

The decision to save the shopping cart(s) in the database comes from personal

experience, as if I add something to it from my computer and decide to continue

12

Chapter 2. REST Service

later from another device, the shopping cart would be empty and it can be quite

frustrating. Because of this I have decided not to save it in a cookie file. The detailed

view of every table can be viewed in Appendix A.

2.6 REST Service

I created a Representational State Transfer (REST ) Service for my project that

focuses on allowing the back-end to communicate with the front-end. So, each time

a request is made, a list of products (relevant to what the user searched for or

requested) is pulled from the back-end server via this service. It provides a JSON

output that will be consumed and displayed on the website by Angular templates. In

order to further improve scalability and performance, these results are partially and

temporarily cached in the event that the same resources will be requested by the

same or a different user. This reduces the server load and the number of requests

needed. In the event that something has changed while this cache exists and the

information would not be accurate, it will automatically be invalidated and the

user will be provided with the most recent data. This approach also enforces the

idea of security, as the client will never actually connect to the back-end directly,

but rather through a controlled middleware. The REST Service is also split in

two: administrator API that returns categories, orders and the products, and the

user API that contains user information, shopping cart data, product data, order

information and categories. In order not to use authentication at every request,

the user of the ExpressJS module, express-session, is used. It provides cookie-based

sessions that store the user identifier. On top of the REST data retrieval, all the

services that I have coded in my application that require user-specific data check

whether the requested information belongs to the end-user or not, in order to display

only data that is authorised for the specific user.

2.7 Products API

In order for my project to have real product information, with true randomised

values and properties, I had to create an API to pull data from a website called

13

Chapter 2. Products API

archive.org. [11] Due to the nature of the content of this website (Creative Com-

mons), I was able to code a separate script to populate my database with product

information. [12] Being allowed to run such a script, I decided to code my API to be

able to pull products from two different categories, audio books and films, so that

it would be a larger variety of products. I successfully populated the database with

over two million records in order to test the reliability of the server and the search

performance over this much data.

14

Chapter 3

Evaluation

Evaluation is the most important factor for my project. The loading time of a

webpage is an important factor for user experience as surveys say that 67.45% of

UK shoppers abandoned a purchase if the experience was slow. [13] This chapter

focuses on describing performance and scalability.

3.1 Optimisations

In order to obtain fast response times from the server, I had to exclusively use

caching and compression of requests/resources. This section will describe the tools

and techniques I have used in order to increase the overall performance of the system

and present the results of these tests.

3.1.1 Requests compression

Compression is a simple, effective way to save bandwidth and speed up the server.

Instead of sending the HTML file directly to the user, we first encode the file by

zipping it (to reduce space) and we leave the client's browser to decompress and

display the page. By doing this, a document's size of 100KB gets compressed to

10KB, which is 10 times lower than the original. [14]

An example of how this is done in NodeJS can be found in Figure 5.

3.1.2 Resource minification

Because my project uses Bootstrap there are different CSS and JavaScript files that

takes a long time to send one by one. The scope of resource minification is to remove

15

Chapter 3. Optimisations

Figure 5: GZIP compression in NodeJS. [15]

spaces, tabs, new lines and comments from these files, thus decreasing the file size.

An example of how a CSS file looks like before is represented in Figure 6:

Figure 6: Uncompressed CSS [16]

An example of how the same CSS file looks after the minification is represented

in Figure 7.

Figure 7: Compressed CSS. [16]

As my website deals with displaying products, they all have an image set (1

to 10 images per product). These images are displayed in the main product page,

16

Chapter 3. Testing and feedback

basket area, receipt and product listing. But in most of these pages the image is

smaller than the original and there is no need to send such a high definition image

to the user when a smaller version of the image could be created. When the user

uploads an image to the server a smaller version of the image will be created that

will be displayed in those areas where high detail is not required. Due to these two

optimisations the user would have to download the same content but faster as the

size of it is now decreased. Another optimisation is that the images are displayed

directly from the Archive.org website, from where the products are pulled. In this

way storage and traffic is saved as images requests are redirected.

3.2 Testing and feedback

Because of the architecture of my system I was able to test my project by creating

individual tests for each component and comparing it against an expected output

or behaviour. Due to the fact that I have used Agile Short Iterations methodology,

I was able to test my project after each iteration. I have also considered extreme

case inputs and covered them in the code. An example of this would be a product

with no image, in which case the default NoImage picture is displayed. This allowed

me to have a bug-free code but during the development as the project changed I

have discovered certain functionality is not working as intended which is not a pro-

gramming error but a design error. Since this discovery I incorporated over fifteen

of my friends that supported me by testing the project and providing me constant

feedback. I was then able to identify what a user expects from my website and

which sides of the project I should focus on/improve. I was then able to meet all

the requirements while improving user experience. As I have used other users for

testing, my confidence in the correctness of the results has increased significantly.

Some of the received feedback included the possibility for the user to use the de-

livery address details on the card information as well, without the need to write it

again, a functionality which is now incorporated in the project. I also tested the

website by inserting over two million products to see how searching would perform.

Considering I am searching in description and product proprieties as well (through

all the available data) this was not the most optimal way to do it. In the future if I

17

Chapter 3. Testing and feedback

continue working on this project I need to incorporate a way of indexing this data

to allow searches to happen faster, perhaps by treating products as documents and

indexing them in a more optimal way.

3.2.1 Performance Testing

In order to evaluate the performance of my website I have used GTmetrix. [17] On

top of offering me statistics, this website provided tips on what optimisations I could

do on top of what I had already done, such as resource minification of JavaScript

and image optimisations. The server hosting my website had minimal resources so

the performance of the website was also highly dependent on the hardware but I was

able to extract some information that should give a rough idea of my application's

performance. The results performed with GTmetrix are shown in Table 1 and

plotted in Figure 8.

URI Test 1 Test 2 Test 3 Test 4 Test 5 AverageCategory.html 30.341 62.343 80.314 61.234 66.342 60.1148Index.html 40.234 159.234 162.234 200.134 161.341 144.6354myAccount.html 3.023 3.203 3.201 2.597 3.295 3.0638myOrders.html 26.302 28.301 27.203 25.302 26.703 26.7622Product.html 170.202 180.300 174.302 200.302 182.002 181.4216shoppingCart.html 2.001 2.005 3.007 2.003 2.010 2.2052

Table 1: Average speed based on the requested resource

I ran these tests after all the optimisations. There was an increase of 35% in

performance compared to the initial, un-optimised version of my project. I am

pleased with the results above as they are mostly constant. The peaks happen when

a product has more than one image and the lowest values are hit when the product

has no image (the default NoImage is shown, which is optimised).

3.2.2 Cross Browser Testing

Major browsers that are used by internet users such as Mozilla, Internet Explorer,

Chrome, Opera and Firefox have been used in order to test the capability of the

website's being displayed properly. Due to the fact that there are many versions,

only the latest ones have been used for the purpose of testing. The tests were

18

Chapter 3. Completeness

Figure 8: Plotted average speed based on the requested resource.

successful with small bugs on Internet Explorer, where the view-port would not

be displayed correctly. Further testing has been done by using the developer tools

included in Chrome and Firefox in order to preview and debug the live version of the

website. At this stage I also tested some vulnerabilities such as JavaScript injection.

Taking into consideration the fact that users are browsing ecommerce websites from

mobile devices as well, I have tested it from an iPhone 5, 7 and a Nexus 5 phone.

The content is displayed correctly but it is not the best experience that a user can

get so further work is required in this section if I develop my project further, after

graduation.

3.3 Completeness

On top of end-user platform, I have built a Content Management System for admin-

istrators. From here, authorised users can see, sort and deal with orders by marking

them as delivered or cancelling them. Products can be updated, removed and put

on sale and we can manage categories that will appear in the header dynamically. I

have covered all the features required by the project and on top of it I have extended

the functionality on searching and ordering as described in the previous chapters.

A picture of the homepage of my completed project can be seen in Figure 9 and

19

Chapter 3. Completeness

Figure 10.

Figure 9: Homepage screenshot of the completed project rendered on a MacBookPro.

20

Chapter 3. Completeness

Figure 10: Shopping Cart screenshot rendered on an iPhone 7.

21

Chapter 4

Reflection and Conclusion

In this section I will describe the overall achievements and knowledge I have obtained

during the last few months, along with any further improvements I will add to my

project in the future.

4.1 Project Planning

The methodology applied to my project was Agile, Short Iterations. Initially, the

decided iteration length was a week but shortly after, I realised that it was too

often and it did not allow me to finish any planned action therefore I had to extend

it to two weeks. This happened because at the beginning I did not have a clear

idea of how my system architecture worked and it had to be changed several times.

The iterations have been prioritised on the value they bring; therefore, my first few

iterations were to display a product. From there it extended to displaying a list

of products and a basket that would take these items. I will group the iterations

into three main groups. After the website was able to display products from the

database I coded the individual product page, a generic page that would update

accordingly to the product type and content. Once all the tests were passed for the

current modules I designed the categories and subcategories. The problem here was

that they had to be dynamic and displayed in the header whenever a new one is

added or removed. The last planned iteration group was the login module. Now this

project is at the required stage by the requirements. As I have finished earlier I was

able to code an administrator page, comments and a rating system. I was then able

to focus on the searching module to make it as complex as I could for the remaining

22

Chapter 4. Achievements

time. More information about project planning can be found in Appendix B.

4.2 Achievements

This application is an achievement in itself as it is my first large-scale web project.

The task of meeting all the aims and objectives defined in the proposal of the report,

as well as my personal aims, were successful challenges from which I have learned

many lessons, as those described in this chapter.

4.2.1 Project functionality

One of the greatest achievements is that the system is not limited by its design. Any

kind of product or category can be dynamically created from the admin panel or

via the product pull API. The products will be displayed correctly despite the fact

that the number of proprieties or attributes (product description) is different. The

searching functionality also supports and detects these unique product proprieties

and allows them to be used in a search query. For instance, if a music CD or a

new genre that the system does not know about is introduced into the system, it

will automatically understand this attribute. It is also true for a completely new

attribute such as “CD artwork”, which can then be used to display the products

that only have this property as true along with other attributes. Another important

achievement of my project is the highlighting of the query words in the product list

result (note: this query has been done on the server). This is important from a user

experience perspective as it helps the end-user understand better where the query

words are coming from (product, description, etc.). On the AngularJS side this was

done using a simple Regex. The highlighted words are shown highlighted on the

correct resulted list of products, on the client side which reduces the offload of the

server.

4.2.2 Knowledge Acquired

I have always been interested in web development but I never got to build a project

on such a scale. In the past I have always used the LAMP approach and taking this

application for my third year project made me understand in which way modern web

23

Chapter 4. Future Scope

developing is heading, but it also made me aware of different approaches, techniques

and challenges. One of the most important pieces of knowledge that I have gained

through this project was through setting up my own Ubuntu server and configuring

it to work with the MEAN stack. This information will be useful for the future as

working on a server or setting up new tools for a server is a requirement for many

jobs in Computer Science. After my architecture was set up, I became proficient

with JavaScript, a popular language, from a stage where I was unfamiliar with

it. I have learned about the importance of NoSQL databases, NodeJS, ExpressJS,

AngularJS, Bootstrap and how to use IntelliJ IDE in an efficient way, on a daily

basis. These tools are widely used by the web design industry and I believe this is

a great achievement as, if I chose this path for my future, it will be of great help. I

have also learned how to build my own API as well as how to use existent ones.

4.3 Future Scope

For the scope of deploying my system in the real world, many other functionalities

would be required. My application is secure for the scope of the project, but it needs

to be empowered as holding thousands of customers' data is a sensitive business.

The extra functionalities that I had planned to code but could not achieve in time

are an email system that sends messages/notifications/receipts to the users and the

incorporation of a payment system such as PayPal. The system would also need to

be tested from all aspects to ensure there are no bugs at the time of deployment. It

is in a very stable state but definitely not fully ready to be a real world application.

From the feedback obtained during testing, an interesting functionality has come

across that the website should support the option for the customers to sell their own

items as well on the website. This also gives an opportunity for customers to buy

a second-hand item. This process would also involve an email or chat system that

could secure communication between the client and the seller. A final improvement

would be to create an area where complaints and returns can be processed, as this

is an important factor to customer satisfaction, along with the ability to view the

price and purchase in a different currency.

24

References

[1] 15 Hazards That Will Cripple Your E-Commerce Sites Load Time, [On-

line]. Available: https://blog.kissmetrics.com/ecommerce-load-time-

hazards, [Accessed: 01 - Apr - 2016].

[2] A Modern Approach to Ecommerce Optimization, [Online]. Available:

http://www.slideshare.net/vivastream/a-modern-approach-to-

ecommerce-optimization, [Accessed: 01 - Apr - 2016].

[3] What is MongoDB?, [Online]. Available:

http://searchdatamanagement.techtarget.com/definition/MongoDB,

[Accessed: 01 - Apr - 2016].

[4] Node.js : Modularizing Express.js and Node.js Applications, [Online]. Avail-

able: http://www.javabeat.net/nodejs-modular-application/, [Ac-

cessed: 02 - Apr - 2016].

[5] What Is Angular?, [Online]. Available:

https://docs.angularjs.org/guide/introduction, [Accessed: 02 - Apr -

2016].

[6] What are the benefits of developing in Node.js versus Python?, [Online]. Avail-

able: https://www.quora.com/What-are-the-benefits-of-developing-

in-Node-js-versus-Python, [Accessed: 04 - Apr - 2016].

[7] What are the pros and cons of Node.js versus Apache web server?, [Online].

Available: https://www.quora.com/What-are-the-pros-and-cons-of-

Node-js-versus-Apache-web-server, [Accessed: 04 - Apr - 2016].

25

References

[8] How To Build Responsive Mobile Friendly Websites With Twitter Boot-

strap, [Online]. Available: http://line25.com/tutorials/how-to-build-

responsive-mobile-friendly-websites-with-twitter-bootstrap, [Ac-

cessed: 04 - Apr - 2016].

[9] 8 Reasons Why Pageless Design is the Future of the Web, [Online].

Available: http://www.dtelepathy.com/blog/design/8-reasons-why-

pageless-design-is-the-future-of-the-web, [Accessed: 05 - Apr - 2016].

[10] What are the tradeoffs of client-side rendering vs. server-side rendering?,

[Online]. Available: https://www.quora.com/What-are-the-tradeoffs-

of-client-side-rendering-vs-server-side-rendering, [Accessed: 06 - Apr -

2016].

[11] The Archive Website, [Online]. Available: http://archive.org/, [Accessed:

10 - Nov - 2015].

[12] Terms of Archive.org Website, [Online]. Available:

https://archive.org/about/terms.php, [Accessed: 10 - Nov - 2015].

[13] Two-thirds of shoppers unhappy with online customer experience, [On-

line]. Available: http://www.information-age.com/industry/uk-

industry/123459020/two-thirds-shoppers-unhappy-online-

customer-experience, [Accessed: 15 - Apr - 2016].

[14] How To Optimize Your Site With GZIP Compression, [Online]. Available:

http://betterexplained.com/articles/how-to-optimize-your-site-

with-gzip-compression/, [Accessed: 15 - Apr - 2016].

[15] GZIP example in NodeJS, [Online]. Available:

http://stackoverflow.com/questions/8880741/node-js-easy-http-

requests-with-gzip-deflate-compression, [Accessed: 24 - Apr - 2016].

[16] CSS Minifier, [Online]. Available: http://www.cleancss.com/css-

minify/, [Accessed: 24 - Apr - 2016].

26

References

[17] GTmetrix: Analyze your sites speed and make it faster, [Online]. Available:

https://gtmetrix.com/, [Accessed: 01 - Feb - 2016].

27

Appendix A

A closer look to the DB structure

In this section I will describe in a bit more detail Figure A.1, also displayed in

section 2.2.2.2 as Figure 3. The Categories structure of the database is displayed

in Figure A.2.

Figure A.1: Top-View of the database structure

28

Figure A.2: Category structure

For a category I have decided that the best information I can store is:

• An ID that is used for bookmark-able URLs as well as its unique identifier

• The name of the Category to be displayed on the website

• When it was created

• When it was last updated/modified

• Priority which renders the position in the header

The category is able to contain sub-categories. They are composed of the fol-

lowing:

• The name of the sub-category

• The ID of the sub-category

• Hard-coded filters which will be applied to all the products in this section

29

The next database structure is for images, displayed in Figure A.3. This con-

tains:

• An ID of the image that is used when displaying it on the website

• A filename to be found in the local system which is the image itself

• The path where the file can be found

• Content Type which tells the system what kind of an image it is

• The path you can access this image via the browser after the routing

Figure A.3: Images structure

The third database structure contains the orders and it is shown in Figure A.4.

It is composed of the following fields:

• The unique ID of the order

• A list of arrays which represents the items purchased

This list is formed of the following:

• The ID of the product

• The quantity of the product that has been purchased

30

• Total price paid for the product(s)

Following the product field, it is composed of:

• Attributes that describe the product

• Filters such as Availability

• qFilters which is the filters inherited from the category/sub-category

• Generic information such as the name, price, description and product code

• Sub-categories it belongs to

• When the item was added to the website

• When the item was last updated

• A list of references to images to be displayed on the product page

31

Figure A.4: Orders structure

The products database structure is displayed in Figure A.5 and it is composed

of the following:

• The unique identifier of the product

• The attributes of the product such as the name of it

• The filters of the product such as Availability and whether the product is

discounted

• Inherited default filters from the category/sub-category such as In-Stock

• Different generic attributes such as name, price, description and code

• The sub-categories the product belongs to

The second-last database structure represents the shopping carts in Figure A.6.

It is formed by the following:

32

Figure A.5: Products structure

• The unique identifier of the shopping cart

• The list of products inside the shopping cart which is composed of the prod-

uct's unique code and the quantity

• The sessionID that belongs to this cart

The final database structure is represented in Figure A.7, composed of the

following:

• The unique identifier for this user

• The email address of the user

• The password of the user, encrypted

• The first name

33

Figure A.6: Shopping Cart structure

• The last name

• The phone number

34

Figure A.7: User Account structure

If the user has an address these supplementary fields will be also stored here.

35

Appendix B

A closer look at project planning

The project planning started by analysing the requirements. I then created the

UML diagram of the project and a basic use case. These are represented in Figures

B.1 and B.2. After deciding what functionality the website should do, the next

step was to decide which technologies would be best for my project.

Figure B.1: Project Functionality

After all the requirements were understood I proceeded to sketch out how the

36

Figure B.2: Use Case Diagram

website would look. Figures B.3, B.4 and B.5 represent my vision of how the

website would look in the first month of project planning.

Figure B.3: Homepage sketch

37

Figure B.4: Product page structure

Figure B.5: Category Search sketch

38