GITBOOK-20: No subject

documentation/developers-guide/contributing-to-the-code.md

@@ -0,0 +1,18 @@
+---
+icon: list-check
+---
+
+# Contributing to the code
+
+We generally follow the [gitflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) workflow model.  If you’re not familiar with it, the general steps are
+
+1. Create a feature branch in your local depository and make your changes.
+2. Push your branch to the remote repository on Github.
+3. Open a pull request.
+4. The rest of the team will review the pull request and either approve or request changes.
+5. If changes are requested, make changes and push.
+6. Project maintainer will merge the branch, closing the pull request and deleting the remote branch.
+
+### Git
+
+If you are inexperienced with Git or need a refresher please visit our [Git Quick Start Guide](https://github.com/ajhollid/bluewave\_collaborative\_git) to help get up to speed.  If you’d like to go further in depth, this [Git for Professionals](https://youtu.be/Uszj\_k0DGsg?si=6rOWEQOMxmwhnb-K) is a good resource.\

documentation/developers-guide/general-project-structure.md

@@ -0,0 +1,48 @@
+---
+icon: diagram-project
+---
+
+# General project structure
+
+The Uptime Manager product uses the MERN stack, which is to say that the project uses:
+
+* React on the Front End via Vite
+* Express on the Back End via NodeJS
+* MongoDB for data with Mongoose for data access
+
+### Front end
+
+The project uses the [Material UI Components](https://mui.com/material-ui/all-components/) (MUI) which allows us to build with a minimum of fuss.  The library is highly customisable and the project makes heavy use of the Theme concept and follows MUI’s paradigm to avoid writing excessive CSS.\
+\
+The overriding goal on the Front Eed is to write maintainable and scalable code.  If you find yourself writing lots of CSS to customize a component or are having to set a value often like font size or color you probably should be using the theme.\
+\
+When making changes to the Front end please always keep future developers in mind.  Will they know how to make changes to your code?  Is your code modular?  If a dev makes changes elsewhere in the app will your component be affected?  If the team makes a theme change like font size or primary color will your component be updated as well? 
+
+### Back end
+
+The back end of this project is not especially complex and is built around Express.  The back end is a RESTful API and the [documentation can be found here](https://uptime-demo.bluewavelabs.ca/api-docs).
+
+The application consists of several main conceptual models:
+
+1. User
+2. Monitor
+3. Check
+4. Notification
+
+There are several supporting models as well.
+
+1. AppSettings
+2. InviteToken
+3. Team
+
+All requests are based around these models and manipulation of their data.\
+\
+In general the models interact in this fashion:
+
+* A `User` has many `Monitors`
+* A `Monitor` has many `Checks`
+* A `Monitor` has many `Notifications`
+
+A `User` can create a `Monitor`.  `Monitors` are enqueued in the `JobQueue`, and their target URLs are queried when they are dequeued.  When the query is complete, a `Check` is created that records information about the request.\
+\
+A `User` may attach a `Notification` to their `Monitor`, if the `Monitor`’s status changes then the user will be notified by the method specified in the `Notification`

documentation/developers-guide/high-level-overview.md

@@ -0,0 +1,57 @@
+---
+icon: dove
+---
+
+# High level overview
+
+
+
+The figure below shows a high level architecture of the Uptime Manager.
+
+<figure><img src="../.gitbook/assets/Screenshot 2024-10-04 at 9.28.27 AM.png" alt=""><figcaption></figcaption></figure>
+
+### Typical auth request overview
+
+The following diagram describes a typical request to the /auth endpoints.
+
+<figure><img src="../.gitbook/assets/Screenshot 2024-10-04 at 9.30.30 AM.png" alt=""><figcaption></figcaption></figure>
+
+### Typical monitor request overview
+
+The following diagram describes a typical request to the `/monitors` endpoints.
+
+<figure><img src="../.gitbook/assets/Screenshot 2024-10-04 at 12.13.55 PM.png" alt=""><figcaption></figcaption></figure>
+
+### JobQueue
+
+The heart of this application is a `JobQueue` class that wraps a BullMQ `Queue`. \
+\
+A `Monitor` is considered a job, when one is created it is enqueued in the `JobQueue`.\
+\
+Jobs are handled by a pool of workers in the `JobQueue` and their tasks are executed in the order in which they are enqueued.\
+\
+Workers are scaled up and down based on the jobs/worker ratio as jobs are enqueued and dequeued.
+
+#### **High level overview of the JobQueue** 
+
+<figure><img src="../.gitbook/assets/Screenshot 2024-10-04 at 12.17.44 PM.png" alt=""><figcaption></figcaption></figure>
+
+### SSL
+
+SSL is handled by LetsEncrypt and Certbot.  This works by Nginx and Certbot sharing the same volume where the certificates are held.  The following snippet from the docker-compose.yaml file shows how this works.\
+
+
+<figure><img src="../.gitbook/assets/Screenshot 2024-10-04 at 12.20.52 PM.png" alt=""><figcaption></figcaption></figure>
+
+Please see [this guide](https://phoenixnap.com/kb/letsencrypt-docker) for more information on this setup.
+
+\
+\
+\
+
+
+\
+\
+
+
+\