RentInform

Welcome to the front end repository for RentInform!
RentInform is a web application built for the Turing School of Software and Design's Mod 3 Consultancy project. Read more about project requirements: https://backend.turing.edu/module3/projects/consultancy/

Table of Contents

1. About The Project
   • Video Demonstration
   • Built With
2. Getting Started
   • Installation
3. Testing
4. Wireframes
5. Technical Solutions
6. Roadmap
7. License
8. Contact
9. Acknowledgments

About The Project

RentInform is a civic data tool designed to help prospective Philadelphia renters gather information about potential new homes, avoid financial and health hazards, and make informed renting decisions to best meet their household's needs.

The front end application handles user interaction through the browser, and is built on Rails with HTML and CSS styling. It is responsible for user authentication and authorization, and consumes RESTful endpoints exposed through the back end application to deliver data about search results, saved properties, and property details to the views. The front end is also responsible for passing specific data through via JSON requests to perform CRUD actions in the back end database (ex. saving a property for a specific user).

• Production Website
• Backend Service
  • To reach endpoint append /api/v0/search?street='123-main-street'&zip='12345' to URL linked above
  • See more endpoints here
• Github repositories:
  • Front End:
  • Back End:

(back to top)

Video demonstration:

Demo_CP.mp4

(back to top)

Built With:

• 
• 
• 
• 
• 
• 

Integrations:

• RentInform's front end application uses OAuth with Google for user authentication and log in
  • Gem: omniauth-google-oauth2, more information here
• Tailwind was used for CSS styling
  • Gem: tailwindcss-rails, more information here
• New Relic was used for monitoring and observability
  • Gem: newrelic_rpm, more information here

(back to top)

Getting Started

To demo RentInform on your local machine, follow these steps:

Back End Repository

1. Clone the back end repo
2. Follow instructions in the backend repo README

Front End Repository

1. Clone this repo git clone git@github.com:RentInform/Rent-Inform-FE.git
2. Register for a MapQuest API Key here
3. Navigate to the local repository: cd Rent-Inform-FE
4. Run: bundle install
5. Run: rails db:{create,migrate}
6. Run: bundle exec figaro install
7. Add GOOGLE_CLIENT_ID, GOOGLE_CLIENT_SECRET, MAPQUEST_KEY, and NEW_RELIC_LICENSE_KEY to config/application.yml file
8. Run: rails s to start rails server
9. Visit: http://localhost:5000/

Prerequisites

• Ruby Version 3.1.1
• Rails Version 7.0.5

(back to top)

Testing

bundle exec rspec will run the entire test suite. All tests are passing at time of writing.

The team tested happy paths, sad paths, and edge cases when needed. Error messages were added where applicable.

(back to top)

Wireframes

Route: "/"

Landing Page:

Route: "/login"

Log in Page:

Route: "/sign_up"

Sign up Page:

Route: "/dashboard"

User Dashboard - New User Page:

User Dashboard - Search + Saved Properties Page:

(back to top)

Technical Solutions

As part of the Consultancy project requirements, the RentInform team challenged ourselves to implement three stretch technologies during the two-week design and development process. We selected these technologies based on the challenges we anticipated facing while building out our MVP, and adjusted our choices to reflect our individual and team learning goals as well as blockers that came up during the course of working on the project.

Background Workers

• Challenge: The available data on certification of rental compliance was only available in a CSV format, the number of entries in the list was very large (500K+), and the data needed significant de-duplication and normalization to be able to successfully query by address.
• Solution: We used the Rails Active Job framework, Sidekiq, and Redis to declare and run a job to read in the CSV file, sanitize the data, and populate our back end Postgres database with Property records. While our first draft job worked in development, we exceeded the memory limit of our Heroku deployment when we ran the job in production. To address this, we broke the single job into three smaller jobs with a single responsibility each, and also split our CSV file so that the most memory-intensive portion of the task was completed in batches. A future extension might include adding jobs to periodically download a new CSV from the City of Philadelphia’s website and a job to handle breaking the large CSV into multiple smaller parts for faster processing.

Observability

• Challenge: Once our application was deployed, we did not have a good way to measure response times, track performance, or analyze how the app was working in production beyond reviewing errors and logs.
• Solution: We researched popular observability platforms with free access tiers, including Honeybadger and New Relic. We decided on New Relic for this project because it offered an easy-to-read metrics dashboard with information on page response and loading times. We configured New Relic for both our front end and back end repositories, and ran some experiments interacting with our application to help us determine where best to utilize caching.

Caching

• Challenge: Two of the API endpoints that expose data for the front end of our application rely on both database queries and external API calls, and were running slowly (10-15+ seconds per call) when first deployed. This delay resulted in a less-than-ideal experience for our users.
• Solution: After interacting with our application running live and reviewing data from New Relic, we realized that the endpoints for searching properties and getting more details for a property were running slowest, and were good candidates for low-level caching since they contained information that was not likely to change quickly (addresses and scores). We used the Rails.cache syntax and some helpful documentation to cache these requests in the front end service object that handles the call to the back end API, and noticed immediate improvements in response times. We decided not to implement caching for other API calls that would change frequently, such as the request to get all saved properties for a specific user.

(back to top)

Roadmap

Features added to MVP 2.0 as of July 2023:

• Build out property details page for displaying more information about property to users
• Add map with address marker to property details page
• Add information about nearby parks to property details page
• Update UI to improve accessibility and design

Additional features, functionality, and potential refactors:

• Standard user registration and log in (to be added to the OAuth workflow)
• Two-factor authentication
• Improve search to match on zipcode and/or lat & lon coordinates
  • Allow a visitor to search properties with different queries
• Expanded error handling
  • Could potentially include rescuing from standard Rails errors
• Implement more details for the user through additional external API calls
  • Amenities: Grocery stores, schools, libraries
  • Commute time to workplace from searched property
  • Aggregate score for the property from within the application
• Allow a user to add notes for the property
• Compare properties
• Share properties
• Allow users to export their saved properties to Google Drive

(back to top)

License

Distributed under the MIT License. See LICENSE.txt for more information.

(back to top)

Contact

• Caroline Peri:
• Grace Joh:
• Logan Cole:
• Stephen McPhee:

Special Thanks: Jamison Ordway, our instructor and project manager

(back to top)

Acknowledgments

• Install Tailwind CSS with Ruby on Rails
• How to Setup Tailwind 3 on Rails 7
• Banner Image - Philly Skyline

(back to top)