API Documentation

Backend deployed using AWS

CI/CD Using CodePipeline, CodeBuild

Staging and Production deployed using Elastic Beanstalk and CloudFront

Foster Together

You can find the deployed frontend at https://app.fostertogether.co/signup.

Contributors

Steve Dole	Michelangelo Markus	Brendan Schatz	Bianca Severino
Full Stack Developer	Full Stack Developer	Full Stack Developer	Full Stack Developer

Jarrod Skahill	Marc Dandoy	Frantz Audige	Stacy Williams
Full Stack Developer	UX Designer	UX Designer	Team Lead

Lihuang Zheng	Ricardo Leite	Tyler de Friess	Lisa Cook
Full Stack Developer	Full Stack Developer	Full Stack Developer	Full Stack Developer

Dan Cashion	Raj Upadhyaya	Austin Huisinga	John Kernan
Full Stack Developer	Full Stack Developer	Full Stack Developer	Team Lead

Project Overview

Trello Board
Product Canvas
UX Design files

Foster Together is a nonprofit organization that connects foster families to volunteers (or "neighbors") in their area that can help with various tasks like cooking and transportation.

The main problem that the organization faces: data is scattered into multiple emails and spreadsheets, making it difficult to keep track of neighbors and foster family information.

Our goal with this application is to streamline the process for volunteer and family sign up, make it easier for the admins to view and interact with data, and automate the matching process.

From the Foster Together website:

In general, two myths persist about foster parents. Either they're "doing it for the money" (sometimes true, but not the norm) or they're a special, heroic kind of person with time and a big heart to spare. Through a public relations campaign based on real life foster parents, Foster Together will introduce you to "someone like you" who makes foster care work, with the right motivations and support from neighbors.

When tragedy strikes, local communities jump in with tangible relief efforts. Foster care exists as disaster relief in the most tragic of life events for a child. Through Random Acts of Foster Kindness, we connect neighbors with foster parents to meet a simple need like a delicious feast delivered at dinnertime, or transportation for a child's therapy appointments. We make it easy. We make it fast. We make it relational.

Key Features

Registration process for families and neighbors
Dashboard for admins to view and interact with database
Integration with Sterling for background checks

Tech Stack

Back end built using:

Node

As an asynchronous event-driven JavaScript runtime, Node.js is designed to build scalable network applications.

Express

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

Knex.js is a "batteries included" SQL query builder for Postgres, MSSQL, MySQL, MariaDB, SQLite3, Oracle, and Amazon Redshift designed to be flexible, portable, and fun to use. It features both traditional node style callbacks as well as a promise interface for cleaner async flow control, a stream interface, full featured query and schema builders, transaction support (with savepoints), connection pooling and standardized responses between different query clients and dialects.

PostgreSQL

PostgreSQL is a powerful, open source object-relational database system with over 30 years of active development that has earned it a strong reputation for reliability, feature robustness, and performance.

APIs

SendGrid

Sends email to member upon application approval, ready to be configured to send emails in other situations as well. Should set up a route for the admins to upload emails in serialised format and then send those emails for each situation. EX. PUT /emails/app/approved.

Contentful (coming soon)

Contentful will be used to make the training and possibly the application data easily changeable by the administators (non tech) users of the site. It will greatly reduce the amount of hardcoded and repeated data in the front end of the site as well.

Stripe (coming soon)

Stripe will be used to collect the payment for the background check. Flat rate of 20 dollars. Account has been set up already and API keys are available from it upon login. Link to the documentation for the integration that was previously working, but there is also Stripe Checkout that could be used.

Checkr (coming soon)

Checkr will be used to perform the background check. Create a Canidate profile upon completion of the Stripe payment using the user's email, then use the invitation API to send that user an invitation to complete the background check on Checkr. Will also need a POST route to collect the data from the Checkr WebHooks so we can update the database with the results when they're available. Account has been set up already and API keys are available upon login.

Environment Variables

In order for the app to function correctly, the user must set up their own environment variables.

create a .env file that includes the following:

All enviroment variables ending in test are set up differently than a typical postgres URL to account for AWS RDS. This allows CI on AWS to use RDS databases to test on, keeping production exactly the same as staging and testing.

PORT - Port you would like to run sever on.
NODE_ENV - set to "development"
DATABASE_URL - development DB url (postgres)
HOSTNAME_TEST - postgres hostname
USERNAME_TEST - postgres username
PASSWORD_TEST - postgres paswword
PORT_TEST - postgres port
NAME_TEST - database
JWT_SECRET - string for jwt secret
SENDGRID_API_KEY - key for SENDGRID API.

Testing

Jest
Supertest

Getting started

To get the server running locally:

Clone this repo
Create local PostgreSQL database for development
Create local or AWS RDS database for testing
npm i to install all required dependencies
Set your enviroment variables. (details below)
npm start to start the local server
npm test to run all tests in the testing environment

Endpoints

Auth Routes

Method	Endpoint	Access Control	Description
POST	`/login`	any user	Log in as a user.
POST	`/register`	admins	Create a new admin account.
GET	`/logout`	any user	Signs out a user.

Neighbor Routes

Method	Endpoint	Access Control	Description
GET	`/members`	admins	Returns the contact information for all neighbors and families.
GET	`/members/{querystring}`	admins	Returns member information based on a query string. ex: /members/?type=families.
GET	`/members/:id`	admin or exact user	Returns the contact information for a foster neighbor by ID.
POST	`/members/:membertype`	all	Add a new foster neighbor. Requires `first_name`, `last_name`, `email`, `phone`, `address`, `city`, `state`, and `zip`.
PUT	`/members/:id`	admins	Update the contact information for a foster neighbor.
DELETE	`/members/:id`	admins	Delete a foster neighbor.

Neighbor Training Routes

Method	Endpoint	Access Control	Description
POST	`/training/start`	user	Adds a new training table for a user if one does not already exist
PUT	`/training/update`	user	Updates fields in user's training table and returns updated table
GET	`/training/:id`	user	Returns user's training table
GET	`/training/`	user	Returns all users' training tables
DELETE	`/training/:id`	user	Deletes a user's training table

Data Model

ADMINS

{
  id: INCREMENT, // primary key
  first_name: TEXT
}

CITIES

{
  id: INCREMENT, // primary key
  city: TEXT
}

STATES

{
  id: INCREMENT, // primary key
  state: TEXT
}

ZIPS

{
  id: INCREMENT, // primary key
  zip: TEXT
}

CITY_STATE_ZIP

{
  id: INCREMENT, // primary key
  //foreign keys
  city_id: INTEGER,
  state_id: INTEGER,
  zip_id: INTEGER
}

MEMBERS

{
  id: INCREMENT, // primary key
  first_name: TEXT,
  last_name: TEXT,
  email: TEXT,
  phone: TEXT,
  address: TEXT,
  city_state_zip_id: INTEGER // foreign key
  latitude: TEXT
  longitude: TEXT
  membertype_id: INTEGER // foreign key
  match_id: INTEGER //foreign key to same table
}

USERS

{
  id: INCREMENT, // primary key
  email: TEXT,
  password: TEXT // hashed
  member_id: INTEGER // foreign key
  admin_id: INTEGER // foreign key
}

NEIGHBOR TRAINING

{
  id: INCREMENT, // primary key
  m1_q1: TEXT,
  m1_q2: TEXT,
  m2_q1: TEXT,
  m2_q2: TEXT,
  m2_q3: INTEGER,
  m2_q4: BOOLEAN,
  m2_q5: INTEGER,
  m2_q6: TEXT,
  m2_q7: BOOLEAN,
  m2_q8: BOOLEAN,
  m2_q9: TEXT,
  m3_q1: TEXT,
  m3_q2: TEXT,
  m3_q3: TEXT,
  m3_q4: TEXT,
  m3_q5: TEXT,
  m4_q1: TEXT,
  m4_q2: TEXT,
  m4_q3: TEXT,
  m4_q4: TEXT,
  m4_q5: TEXT,
  m4_q6: TEXT,
  m4_q7: TEXT,
  m4_q8: TEXT,
  m4_q9: TEXT,
  m4_q10: TEXT,
  m4_q11: TEXT,
  m4_q12: TEXT,
  m4_q13: TEXT,
  m5_q1: TEXT,
  m5_q2: TEXT,
  m5_q3: TEXT,
  training_completed: BOOLEAN,
  training_approved: BOOLEAN,
  member_id, INTEGER // foreign key
}

Actions

add(data) -> Insert a foster neighbor, family, or admin account

find() -> Get a list of all foster neighbors or families

find(filter) -> Get foster neighbor(s) or famili(es) by a key name, ie { email }

update(id, data) -> Update a foster neighbor or family's contact information, or an admin's account info

remove(id) -> Delete a foster neighbor or family

NOTE

There is an application table with various questions in indivdual tables, but per engineering manager, should be changed to a single serialised table. Working as written, but would be much simplier serialised.

Contributing

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.

Please note we have a code of conduct. Please follow it in all your interactions with the project.

Issue/Bug Request

If you are having an issue with the existing project code, please submit a bug report under the following guidelines:

Check first to see if your issue has already been reported.
Check to see if the issue has recently been fixed by attempting to reproduce the issue using the latest master branch in the repository.
Create a live example of the problem.
Submit a detailed bug report including your environment & browser, steps to reproduce the issue, actual and expected outcomes, where you believe the issue is originating from, and any potential solutions you have considered.

Feature Requests

We would love to hear from you about new features which would improve this app and further the aims of our project. Please provide as much detail and information as possible to show us why you think your new feature should be implemented.

Pull Requests

If you have developed a patch, bug fix, or new feature that would improve this app, please submit a pull request. It is best to communicate your ideas with the developers first before investing a great deal of time into a pull request to ensure that it will mesh smoothly with the project.

Remember that this project is licensed under the MIT license, and by submitting a pull request, you agree that your work will be, too.

Pull Request Guidelines

Ensure any install or build dependencies are removed before the end of the layer when doing a build.
Update the README.md with details of changes to the interface, including new plist variables, exposed ports, useful file locations and container parameters.
Ensure that your code conforms to our existing code conventions and test coverage.
Include the relevant issue number, if applicable.
You may merge the Pull Request in once you have the sign-off of two other developers, or if you do not have permission to do that, you may request the second reviewer to merge it for you.

Attribution

These contribution guidelines have been adapted from this good-Contributing.md-template.

Documentation

See Frontend Documentation for details on the frontend of our project.

Files

README.md

Latest commit

History