DeDe_en1b

The main point of creating DeDe is to develop a delivery application similar to those that already exist, but which does not store user data in the app’s database. Instead, user hosted SOLID pods will be used.

Functional Requirements

DeDe is a decentralized system that follows the architecture of the Solid Project. This means that users are the ones that own and manage the access to their sensitive information, and not the application itself. To handle this, each user will be the owner of a Solid POD (Personal Online Data Store) from which the required information is extracted if needed.

Although the personal data is handled by the PODs, DeDe will also store general information within MongoDB. The application is written in TypeScript, employing the React framework in combination with Material UI for a more polished appearance.

We identify the following technical interfaces:

We have chosen to use the following technologies:

ON development, the project will match MVC (Model-View-Controller). The separation of responsibilities in layers provides both easier especialization of each member during the development and a better way of treating the data model so that POD and MongoDB information does not intersect.

The primary concern, privacy, is already solved through the usage of the PODs (assuming of course the correct implementation of the access to them). The whole structure of the application is centered around preserving the integrity of the user’s data, so it’s not hard to affirm DeDe will have a high privacy value. Usability is also a major concern and so the application will be built as responsive and accesible as possible. The decentralization of data will also have positive consequences on the security of DeDe, and server-side validation will be provided to check for the legitimity of the user’s operations.

Apart from the periodic Tuesday reunion during the laboratories, a second one has been scheduled every Thursday at 18:00. Thanks to Microsoft Teams, it will be easy to get together and check the progress multiple times during the week. A WhatsApp group has also been created for a more swift communication on the kind of matters that must be resolved quickly or are too unimportant for the reunions.

The use of pull requests is our standard to solicit aproval from the team to add a new feature or improvement to the develop branch. This will also guarantee the quality of the code through the peer review process.

As we are students, we searched for the cheapest provider to run our application. The first one we tried, Oracle, has a free tier for students which includes 2 virtual machines with 1 cpu and 1 GB of RAM without time limt. We deployed our database there and had no issues with performance, but when we tried to deploy our application, the server struggled to run everything smoothly so we looked for an alternative. We found that Microsoft Azures has also a student program which gives us 100$ credit for its services, so we used it to rent a vm with 1 cpu and 2GB of RAM. We kept the database in the oracle server and use the azure one to deploy our application.

To use other Solid providers, it is necesary to have the web encrypted with https because connections from https to http are not allowed for security reasons. To have HTTPS on our web, we used Caddy to configure a proxy server, and registered a free domain name with freenom. Caddy is in charge to serve the content in localhost:3000 to the requests coming from dedeen1b.tk encrypting it first using a SSL certificate from letsencrypt.org. The same thing is done for api.dedeen1b.tk to serve the api.

With this setup, we have now a complete infrastructure for our application.

Both the WebApp and the RestApi are automatically deployed using GitHub Actions. Every time a new realese is made, a script, located in .github/workflows/asw2122.yml, will be executed. This script first runs the tests, and if they all pass succesfully, the docker images will be build and publish to GitHub Packages. Finally, the scripts connect through SSH to the server and deploys the application using Docker-Compose. As tokens, server IPs and other information must be private, we are using GitHub Secrets to store it.

We will store store the user in our non-relational database, provided by mongoDB.

The MVC pattern is the one that will be used to start coding our project, as it is one of the best ways for accessing the SOLID pods using REACT.

Routes for accessing every action will exist, and a model defining the database schema will be defined.

Protocol HTTPS will be used to ensure the user’s secure access, and validation constraints will be present to avoid undesired access.

SOLID pods also provide a mean of security, as each user is the only owner of his/her private information stored in a decentralised way.

An independent login was used to access the administrator page, we considered this decision a mean of improving security on that specific feature, as there will be only one administrator and we don’t want to depend on external providers for performing any of its responsabilities.

The project will be a multi-language application since the beginning of the design, to save expensive future costs in implementing this functionality.

Unfortunately, due to time constraints, the interationalization of the app could not be implemented. DedEx remains a single language application for the moment, written entirely en English.

A notification system will be implemented, in which a user gets a notification that provides relevant information to keep track of the product, such as whether that product has arrived or not.

On the same trend as with internazionalization, time would not let us implement this optional feature. Both these things are now pending to create in next sprints.

We decided to create a Web application supported by the latest versions of the main market browsers (Chrome, Firefox, Edge…​). This online version of DeDe could be ported to a mobile device app easily with REACT Native, a JavaScript framework for writing real, natively rendering mobile applications for iOS and Android.

Because we are choosing to develop a web app from the beggining, we must take careful consideration into making components mobile friendly. This should not be done, it would prove a struggle to adapt in the future.

We chose MongoDB as our Database Management System because its flexible schema allows us to rapidly model the domain and change it with the evolution of the app without any problems. MongoDB stores data in form of JSON so the conversion and interaction between typescript and the database are flawless. Another point in favor is its performance and scalability although in a small application like ours is not strictly necessary. We also chose MongoDB because it gives us a free database in the cloud for developing purposes.

By discarding the use of an SQL database, we are also losing the opportunity to wotk with an schema, and thus, all data validation responsibility falls in the hands of the developers, that is, us. This may prove trying at times, but it is also good to learn new technologies.

Material UI is a free React-compatible library directed at easy creation of responsive components. It contains many default styles for typography, forms, buttons, navigation, and other interface components. It will allow us to create a good frontend with less effort.

We descarded the use of Bootstrap because we felt that Material was more attuned to what we were trying to do with this reactive app. By doing so, we made a lot of design decision fall in the developers hands, making it more customizable but also more diffcult and time consuming to create.

We made use of Jest and React testing library. We tried to take into account several tips and good-practises for testing by Kent C Dodds, creator of the react testing library. He has several blogs and videos for teaching React in action.

Unitary testing had difficulty in the sense that there should not be any dependencies and if they do, they must be mocked for the test.

We needed to verify that isolated parts of DeDe worked as expected and in some cases it got really hard.

The general strategy used was, in some cases, to put a data-testid in the components we wanted to fetch, or query them by text criteria.

When the component relied on asynchronous API calls, we mocked their implementation and used functions like waitFor() or waitForElementToBeRemoved(), in order to wait for the end of execution of those functions.

In other cases we had to wrap elements inside others such as MemoryRouter or ReactNotifications before rendering them with the goal of mounting them properly.

In the end, we have 40 test distributed in 19 suites. We tested the following scenarios:

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

We divided the 8 tests in 5 different suites, who aggregate similar tests. For each on of them, these were the features tested:

The result of running these test is as follows:

Gatling tool was used to perform load tests to the application. Using its recorder functionality we were able to capture a fixed number of requests and reproduce their functionality for every user that was simulated by the program.

Those requests included the use of filters, adding products to the cart, modifying their quantities and perform checkout functionality.

The recorder tool acts as a man-in-the-middle to capture the traffic and requests made, we had to modify the proxy configuration in our browsers for the tool to do the before-mentioned actions properly, losing internet connection meanwhile.

This internet loss made it impossible for us to load test the SOLID login and, as a consequence, the order creation.

An Open Model for user injection was the one used because you control the arrival rate of users, and the concurrent number of users in our web is not capped. We used this injection setup.

An approximate number of 18k requests were made during the test in which 10% of those had a response time between 800ms and 1200ms, and just 1% had a response time above the latter.

During the test there was a peak of 196 concurrent users.

Observing the percentile response time chart generated we can know where in the execution of the recording the requests consume more time and its different distributions. The requests that consume more time in this test would be filter usage, and quantity modification in the shopping cart.

About arc42

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.