Merge branch 'master' of https://github.com/Arquisoft/lomap_en2b

.github/workflows/lomap_en2b.yml

@@ -35,7 +35,6 @@ jobs:
     - run: npm ci
     - run: npm test --coverage --watchAll
     - name: Analyze with SonarCloud
-      uses: sonarsource/sonarcloud-github-action@master
       env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
@@ -50,7 +49,9 @@ jobs:
     - run: npm --prefix webapp install
     - run: npm --prefix restapi install
     - run: npm --prefix webapp run build
+
     #- run: npm --prefix webapp run test:e2e
+
   docker-push-webapp:
     name: Push webapp Docker Image to GitHub Packages
     runs-on: ubuntu-latest

docs/01_introduction_and_goals.adoc

@@ -1,9 +1,10 @@
 [[section-introduction-and-goals]]
 == Introduction and Goals
 
-This project consists on developing an application that allows users to personalize a map of their city. 
+This project consists on developing an application that allows users to personalize a map of Brussels. 
 In their map they can add the landmarks they want, like shops, sights or restaurants.
 In addition, users will be able to share their map information with the users they want while restricting other users from seeing it.
+Ideally, this application should easily be implemented for using it in a different city, while it should be interoperable with similar applications.
 
 === Requirements Overview
 

docs/02_architecture_constraints.adoc

@@ -8,7 +8,7 @@ These constraints are the base of the architecture process, and are the roots of
 [options="header",cols="1,4"]
 |===
 |Constraint|Description
-| Solid | _Provided by the stakeholders. A way of building decentralized social apps, it gives every user a choice about where data is stored, helping the privacy of each user._
+| SOLID | _Provided by the stakeholders. A way of building decentralized social apps, it gives every user a choice about where data is stored, helping the privacy of each user._
 | Github | _The development team was given a starting draft of a project in GitHub as a public repository. From then on, all the work related with this project will be tracked and uploaded in this repository._
 | Time | _The application is developed in a semester during a course, that means time is limited._
 |===

docs/04_solution_strategy.adoc

@@ -10,7 +10,7 @@ Up until now, we have made some decisions about the project, those decisions can
 * Map API: Used to plot the map in the application in order to allow the user to do every possible action. The selected API to do it is Leaflet.
 
 . *Decisions on top-level decomposition:*
-* MVC: We are using the MVC (Model-View-Controller) pattern in order to organize the code in a clean and obvious way.
+* N-Layers: We are using an N-Layers pattern of two components: the controller and the frontend. The former can be found in _/restapi/_ and the latter in _/webapp/_.
 * Editor: We are all using Visual Studio Code to work on this project, it is the editor we are used to program in and it has some features that made us work using it.
 * Github: The project is on a public repository as given by the professors of the subject. We are all able to work using it, and the main features of it are the pull requests in order to upload code.
 

docs/05_building_block_view.adoc

@@ -16,11 +16,14 @@ This diagram is motivated by the need of having a clear separation of the compos
 header Architecture of the application
 title Architecture of the application
 
-agent "View"
-agent "Controller"
-agent "Persistance"
+rectangle webapp/src/ {
+    agent "View"
+}
+
+rectangle restapi/ {
+    agent "Controller"
+}
 
-"Controller" -> "Persistance"
 "View" -> "Controller"
 @enduml
 ----
@@ -31,9 +34,7 @@ As seen, the different components are the following:
 
 * *View*: The view layer is composed of those elements that the client will interact with; it includes the React code, CSS sheets and the client-side code.
 
-* *Controller*: The controller layer will ensure a proper communication the client and the server.
-
-* *Persistance*: The persistance layer handles data retrieval and persistence logic.
+* *Controller*: The controller layer will ensure a proper communication the client and the server. It currently handles also persistence.
 
 ==== View layer
 
@@ -45,11 +46,9 @@ As already explained this layer will be composed of those components that the us
 
 Since we are not using interfaces, we will be seeing important components:
 
-* *Map*: This component is one of the most important parts of the application. It returns a working map that can be extended, adding functionality through other components. It can be found in _/webapp/src/components/map_, and can be applied several stylesheets.
-
 * *The main UI*: It is divided in several components: the left bar, the navbar and the rightbar, each one with its one subfolder in _/webapp/src/components_.
 
-* *The pages*: These are the React components that compose the web. They can be found in _/webapp/src/pages_.
+* *The pages*: These are the React components that compose the web. They can be found in _/webapp/src/pages_, in their own folder.
 
 ===== Open Issues/Problems/Risks
 
@@ -63,66 +62,8 @@ The controller layer will handle internal communication between the view and the
 
 ===== Interfaces
 
-No interfaces have been defined yet.
-
-===== Open Issues/Problems/Risks
-
-No issues, problems or risks are known.
-
-==== Service layer
-
-===== Purpose/responsability
-
-The service layer will handle communication with the persistence layer.
-
-===== Interfaces
-
-No interfaces have been defined yet.
+* *The controllers*: they handle the logic and the persistence of the application. They can be found in the _restapi_ folder.
 
 ===== Open Issues/Problems/Risks
 
-It is important to consider how we will handle communication between the server and the pods, and if there will be any difference to communicating with the database.
-
-==== Model layer
-
-===== Purpose/responsability
-
-The model layer will handle internal logic.
-
-===== Interfaces
-
-No interfaces have been defined yet.
-
-===== Open Issues/Problems/Risks
-
-No issues, problems or risks are known.
-
-=== Level 2
-
-==== Persistence layer
-
-Currently, the only layer we have somewhat structured is the persistance layer. 
-
-[plantuml,png, id = "PersistenceLayer"]
-----
-@startuml
-
-header Structure of the persistence layer
-title Structure of the persistence layer
-
-folder "Persistence layer"{
-agent Database
-agent "User pod"
-}
-agent "Service layer"
-Database <-- "Service layer"
-"User pod" <-- "Service layer"
-@enduml
-----
-
-As you can see, it is divided in in several two components: the pods and the database.
-
-* The pods will store the user data.
-* The database.
-
-What the database will store and what will also be included in the pods is yet to be decided, as we are trying to reach a compromise between storing mostly everything in the pods (which will significantly harm performance) and storing mostly everything in the database (which will harm privacy and does not follow SOLID).
+No issues, problems or risks are known.

docs/07_deployment_view.adoc

@@ -46,4 +46,4 @@ Although we have yet to choose the operating system that will run it, it will pr
 
 ==== The database management system
 
-We have chosen to use MongoDB. This decision was considered due to the experience of one member of the group using MongoDB through Mongoose, as well as using Typescript to run the product and, thus being posible to manipulate the data directly.
+We have chosen to use MongoDB. This decision was considered due to the experience of one member of the group using MongoDB through Mongoose, as well as using Typescript to run the product and, thus being posible to manipulate the data directly using JSON notation.

docs/09_design_decisions.adoc

@@ -10,4 +10,18 @@
 | React Libraries | In order to make our life easier while the development of the application, we made the decision to include some libraries in the project. These libraries we used are listed on issue #42.
 | SonarCloud | This has been presented to us on one laboratory, it measures how many lines of code are being tested using TDD.
 | Cucumber | In order to make the mandatory BDD tests, we are going to use a tool that we somewhat knew from other courses in the degree, used to make the acceptance tests.
+| Prioritize | As we have seen until the third deliverable, we are having some trouble on some things. As a result, we have decided to focus on the more functional requirements on this last deliverable.
+| MongoDB | The application main place for storing information is still Solid. We made the decision to store in a database on the cloud with the users that log into our app. Each time a new user logs into the lomap application, its username and webID of solid are stored in our database in order to help the interactions of users on the app, making sure each user can only see the friends that have logged into the app.
+| Landmarks | We have been dealing with a problem related with the persistence of the landmarks on solid, as a temporal solution, we decided to store them in the mongo database, which in the future will be changed.
+| Friends | We had a little discussion over this topic on a meeting, reaching an agreement over only allowing the users to add friends via lomap. As the way of adding friends is quite special on this app and is done via Solid, we decided not allowing to cancel a friendship via lomap, as we thought it was something external to lomap, more related only with Solid.
+| Coordinates | When we were dealing with adding landmarks, we were trying to add coordinates by writing the number, and we are changing our inicial approach to be able to click on the map and retrieve the coords of that point.
+| The old map interface | In prior versions, we used a custom _Map_ component to handle the map logic. This component has been discarded in version 1.1 due to it becoming an obstacle when implementing event handling related to the map.
+| Monitoring and profiling | We are quite short of time so we decided to try to improve the tests and the features of the app rather than recording our perfonmance, as it was optional, we thought we should put all our focus on delivering a nice app.
+| Puppeteer | We think it was the easier way in order to implement the necesary e2e tests for the application, we considered other options seen in class and that we tried searching for, but finally decided to use puppeteer.
+| Use of pods and interoperability | We as a team participated in the debates on the other github issues about the interoperability, not arriving to a very clear conclusion. As a result we spoke to some colleagues in order to try and make our applications interoperable, causing this decision to change our approach of storing landmarks on the pods.
+| Way of storing landmarks | Connecting with the previous decision and probably as a result of having trouble with storing information on solid through the restApi, we decided to stop that approach and start dealing with writing and reading from the pods from the webApp.
+| Tests | On the lasts days we arrived quite short of time and we could do everything we were requested but not all tests run correctly, this is not due our application, because obviously we've tested everything via executing our app, but the setup of some tests of the restApi may not be working properly.
+| e2e Tests | We have been dealing with a problem on these tests almost for 3 weeks before the final deliverable. The tests start executing perfectly and the login is done as it should, but when the home page must load, the page is not loaded in a redirect, that outside testing works perfectly, for some reason we did not realised. We decided to keep the code related with the tests as we think it has to be ok, although the test do not succeed.
+| Structure of the app | We decided to keep a leftBar in order to navigate through all the pages of our application, as a result of this decision, we needed to place different maps in different pages of the app, as we don't always keep the same instance of the map.
+| Structure of the presentation | We have decided to focus on different things in the presentation on the final day, we will explain some of the problems we had, as well as revising the main structure of our application and making a draft on how to navigate on our app via showing how we use it. Just in case the day of the presentation the app does not work, we are preparing a short video of how it can be used too.
 |===

docs/12_glossary.adoc

@@ -4,7 +4,7 @@
 [options="header"]
 |===
 | Term         | Definition
-| SOLID     | SOLID is a web decentralization project where the users have control over their data. It is led by the inventor of the WWW, Tim Berners-Lee. SOLID guarantees that users decide what and with whom they should share their data. 
 | N-Tier architecture | Client–server architecture in which different layers are separated allowing the development of flexible and reusable applications.
-| MVC architecture | Architecture style that separates the application data, the UI and the business logic in three different components.
+| SOLID     | SOLID is a web decentralization project where the users have control over their data. It is led by the inventor of the WWW, Tim Berners-Lee. SOLID guarantees that users decide what and with whom they should share their data. 
+| POD | Secure personal web servers for data. When data is stored in someone's Pod, they control which people and applications can access it.
 |===

restapi/controllers/landmarks.ts

@@ -7,7 +7,7 @@ router.post("/friend", async (req: any, res: any) => {
     try {
         console.log("POST /landmarks/friend");
 
-        const results = await Landmark.find({webId: req.body.webID});
+        const results = await Landmark.find({webId: req.body.webID.toString()});
 
         res.status(200).send(results);
     } catch (err) {
@@ -19,8 +19,8 @@ router.post("/", async (req: any, res: any, next: any) => {
     try {
         console.log("POST /landmarks/");
         const landmark = Landmark.create(
-            {name: req.body.name, category: req.body.category, latitude: req.body.latitude, 
-            longitude: req.body.longitude, webID: req.body.webID});
+            {name: req.body.name.toString(), category: req.body.category.toString(), latitude: req.body.latitude.toString(), 
+            longitude: req.body.longitude.toString(), webID: req.body.webID.toString()});
 
             const result = await landmark.save();
         res.status(200).send(result);

restapi/controllers/users.ts

@@ -33,7 +33,7 @@ router.patch("/", async (req : any, res : any, next : any) => {
     try {
       console.log("PATCH /users/");
 
-      const result = await User.findOne({solidURL: req.body.webId});
+      const result = await User.findOne({solidURL: req.body.webId.toString()});
 
       res.status(200).json(result._id);
     }catch(err){
@@ -59,10 +59,29 @@ router.post("/", async (req : any, res : any, next : any) => {
       console.log("POST /users/");
       res.status(201).json(result);
 
+    } catch(err){
+      res.status(404).json(err);
     }
-      catch(err){
-
+  });
+
+router.delete("/", async (req : any, res : any, next : any) => {
+    try {
+
+      if(!req.body.solidURL){
+        res.status(400).json("No solidURL provided");
+        return;
       }
-    });
+      let id = req.body.solidURL;
+      id = id.split("#")[0];
+
+      const user = User.deleteOne({ solidURL: id });
+      console.log("DELETE /users/");
+      res.status(201).json(user);
+
+    } catch(err){
+      res.status(404).json(err);
+    }
+  });
+
 module.exports = router;
 

restapi/index.ts

@@ -14,6 +14,7 @@ const users = require("./controllers/users");
 const landmarks = require("./controllers/landmarks");
 
 const app = express();
+app.disable("x-powered-by");
 const metricsMiddleware:RequestHandler = promBundle({includeMethod: true});
 
 
@@ -51,7 +52,6 @@ app.use(
       "Required, but value not relevant for this demo - key2",
     ],
     maxAge: 1 * 60 * 60 * 1000, // 1 hour
-    httpOnly: false,
   })
 );