DEDE EN_2A

Privacy

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.

High

Performance

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.

High

Usability

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.

High

Security

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.

High

Maintainability

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.

Medium

Freedom

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.

Medium

Students

Á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.

Teachers

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.

Users

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

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

React

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

TypeScript

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.

Github

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.

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.

Testing

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.

Meetings

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.

Experience

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.

Coordination

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.

Language

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).

Documentation

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

Accessibility

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.

SOLID

The application must follow the Solid specifications.

User

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.

webapp

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.

RestAPI

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.

Database

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.

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.

SOLID PODs

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

TypeScript

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

React.js

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

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.

Usability

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.

Maintanability

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.

Freedom

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.

User

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.

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.

MongoDB

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.

Views

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

Home

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

Shop

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).

Sign-in

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

Sign-up

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

Orders

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

Log-out

It logs the user out from the application.

Checkout

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

RestAPI

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.

WebApp

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

RestAPI

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

MongoDB

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.

TypeScript

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.

React.js

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.

MongoDB

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

Node.js

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.js

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

mongoose

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

plantuml

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

Prettier

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

Java

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

Privacy

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.

High

Performance

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.

High

Usability

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.

High

Security

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.

High

Reliability

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.

High

Maintainability

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!

Medium

Freedom

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.

Medium

Portability

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.

Low-Medium

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).

Time

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.

SOLID APIs

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.