Skip to content

hillstew/paired-fe

Repository files navigation

Paired Front-End

Table of Contents

Deployed App

Vist the deployed Paired app at https://www.paired.tech/.

Local Deployment

See this Deployment Guide for detailed instructions on how to deploy the app in a local environment.

Dev Team

Paired 2.0's dev team is:

Rock & Pebble feature's dev team:

The original Paired dev team is:

Description

This repo contains the Paired 2.0 Front-end, a React/Redux app. It derives data and logic from a GraphQL API built with Ruby on Rails and PostgreSQL (paired-be), which communicates with a Flask micro-service that handles SMS text notifications (paired-sms).

Together, these micro-services facilitate paired programming and peer mentoring between Turing students throughout their seven-month immersive program. Students later in the program can create available booking slots, and students earlier in the program can browse those and book paired sessions.

Paired 2.0 was built by a team of students in Turing's Back-End Engineering program. It adds SMS and email notifications of bookings and a user statistics dashboard to the original Paired app (front-end repo, back-end repo) which was built by Front-end students in April of 2019. They graciously allowed contributions to the app and were helpful throughout this process. You can view the original project's Readme file here.

Rock & Pebble Feature

The Rock & Pebble feature adds the ability for Paired users to offer to be peer mentors, search for and request peer mentors, and manage their mentors/mentees. Building on the previous 2.0 work, it sends descriptive email notifications throughout the process. By adding this feature we hope to support the grassroots tradition at Turing of upper-module students ("rocks") being partnered with lower-module students ("pebbles") to support their journey.

The Rock & Pebble feature was developed over the course of 2020 by a group of 1909 back-end and front-end graduates, some from the Paired 2.0 dev team and some new contributors. The development took place on forks of the BE and FE repos, which are now archived but can be found here and here respectively for future reference.

Agile Development

Paired 2.0 was developed over the course of 9 days using accelerated agile practices. After an initial proposal was written by the project lead, the team collaboratively participated in an "inception" process. After writing problem and solution statements, the team "brain-dumped" all their feature proposals; prioritized which of those features would be part of the "minimum viable product" (MVP); and engaged in a story-grooming process to craft the user stories and tasks necessary to complete that MVP.

Soon thereafter the team had a meeting to establish goals, communication plans, project management conventions, and more. It was agreed upon that the team would use a Kanban system for project management using Github Projects, and have daily stand-up meetings and weekly retrospective meetings. The team met with a project manager every three days for check-ins and communicated with her regularly via Slack.

Technologies & Architecture

Technology and Architecture Chart

  • Hosting: Firebase (FE) and Heroku (BE, SMS)
  • Database: PostgreSQL
  • Front-end: React & Redux
  • Back-end: Ruby on Rails
  • SMS Micro-service: Flask & Python
  • Testing: Jest (FE), RSpec (BE), and PyTest (SMS)
  • GraphQL: Apollo Client (FE) and GraphQL-Ruby (BE)
  • OAuth: Github via Firebase
  • SMS Notifications: Twilio
  • Email Notifications: Sendgrid
  • Background Workers: Sidekiq and Redis
  • Performance Tracking: Skylight

React and Redux Tutorial

As a team of back-end engineers, stepping into a JavaScript-heavy tech stack was an incredible and bewildering learning experience. To help share that learning with our fellow students in the back-end program, we wrote this tutorial: Explain It Like I'm a Back-ender: React and Redux.

Testing & Performance

Skylight performance dashboard

At date of project completion, the Paired 2.0 back-end service has 98% test coverage and all tests passing. Server performance and load times are monitored using Skylight, and at time of writing responses average 37 ms.

PostgreSQL Schema

Users Data Type Keys
Id ID Primary Key
name String
program String
pronouns String
mod Integer
slack String
email String
phone_number String
firebase_id String OAuth Token
Pairings Data Type Keys
Id ID Primary Key
pairer_id Integer User Foreign Key
pairee_id Integer User Foreign Key
date String
time String
notes String
Skills Data Type Keys
Id ID Primary Key
name String
user_id Integer User Foreign Key

GraphQL Endpoints

Our GraphQL endpoints fall into three categories: queries, mutations, and filter queries. For detailed examples of all the endpoints and example responses, see our GraphQL Endpoints Guide or click the specific query or mutation below to go its section.

To make live queries to the GraphQL endpoint and see live schema information, setup the back-end using the local deployment instructions and access GraphiQL at http://localhost:3001/graphiql.

Resource Credits