You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
-[Node and Express setup](#node-and-express-setup)
11
+
-[Environment variables](#environment-variables)
12
+
-[Example .env](#example-env)
13
+
-[PostgreSQL](#postgresql)
14
+
-[Sequelize](#sequelize)
15
+
-[Docker](#docker)
16
+
-[Using this product](#using-this-product)
17
+
-[Testing](#testing)
18
+
-[Sources and Links](#sources-and-links)
19
+
20
+
<!-- /TOC -->
21
+
22
+
# Bmore Responsive
4
23
An API to drive disaster and emergency response systems.
5
24
6
-
## 1.1. Documentation
25
+
## Documentation
7
26
We've included a `docs` folder with a template [Tech Spec](/docs/Tech_Spec.md) and [Best Practices](/docs/Best_Practices.md) document, though using Github's Wiki capabilities is also a good idea. This will get you started with documenting your project. Other documents and relevant information that has no other place can live in the `docs` folder. Replace this paragraph with a brief breakdown of what you've included in your `docs` folder.
8
27
9
-
### 1.1.1. API Spec
28
+
### API Spec
10
29
Our API spec is on Swagger. You can view it here https://app.swaggerhub.com/apis/codeforbaltimore/bmoreResponsive/1.0.0#/ or you can find the `swagger.json` file in our `docs` folder and use it via http://localhost:3000 when the app is running locally.
11
30
12
-
### 1.1.2. Database Documentation
31
+
### Database Documentation
13
32
Our database documentation can be found in our `docs` folder under `database.csv`. This documentation was created using SchemaSpy. Instructions for use can be found here https://github.com/bcgov/schemaspy
14
33
15
-
# 2. Setup
34
+
# Setup
16
35
A `Dockerfile` and `docker-compose` file have been included for convenience, however this may not be the best local setup for this project. For more information on how to use Docker with this project, please see the [docker section](#24-docker).
17
36
18
37
To work on this project you should have:
@@ -21,14 +40,14 @@ To work on this project you should have:
21
40
- Docker (optional)
22
41
Once you have the prerequisite software installed you can proceed to setup this application.
23
42
24
-
## 2.1. Node and Express setup
43
+
## Node and Express setup
25
44
This application is designed to work as an API driven by Express. To setup your environment first you must install all required dependencies by running the following command from the root of your project directory:
26
45
```
27
46
npm install
28
47
```
29
48
Once all dependencies are installed you will need to setup some environment variables to interact with your database and application.
30
49
31
-
## 2.2. Environment variables
50
+
## Environment variables
32
51
You will need to set some local environment variables to run this application. This is true even if you're using Docker.
33
52
```
34
53
touch .env
@@ -57,7 +76,19 @@ _We do not recommend using the default options for PostgreSQL. The above values
57
76
-`DATABASE_HOST`: The IP address Docker is running on. You can find this by running `docker-machine ip` but it's usually `192.168.99.100` instead of `localhost`
58
77
-`DATABASE_URL`: This will need to be adjusted as well, for example `DATABASE_URL=postgres://postgres:postgres@localhost:5432/postgres` would become `DATABASE_URL=postgres://postgres:[email protected]:5432/postgres`
59
78
60
-
## 2.3. PostgreSQL
79
+
### Example .env
80
+
To make this easier included below is an example `.env` file using all default values. ***We highly recommend*** you use custom values, but this should clarify what is needed for this to run.
***You will need a PostgreSQL database running locally to run this application locally.*** You may setup PostgreSQL however you wish, however we recommend using Docker using the instructions found here: https://hub.docker.com/_/postgres
62
93
63
94
If you are using the Docker method you may spin up your database layer by running this command:
If you're running a database in another way then we trust you can sort it out on your own because you're awesome :sunglasses:
69
100
70
-
### 2.3.1. Sequelize
101
+
### Sequelize
71
102
To properly start the application the database needs to be built by Sequlize ahead of time. To do that run the following commands
72
103
1. You must create your database tables without running the application by running `npm run db-create` first.
73
104
2._optional_ You can now seed your database if you wish by running `npm run db-seed`.
@@ -78,7 +109,7 @@ To create new models, migrations, and seeders you _must_ use the Sequelize CLI c
78
109
-`npx sequelize-cli model:generate --name User --attributes firstName:string,lastName:string,email:string` - Creates a model under `/src/models` and a migration script.
79
110
-`npx sequelize-cli seed:generate --name demo-user` - Creates a seeder for the `User` model and migration previously setup.
80
111
81
-
## 2.4. Docker
112
+
## Docker
82
113
To use the `docker-compose.yml` file included you will first need to set [environment variables](#22-environment-variables). You **MUST** set your `DATABASE_HOST` to `db` to use the `docker-compose` solution.
83
114
84
115
If you are running your own database, but want to use the `Dockerfile` you will need to run that this way:
@@ -97,16 +128,16 @@ You can manually set the environment variables and not use a `.env` file by sett
97
128
-e DATABASE_URL=<your connection string>
98
129
```
99
130
100
-
# 3. Using this product
131
+
# Using this product
101
132
You may use this product to create and manage users for your front-end. More to come!
102
133
To run the application--after the above steps are completed--run `npm start`.
103
134
104
-
## 3.1. Testing
135
+
## Testing
105
136
To test your code you may write test cases to `./index.spec.js` and then run the tests with `npm test`.
106
137
107
138
To check your linting you may run `npm run lint` and to format and automatically fix your formatting run `npm run format`.
108
139
109
-
# 4. Sources and Links
140
+
# Sources and Links
110
141
We are also building a front-end application called [Healthcare Rollcall](https://github.com/CodeForBaltimore/Healthcare-Rollcall) to interact with this backend API. To view that project, or to contribute to it, please visit the repo here: https://github.com/CodeForBaltimore/Healthcare-Rollcall
111
142
112
143
We will be including multi-repo build processes with the front-end that will reference this project.
Copy file name to clipboardExpand all lines: docs/Best_Practices.md
+2-5Lines changed: 2 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,9 @@
1
1
# Best Practices
2
-
Code for Baltimore projects should be built with the intention of deploying on [Heroku](https://heroku.com). For details on Heroku Best Practices see their [developer documentation](https://devcenter.heroku.com/articles/node-best-practices).
2
+
Code for Baltimore projects should be built with the intention of deploying on [Heroku](https://heroku.com) or [AWS](https://aws.amazon.com/). For details on Heroku Best Practices see their [developer documentation](https://devcenter.heroku.com/articles/node-best-practices).
3
3
4
4
## Project Management
5
5
6
-
We are using Github Issues to track outstanding issues and work for projects.
6
+
We are using Github Issues to track outstanding issues and work for projects.
7
7
8
8
### Projects
9
9
@@ -38,9 +38,6 @@ Example: Google has openly published style guides for many languages in wide use
38
38
39
39
Static code analysis tools should be used when possible, to monitor and improve code quality. This may be integrated in the local development environment, automated repository commit checks, automated CI/CD pipelines, or other steps in the code development process.
40
40
41
-
### SonarQube scanning
42
-
Before committing or pushing any code changes those changes should be scanned with SonarQube. For convenience a `docker-compose` file has been included with this repository to facilitate local scans so that clean code can be checked and pushed before the deployment scans. See the [README](/sonarqube/README.md) in the sonarqube folder for more information.
43
-
44
41
## Git and Branching
45
42
46
43
All code work should be done in an isolated or feature branch off of the `master` branch. Before starting work on new code, developers should create their feature branch using a standard naming convention determined by the project.
Bmore Responsive is a Contact and Response Management System (CRMS) and API. This document will describe the application in some detail.
23
+
24
+
## Overview
25
+
This application will allow users to add and update contact information for individuals and entities. Additionally, the system will facilitate tracking of entity status and any other pertinent information. The data collected can be used by municipalities to organize response efforts in a disaster or crisis situation.
26
+
27
+
## Scenarios
28
+
This application and API can be used in a few different ways.
29
+
30
+
### COVID-19
31
+
During the COVID-19 Pandemic the City of Baltimore needs a way to check-in with healthcare providers to ensure they have all of the supplies they need, if they have any patients sick with the virus, if anyone is in quarantine, etc.
32
+
33
+
Many healthcare facilities have a few members on staff, however the contact information for those individuals may be out of date or the facility may have experienced some changeover since the last checkin.
34
+
35
+
Using the API and a front-end, the City of Baltimore would be able to keep track of the facility's status via multipule contact points in an organized and efficient way.
36
+
37
+
### Automatic Checkin
38
+
Facilities may not have time for phone calls, and the number of available city workers may not be sufficient to check in with all providers during an emergency.
39
+
40
+
Using our API the providers can securely check-in using a web form on their own. One-time use logins can be sent on regular intervals to preferred contacts for each facility. This can allow contacts to update facility status on their own time without the need for city workers to contact them directly.
41
+
42
+
### Organized Response
43
+
City workers and volunteers have a need to check in with facilities during the COVID-19 pandemic. The callers need to track who has called who and when, and track the overall trends in automatic updates.
44
+
45
+
Using this API workers can login and see the status of the city at a glance, and they can prioritize their check-ins based on need and trend.
46
+
47
+
## Non Goals
48
+
What will this project not accomplish?
49
+
- No front-end website or app
50
+
- No outside data interactions
51
+
- Non-city employee full login (dashboard, etc)
52
+
- Statistical or analytical endpoints
53
+
54
+
## Minimum Viable Product
55
+
To use this product as quickly as possible we will be implementing the following features:
56
+
- User creation
57
+
- Contact creation
58
+
- Entity creation
59
+
- Contact->Entity linking
60
+
- Contact single-use login check-in ability
61
+
62
+
## Components
63
+
This application will be broken down into several components. Each will be outlined here.
64
+
65
+
### API
66
+
The API is the application for all intents and purposes. Use of the API and possible paths of use are defined in the flowchart below.
67
+
68
+
69
+
### CI/CD
70
+
We will use TravisCI, Docker, Netlify, and AWS to provide constant code deployments and test coverage.
71
+
72
+
73
+
### Data
74
+
This product makes use of [PostgreSQL](https://www.postgresql.org/) for the data layer and [Sequelize](https://sequelize.org/) for database interactions. The schema is outlined below
75
+
76
+
77
+
### Application Architecture
78
+
The overall application will have several components in support of the code. These will facilitate secure communication between any front end, our API, and the data layer. Additionally our architecture will be designed to be scalable for instances of heavy load.
0 commit comments