adr stuff

model/adrs/ADR001_AUTHENTICATION.md

@@ -1,9 +1,19 @@
 # ADR001
+
 ## Authentication
-Authenticate user actions - don't want users editing or deleting content of other users.
+
+Implementing user authentication for actions on post, patch, edit (anything that changes db).
 
 ## Options
-- Add options here
+
+- No user authentication
+- User authentication
+  - Auth0
+  - OAuth2
+  - NextAuth.js
+
+We picked auth0 as it is a well known and trusted service that is easy to implement and is well tested. Auth0 also has a terraform provider which allows us to integrate it into our IAC for easy deployments/ teardowns.
 
 ## Outcome
-Frontend authentication handled by Auth0. Backend user table added to track user IDs and associate with comments.
+
+Users are authenticated using Auth0. Managed through terraform for easy deployment and teardowns. Cannot run e2e tests on workflow because we do not have permissions in our repository to manage secrets for auth0. This meant that e2e tests can only be run locally.

model/adrs/ADR002_ORM.md

@@ -1,12 +1,16 @@
 # ADR002
+
 ## ORM
+
 Introduce an ORM to reduce coupling between the data and backend layers.
 
 ## Options
+
 - No ORM  
 - Orm
 
 ### No ORM over ORM
+
 | Pros | Cons |
 |----|----|
 | Deveolpers that are more comfortable in SQL can use SQL over an unfamilar package | The syntax and functions are more similar to the code language in use, helping devs understand code easier |
@@ -15,4 +19,5 @@ Introduce an ORM to reduce coupling between the data and backend layers.
 | - | Overall less boilerplate to do some things reduce the amount of code / failure points |
 
 ## Outcome
-Introduced TypeORM on the backend due to the cons of having no ORM being more siginificant than the pros. 
+
+Introduced TypeORM on the backend due to the cons of having no ORM being more siginificant than the pros.

model/adrs/ADR003_ROUTES.md

@@ -1,16 +1,21 @@
 # ADR003
+
 ## ROUTES
+
 Introduce more files to decrease the size of routes.ts and as such improve readability and maintainability of code
 
 ## Options
+
 - All route functions in routes.ts
 - Route functions in files based of their path i.e. /courses goes to courses.ts
 
-### Why choose one file over seperate files
+### Why choose one file over separate files
+
 | Pros | Cons |
 |----|----|
 | All routes are easy to find since they are all in the one file | Easier to search for functionality as question based routes are grouped in questions.ts |
 | - | Having a large file can be hard to read and understand, making it more difficult to understand and debug |
 
 ## Outcome
-Moved the routes to their seperate files to increase readability of the code.
+
+Moved the routes to their separate files to increase readability of the code.

model/adrs/ADR004_INTEGRATION_TESTS_WITH_DB

@@ -2,13 +2,13 @@
 
 ## Integration Testing
 
-This ADR was the decision
-Allowing the test container to verify changes made through the backend by directly communicating with the DB. 
+Connecting the integration tests to the database.
 
 ## Options
 
-- Add options here
+- Leaving integration tests to only verify return HTTP code and response.
+- Allowing integration tests to connect to the database to verify HTTP code, response and changes were made to the database.
 
 ## Outcome
 
-Better test coverage and validation. 
+This ADR was the decision to utilise ADR002 and allow the integrations tests to connect with the database. This allow the tests to verify changes made through the backend by directly communicating with the DB. By implementing this ADR we have increased the maintainability QA and reliability as we can now verify changes made to the database through the backend. This gives developers more confidence in the changes they made and allows for better test coverage.

model/adrs/ADR005_USER_ROLES

@@ -2,10 +2,15 @@
 
 ## User Roles
 
-Authenticate user actions - don't want users editing or deleting content of other users.
+Implementing authentication of user actions. Every post/ patch/ edit action will be associated with a user ID.
 
 ## Options
 
-- Add options here
+- Implement user roles in the database
+  - Regular user and Admin user roles
+- Not implementing roles
 
 ## Outcome
+
+By implementing this ADR, we can ensure that users are only able to edit or delete their own content or content they are allowed to edit. This will prevent unauthorized users from making changes to the database. Frontend authentication handled by Auth0. Backend user table added to track user IDs and associate with comments.
+An improvement we could make is utilising auth0 custom roles/ metadata to manage user roles. This would allow us to manage users completely through auth0 instead of handling it in our backend.

model/adrs/ADR006_LOAD_BALANCERS

@@ -2,12 +2,14 @@
 
 ## Load Balancer
 
-putting lb in front of backend. allows availability. 
+putting lb in front of backend. allows availability.
+This ADR is about putting a lb in front of the backend
 
 ## Options
 
-- Add options here
+- Leaving the frontend directly connected to the backend
+- Connecting the frontend to backend LB which is then forwarding to the backend
 
 ## Outcome
 
-our layered architecture is more available. 
+By implementing this we have increased the availability of our system. Prior to this, if the backend went down we needed to run a full teardown of the entire system so that the frontend could be passed the link to the backend. By using a lb in between the frontend and backend, we do not need to do this. The frontend can be passed the link to the lb and the lb can be passed the link to the backend. This means that if the backend goes down, the autoscaling group can recover it and no other services will need to be restarted.