Home

Welcome to the sdzwa-sensor-dashboard-backend wiki!

The SDZWA Sensor Dashboard backend was built by employing Prisma (Object Relationship Manager tool), Docker, and SQLite components. The frontend is connected to the backend using REST API calls such as POST and GET.

Overall system architecture (frontend + backend) resembles that of the diagram above. The back-end portion of this project involves the SQLite database built and managed using Prisma, that is hosted on a Node.js server (hosted using Docker) and connected to the frontend using API calls for retrieving and updating user and sensor data.

Design Choices

1. Availability - A local datastore that is available and deployable on any device, without connecting to the internet.

2. Simplicity - A simple data model/schema that can be iterated upon, and that supports the sensor-board application's expected API.

3. Security - Basic data security with respect to how sensitive information like passwords are stored, encrypted, and accessed in the database (salted hash encryption, token authorization).

Data Schema

User Table

Column Name	Data Type	Description
user_id	Int	Primary ID to identify the admin user of the application
firstName	String	First Name of the admin user
lastName	String	Last Name of the admin user
email	String	email of the admin user - should be unique
password	String	encrypted string of the password - the password string is not directly stored
salt	String	salted hash of the password that is used for encryption

Sensor Table

Column Name	Data Type	Description
id	Int	Sensor Primary ID used for referencing the sensor within the database
name	String	Name of the sensor that the zoo uses to reference it - it should be unique
description	String	Description or Note that describes the sensor and its function in the zoo
type	Int	What type of sensor it is? - Camera? Thermal? Motion? Weather?
source	Int	The type of the data source that the sensor collects - image (0)? audio (1) ? numeric (2) ? video (3)?
locationX	Float	Latitudinal Location of the sensor in the zoo
locationY	Float	Longitudinal Location of the sensor in the zoo
status	Int	The current functional status of the sensor - idle (0), not active (1), active (2), needs attention (3)
installedAt	Float	The date and time when the sensor was installed at the zoo
updatedAt	Float	The data and time the sensor was last updated
url	String	The url of the storage location where the data collected by the sensor is uploaded

API function templates

Sensor API functions

Function Name	Role
getAllSensors	Gets the information for all the sensors
getSensorById	Gets the information for the particular sensor marked by that ID
getSensorByName	Gets the information for the particular sensor marked by that Name
updateSensorByID	Updates the information for the particular sensor marked by that ID
deleteSensorByID	Deletes the information of the particular sensor marked by that ID
createSensorByName	Creates a new record for the new sensor

User API functions

Function Name	Role
newUser	Creates a record for the new admin user in the database
LoginUser	Validation of credentials for the admin user during login phase
changePassword	Requires the old password authentication to change to new password
getUsers	Gets the information for all the admin users
getUserById	Gets the information for the particular user marked by that user_id
getUserByEmail	Gets the information for the particular user marked by that Email
updateUserByEmail	Updates the information for the particular user marked by that Email
deleteUserByEmail	Deletes the information of the particular user marked by that Email

Future Work

1. Data model/schema can be extended to fit more metadata information about the many different kinds of sensors used in the zoo.
2. More API functions can be written to create, update, read, and delete sensor and user information from the database.
3. Security features can be extended to further ensure data integrity in the database.
4. Support different database backend and frontend implementations.