1. Introduction and Goals

1.1. Requirements Overview

The functional requirements that the application will have:

  • The login process is delegated to a POD provider (that you can choose from). This means, the fewer information will be stored and the system will be as decentralized as possible.

  • The users will be able to select products to buy. Also they will be able to search for a specific product or filter them. Sorting by price is also possible.

  • Once the user has selected the products:

    • They will be able to see the shopping cart and modify the units of each product. The user is also able to remove the products from the cart.

    • The system will calculate the shipping costs using a custom - created by us - carrier API depending on the user’s address. Pick up locations can also be chosen from the list of available shipping methods, in such a case, you will be able to choose a near-by place where your package will be delivered.

    • The user will be able to see the final cost of the order and select the payment method to complete the order. After an order is completed, the user may download a bill of the actual order.

    • The system will simulate the order shipping and will notify the user the status of the package: ordered, received…​

  • In a separate part of the application, the user will be able to manage list important information:

    • The user will be able to see the orders done by him. In case an admin is watching, all the orders will be listed.

    • A moderator or admin will be able to add, edit or remove products.

    • Account information will also be modifiable directly from the app. Thus, you will be able to modify the addresses in your POD: add, edit or remove them.

  • A detailed version of the product listing will also be available for the user:

    • Information regarding the description, price, stock, number of reviews…​

    • The user will be able to see reviews of the products. And also write or edit them. Not only that, but no personal information will be stored, the system will obtain it from the POD.

  • The application will be implemented using the React framework and TypeScript.

  • An about page will be shown. There you will have information of the project itself: how we created it, the technology used (we advocate for transparency), to name a few.

  • The application should be accessible and deployed using a continuous integration system.

1.2. Quality Goals

Quality goal Motivation Concrete scenarios Priority


Your data, your choice.

The only way for us to ensure privacy is allowing users to know what we do with their data. This is only possible if the source code is available for anyone to read it. More in more, we will allow users to use their data as they please, not as we do.



80% of the effects come from 20% of the causes.

We will aim for the application to load in less than 1.5 seconds; indeed, 47% of the internet users expect a site to load in 2 seconds or less, so we are focusing in doing it better than the average.



If a user is having a problem, it’s our problem.

We aim for 90% of the users to be able to complete any -separate- task in less than 2 minutes, without any previous knowledge of the app.



We wont be able to develop a good product unless data is stored in a secure place.

Data must not be accessible for any third parties. Data from users will be stored in a secure system.



Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

Software industry averages 1-25 errors per 1000 lines of code. We will aim for higher excellence-ratios: 0.5 defects per 1000 lines of code.



Free, as in freedom.

The whole project, including all the components: code, documentation…​ Must be uploaded to a public repository, for it to be accessible to anyone in any place.


1.3. Stakeholders

Role/Name Contact Expectations


Álvaro Rodríguez González, Pablo Lopez Amado, Andrés Martínez Rodríguez, Ángel Iglesias Préstamo and Noelia Iglesias Cuesta. Lorenzo left the group in an early stage of the application.

Main developers of the application. They will develop the whole application and hence they will improve their teamwork capacity and coding skills.


José Emilio Labra Gallo and Pablo González González

They will supervise students work, make sure they are going in the right direction and help us if necessary.


Anyone using the application.

Users will be the ones using the application so they have to find it easy to use, intuitive and practical.


Empathy.co built the commerce Search & Discovery platform for trust. With over 150 Developers and Search Engineers.

They are interested in the project, especially in the part that deals with SOLID Pods because they are used and are important in their working area. Also to offer students business practices

2. Architecture Constraints

2.1. Table 1. Technical Constraints

Constraint Explanation


The React Framework will be used to implement the frontend side of the application.


We are using TypeScript as the programming language for the whole project: both front and backend. For the restAPI we will use a combination of Express.js with Mongoose and Node.js. While in the webapp we will use React and MUI as our main tools.

SOLID and Inrupt

SOLID specifications are required to preserve customer’s privacy. Inrupt are the creators of most of the implementations to work with the previously described specifications.


The version control is managed through Git and the repository is hosted in Github. Not only that, but also Github allows us communicating and organizing the project

Continuous Integration System

We will use Docker for us to deploy the application. Also a virtual machine allocated in Azure will be handy. Further information can be found in the next sections.

2.2. Table 2. Organizational Constraints

Constraint Explanation

Size of the team

The team is made out of six people, in case someone leaves we will a bit compromised. Indeed, one of the members left the group.


Different scenarios will be taken into account to test a correct behavior of the app. Some different techniques will be used to test the application with the higher-the-better coverage.


We will discuss the organization of the to-do tasks in a meeting at each laboratory class. In case we need to arrange an extraordinary meeting, we will have to fix our schedules as we do not have the same timetables. Few extraordinary meetings took place: information about the meetings can be found here.


Team members have different experience when working with the diverse technologies we are using. However, it is the first time we are creating a real life project.

Working as a team

It is the first time for every member of the group we work together. More in more, some of us did not even met before.


A good coordination must be carried out by each component of the group to accomplish all the objectives proposed.

Due dates

For sure we have to stick to some deadlines for us to deliver our project. This depends on the evaluation of the subject: First delivery due by February 22, 2022, while the second is by March 14, 2022. The third will be April 04, 2022 and lastly May 04, 2022.

2.3. Table 3. Conventions

Constraint Explanation


Any person speaking English must be able to interact with the application and successfully complete any task in it: i.e calculating the shipping costs of a certain product to be delivered to a destination.

Clean Code

The code conforming the application must be well written and clean, so it is easier to understand and work with (maintainability in mind).


The documentation must be created by following the Arc42 method: so it is clear, simple and effective.


The application must be easy to navigate through so any user interested on using it can do it easily. Regardless any disability.

Programming Language conventions

We should follow the conventions of the programming languages we are using. Some of those are the JavaScript conventions.


The application must follow the Solid specifications.

3. System Scope and Context

3.1. Business Context

Entity Input Output


User will receive the service provided by the app.

The user will create the pod and store there their information and also it will manage the app to order products to buy.


The app will display information stored in the database and show it to the user. Also it will receive the information from the user using the PODs.

It will make requests to the RestApi in order to get information about users, products, orders, etc. Also store the orders done by the users.


From the app, the api will receive requests to get information stored in the database and the database will return the result of performing queries.

The api will send queries to the database and convert the response received in order to send back the information in a proper way for the WebApp.


The database will receive queries to get information (products, orders, users,…​) from the RestApi.

It will return the result of performing the queries received.

Solid PODs

It will receive petitions from the WebApp to get information about the users.

Will return users' information, mainly the addresses to calculate the shipping costs for orders.

3.2. Technical Context

For this app we are using:

Technical Interface Description

SOLID specification

Architecture that determines the structure of the data management of the project. Data is decentralized and stored in a secure way on PODs.


Data management unit used to store confidential and personal information according to the SOLID architecture.


Language used to program both the user interface and the backend. It was created by Microsoft as an enhancement to JavaScript.


Library to ease the - frontend - programming of the application.

4. Solution Strategy

4.1. Technology Decisions

4.1.1. Technology Stack

In order to develop the application and fullfil the constraints we decided to use the following technologies:

  • MongoDB: we chose to use MongoDB during our last meeting on the 14th of February. Also Mongoose for simplifying everything up.

  • SOLID specification: lets people store their data securely in decentralized data stores called POD.

  • React.js: is a JavaScript library for creating UIs for web applications that is easy to learn.

4.2. Top-level Decomposition

4.2.1. IDE

Our choice is Visual Studio Code mainly because is available for many platforms such as Windows, MacOS or Linux and via plug-ins it supports many programming languages and can be easily enhanced. Git is a built-in feature included for version control.

4.2.2. Diagramming tools

We are using PlantUML for creating the diagrams of the documentation.

4.3. Approaches to achieve top quality goals

Quality goal Scenario Solution approach

Privacy and Security

The user will feel safe while using our product as his data will be stored as he pleases.

We will use SOLID pods in order to achieve this. As we only manage the information that the user wants to share in his POD. We will aim for solving problems that may compromise the robustness and security of the application.


The user will perform the task he wants to do without any trouble.

The use of CSS and JS frameworks that are pre-configured with that in mind. More in more, we will take advantage from the knowledge we earned from other subjects like SEW (Software y Estándares para la Web). Some techniques such as metaphors or conventions, will be used.


The code we write will be easy to read and modify. No spaghetti code or any kind of code smells.

We will implement design patterns and follow code conventions in order to achieve a clean code. More in more, we will write code with tests in mind, covering more than the 50% of the project.


The project will be accessible for everyone to read it. This will include future students.

By means of a public repository anything from our project will be available for everybody.

4.4. Organizational decisions

We have taken the following organizational decisions:app-name:

  • Language: the whole project, including: the code, documentation and conversations among the team members - that includes: issues and other chats - will be in our shared language: English.

  • Issues: even if private chats are a good tool for solving quick doubts, anything apart from that will represent an issue in Github. This way, anyone can see what we discuss about.

  • Kanban: by means of this tool we will be able to plan the development process of the application. More in more, Github has a built-in option for that purpose.

5. Building block view

5.1. Level 1: Whitebox of the Overall System


DEDE application is the general structure of a system in which users will have the possibility to send their deliveries to any place they want and check the state of the orders. All the data that belongs to the user is stored safely in their PODs.

Contained Building Blocks
Name Description


Client of the application which will interact with it.

DEDE application

System developed to be used by the users. Through it information in the PODs will be taken.

PODs service

Has the aim to access each user’s personal POD.

5.2. Level 2


Shows how the application will work internally in general terms. The client, through the user interface, will get the data requested by using the DAL (Data Access Layer).

Contained Building Blocks
Name Description

User Interface

The user will interact with this UI to request any information about the deliveries or request any service. This means, the user will be able to perform any task in our system through this.

Data Access

The layer that will provide and request information from and to the PODs and the Database.


Database used to stored the minimum data as possible from the users. Only the street address will be stored, as in a real life e-commerce shop, we must store it.

5.3. Level 3


Detailed structure of the system. Focused on the components of the User Interface and Data Access.

Contained Building Blocks
Name Description


Sections of the application where the user is going to interact with the system.


Initial screen of the application. A welcome message is going to be displayed as well as the featured products.


View where all the products are shown. Here the user is going to be able to interact with them through a search field, filtering, sorting and pagination.

Shopping cart

The user has a shopping cart where he will see the products previously selected and change the amount of it (number of desired products to order).


Here the user will log-in into their personal account. In case they have created one previously.


Allows the client to create a new account for the application. This process will take place only once for each user.


Here the user can find any information related to their orders. Such as its state or details.


It logs the user out from the application.


At this point, the user can perform a purchase of the desired products.


The application resquest the RestAPI for the information needed. Receiving a response from MongoDB.

PayPal API

API from PayPal used in the checkout for the users to pay their purchase. In case this is performed successfully, an order will be generated.

6. Runtime View

6.1. User adds item to their shopping cart

Once the user logs-in, they can select any product they want and add them to their shopping cart.

Add Item Diagram

6.2. User confirms their shopping cart

Once the user feels happy with the products selected, they can confirm the purchase.

Cart Confirmation Diagram

6.3. User accepts the final price

Once the user sees the final price, including delivery, they must accept it. Then, the system will prepare the package for delivery.

Finish Purchase Diagram

6.4. User checks orders previously performed

A logged user can always look at the orders they have previously done.

Review Orders Diagram

7. Deployment View

7.1. Infrastructure Level 1

07 DeploymentView

For developing and testing, the execution environment will be running on the maching of each student. But, at the production stage, it will be deployed in a Dockerized environment hosted on Azure. Our goal is to have a correct understanding of Docker: the infrastructure over which our system will be deployed.

Quality and/or performance features

The performance on the deployment build will depend on the user’s internet connection as well as on the Azure servers used for the deployment of the app. Since those factors are out of our hand, we can do nothing with that. But the performance of the application can be maxed out with some coding approaches - then - privacy and security will be our main concerns for achieving the best and securest user’s experience.

Table 1. Mapping of building blocks to infrastructure
Element Description


The frontend of our application. It will be rendered by a web browser which will be executed ont the user’s device.


The back-end of our application. It will run on the Azure server.


Database chosen for the application

POD provider

Solid PODs will be provided by solidcommunity.org or Inrupt.

Carrier API

API created to calculate the costs of the shipping for different carriers.

8. Cross-cutting Concepts

8.1. Domain model


8.2. Security

Security is a very important concept in the context of a system. As we are managing information from users, it is important to ensure that the information is safe and that the system is not compromised. So, we decided to store in our system the minimum information necessary and obtain the other from the PODs. Also we decided to encrypt the users' passwords, if any.

Also, we added security in the backend to prevent unauthorized requests to the RestAPI, as well as for preventing the execution of malicious code.

8.3. Testability

In order to ensure the correct functioning of the system, we decided to implement unit tests for most of the components. Also we implemented e2e tests to check that the full system is working properly and that the user experience is good.

9. Design Decisions

9.1. Accepted decisions

Those are the different decisions we have taken for developing our project. They are ordered by importance:

Architectural decision Advantages Disadvantages Link to the ADR


Solves one of the hardest inconveniences of using JavaScript: dynamic binding. This project is increasing its popularity among developers: probably the future of the web.

None of us has ever used this programming language. Indeed, we are not experts in JavaScript neither.

This decision was not taken by us, we were told to use it in the project’s assignment.


Aimed for simplifying the Frontend development process. Well documented. Developed by one of the biggest tech-companies: Facebook.

Not only we are not experts in TypeScript, but we aren’t familiarized with this library neither.

This decision was not taken by us, we were told to use it in the project’s assignment.


NoSQL database that is easy to work-with and integrate using TypeScript. Plenty of resources online.

Transactions are not supported. Stores data by using high memory resources.

ADR #3


However, we will use it in other courses: SDI, so it will become easier with the time. More in more, we need a backend framework allowing us to code faster. Becoming a trend this days. Highly used in companies outside.

We have to learn it from scratch: we have never worked with it. We are not as familiarized with JavaScript.

ADR #6


Express is easy to use, minimalist and works well with the technology stack we have chosen: MERN.

It’s the first time we are working with Express.

ADR #5


Makes working with MongoDB and JS way easier.

We have never used it.

ADR #8

Visual Studio Code

Extremely easy to use. Lightweight and highly customizable. Available for many operating systems. Another advantage is the fact that is widely used in real-world project.

We need to install a bunch of plugins for us to be able to develop the project in a more comfortabe way. More in more, we have to agree which of them we are using, so that everyone has the same UE (user experience).

ADR #2


Works just fine with Asciidoc. We can share diagrams in a minimal way: few lines of code; images are way heavier.

Not as easy to use as a graphical application.

ADR #7


We all write code in a different manner, having a tool that manages the formatting is way too handy

Custom formatting is not allowed unless you tell the plug-in to do it

ADR #9

Carrier API developed by ourselves

We will know how the application works so the process of understanding it will be avoided.

We will have some extra work as we have to develop the API for ourselves.

ADR #10

Bing Maps (Static)

We want to allow the user have a view of the route his package will travel, Bing Maps provides plenty of useful tools for doing so. More in more, we have an student account!

The more functionalities an API has, the complex it becomes. This is no exception.

ADR #11

Geoapify (Dynamic)

We want to let the user choose Pick UP locations as one of the shipping methods. Geoapify provides all those functionalities out-of-the-box. Including integration with dynamic maps and markers. The free-plan has also plenty of features, more than needed.

Having that said, you have to create your own queries for you to choose the locations and customize it a little bit.

ADR #12

Application hosting

Users all around the world will be able to connect to our application!

It’s the first time we do this process, that is, some troubles are arising. More in more, we have never worked with Docker.

ADR #13

Orders resume

Users will be able to download a PDF with a resume of the order after making it (and on their dashboards)

We had many problems while trying to acomplish this feature, with creation of PDFs, sending emails and package installations (as stated next)

ADR #14

9.2. Deprecated decisions

Some decisions we made during the development of the project, but that were reconsidered:

Architectural decision Advantages Disadvantages Why we reconsidered it Link to the ADR


Using this Language that we all have been using for so long we can be assured that there will not be any of the mistakes that comes with learning a new language..

Its popularity is decreasing with the time. Nowadays other stacks are more popular; such as those that are based on JavaScript.

We believe using one and only language will be more handy than using several: one for the frontend and one for the backend.

ADR #1

10. Quality Requirements

10.1. Quality Tree

Quality tree

10.2. Quality Scenarios

In this section, point 1.2 is being extended, describing them all with a different perspective in mind:

Quality goal Motivation Usage scenarios Change scenarios Priority


We must protect data from users. This means, application will only take essential data. Not only that, but also in a decentralized way.

Data from users will be retrieved in a decentralized way, from the user’s pod. Only the username, password and street (for us to know where we have to deliver the package) will be stored. In the sign-up form and checkout the data is not stored, but retrieved from the POD.

We had to change the way we implemented the sign-up form and create a new checkout process where data is retrieved from the POD. This is strictly related to the usability scenario as we have to refactor those sections of the application in such a way that a user with no experience will be able to successfully perform any task.



It won’t matter the usability, nor the overall aesthetics of the applications if the user leaves the site as it won’t load as fast as he expects. More in more, there’s nothing more frustrating than waiting for something to load. This means, user interaction must be done as fluent as possible.

We will aim for the application to load in less than 1.5 seconds; indeed, 47% of the internet users expect a site to load in 2 seconds or less, so we are focusing in doing it better than the average.

We will have to refactor large pieces of code for us to have the best performances possible: one example is using pagination for the shop not to load all the items at once.



The user won’t purchase any item if he is not able to reach the shopping cart, or have some feedback for that product from other customers.

We aim for 90% of the users to be able to complete any -separate- task in less than 2 minutes, without any previous knowledge of the app.

We have included a rating system for the application. This way the user will have a measure of the quality of each item we offer. Not only that but we have also included some loading effects in case we are waiting for a response from a third party system.



We wont be able to develop a good product unless data is stored in a secure place. If the user doesn’t trust in our site, he won’t purchase any item: just leave the app.

Data must not be accessible for any third parties. Data from users will be stored in a secure system.

Highly related to the privacy requirement, we had made plenty of changes for the application to be as secure as possible: one example is preventing NoSQL injections from happening from text fields in forms.



Errors from the application have to be handled by the application itself, it shouldn’t crash!

The user will be unconscious from system crashes happening. In case some error takes place, it will be properly handled.

A big effort will be put into preventing errors. This is strongly related with the maintainability part, where implementing a feature is much more than making it work.



Modifications will take place, so we have to enforce ourselves to code in such a way that maintaining our code will be an easy task.

Software industry averages 1-25 errors per 1000 lines of code. We will aim for higher excellence-ratios: 0.5 defects per 1000 lines of code.

A higher effort will be devoted when implementing a new feature but it will be highly rewarded when modifications take place!



We are developing in a green field: Solid PODS. This means, we expect no one else will take as much effort as we did for implementing our system. Our code is available in a repository with plenty of documentation.

The whole project, including all the components: code, documentation…​ Must be uploaded to a public repository, for it to be accessible to anyone in any place.

A public repository with every discussion, issue or decision recorded.



The application will be available for any kind of device. Users surf the internet in plenty of different devices: cell phones, tablets, desktop computers, laptops…​ Even wearables!

We will make the user experience as good as possible for the more different devices as possible.

We have to put an effort on making our front-end responsive for it to work with any device.


11. Risks and Technical Debts

We have identified these risks and technical debts we might face during this project. They are ordered by priority from higher to lower.

11.1. Risks

Risk Brief description Measures we are taking against it

Lack of knowledge of SOLID

It’s a new technology and we have never worked in any product of this kind. That is, we have no idea of how to work with it. It is not quite easy finding the documentation we needed and there are not quite many examples.

We did our own research and found a library that works just fine. However, before doing so, we needed to understand the technology itself first.

Lack of knowledge of many of the tools

We have not quite much experience working with Typescript, React, Node.js, Docker or Web testing.

Those software products have a nice documentation and - once you understand them - they are easy to work with. Probably Docker was the one we had more struggles with. However, we make this separation between SOLID and the rest of tools, as probably we put the same effort on researching for the first as with the second stack (whole).


We are limited by the deadlines of this course.

We have to put an effort on managing our schedule as good as we can.

Git and Github

We have a limited experience working with git and some troubles may arise from this. Indeed, we lost some work because a merge that was not properly performed.

As it is one of the most important tools a developer should know, we must understand better who it works. We have to study and learn - probably by try and error - this technologies: git and Github.

First time we work in such a big team

Having a group of 6 members has some benefits: you can develop a bigger project. But with some drawbacks regarding organization.

We have to make use of some tools such as Kanban or Issues for us to manage the project and communicate.

11.2. Technical debts

Technical debt Brief description


There are some known issues regarding SOLID APIs that - indeed - we faced during the development of this project. One example to that, is the page redirection on refresh. If you do so, you will notice that you are redirect to the login page as soon as you refresh the page. That is caused because SOLID login features work like that: they store in some kind of cookie the redirection page after performing the login. As handleIncomeRedirect calls login, it will perform the exact same behavior as the previous execution. They are dealing with this issue and information can be found: #1647 or #1473.

Client internet connection

In case the user has a weak Internet connection - and the use of different services we consume from external APIs - the application will run quite slowly. This is an issue involving every application has. We made the decision of using different services, this cannot be undone.

Services going down

If any of the services we consume goes down, that is, we have a strong dependency with external APIs we have no control of. If Inrupt, Bing, Geoapify or any other API fails, some of our features won’t work as intended.

12. Glossary

Term Definition


Set of programming code that enables data transmission between one software product and another.

Acceptance tests

A quality assurance process that determines to what degree an application meets end users' approval.

Continuous Integration

Practice that consists on introducing integrations of a project automatically - very often - so bugs can be detected as fast as possible.


Software platform which allows to create, test and implement applications as fast as possible.


Process by which activities regarding planning and decision making are distributed or delegated away from a central, authoritative location or group.


A document database with a flexible schema.


JavaScript library which allows to define schemas for the MongoDB database.


Secure personal web servers for storing data.


Open-source JavaScript library that is used for building user interfaces.


Architectural style for an application program interface that uses HTTP requests to access and use data.

Solid specification

Proposed set of conventions and tools for building decentralized social applications.


A syntactical superset of JavaScript which adds optional static typing to he language.


Someone who operates the application.

Unit testing

A software development process in which the smallest testable parts of an application are individually checked for proper operation.


A client-side and server-side software application in which the client runs or request in a web browser.

13. Testing

13.1. Unitary testing: WebApp

We made use of Jest and React testing library for testing the WebApp part of our project. We tried to take into account several tips and good-practises for testing by Kent C Dodds, creator of the react testing library.

We needed to verify that isolated parts of DeDe worked as expected by rendering and trying all the possible scenarios. In some cases it became difficult or even impossible to do. Unitary testing has difficulty since it has to be tested without dependencies and to do so, some methods must be mocked.

It was neccessary to add the 'data-testid' to some inputs or use the querySelector function to retrieve the components to be tested When the component relied on asynchronous API calls, we mocked their implementation and also the resolve of the promises resulting.

In the end, we have 80 tests distributed in 42 different suites, hitting a 71% of the available code.

13.2. Unitary testing: RestAPI

For testing that our RestAPI was working as expected, first we created a test database so that way it didn’t mix with the production one.

The approach taken was to made different requests to the RestAPI and comparing the expected status code to the one of each response. That way we can verify that the behaviour is the expected one, and in the cases that some data may be retrieved, some checkings are also made.

In then end, we have 41 tests distributed in 4 different suites, hitting a 98% of the available code.

13.3. Integration testing

We used Jest and Cucumber to perform integration testing in our app. Thanks to cucumber, we could design integration tests following the syntax "Given, When, Then". This allowed for better understandability of the code as well as easier debugging.

As our app relies in some external technology, SOLID PODs, it wasn’t impossible to mock the login so only some funcionalities could be tested. We manage to modify some http request to store the webId neccessary to get data from the database, but some conditions on our code avoids not verify users to access some views, therefore many things couldn’t be tested

In the end we manage to have 3 e2e tests:

  • Feature: Getting products from DB

  • Scenario: A user enters the webpage

    • Given A user on home page

    • When I go to shop section

    • Then Products from the DB are displayed

  • Feature: Getting orders of a user from DB

  • Scenario: A logged user wants to see its orders

    • Given A logged user on the app

    • When I go to orders tab on dashboard

    • Then My orders from the DB are displayed

  • Feature: Getting reviews from DB

  • Scenario: A user enters a product info and sees the reviews

    • Given A user on shop

    • When I enter on a product page

    • Then Info and reviews of the product are requested and displayed

13.4. Load testing

Load testing is a process of testing the performance of a system by simulating a large number of users accessing the system. This tests are important to ensure the performance quality goal defined previously. In our case, to perform this test we used Gatling tool. This tool allows to record an action in the website and later simulate this actions but with a large number of users. Finally, we can see the results of the test and the average time of all the requests and a more complete report of the test.

In our case, we managed to achieve a load test of the app with a 20 users per second and a total duration of 10 seconds. The results obtained reflect that the average time of the requests was in all the cases less than 1200ms. This is a good result since we have a lot of users accessing the app and the average time of the requests is less than 1.5 seconds. Moreover, the 60% of the requests take less than 800ms.

About arc42

arc42, the Template for documentation of software and system architecture.

By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.

Template Revision: 7.0 EN (based on asciidoc), January 2017

© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.