Roadmap

Development Roadmap

Spring 2015

Project Idea Priorities

• Rewrite backend - Per discussion with @gabe283 and @bamnet
  • Separate user facing application from administrative tools
    • Current design is a Ruby on Rails application that powers shuttles.rpi.edu and the admin interface used by WTG/Parking and Transportation
      • Running outdated version of RoR.
      • We don't need all of Rails to vend out the API and user-facing web application.
    • Shuttles API Application - (uses Rack Grape microframework) less framework code, smaller attack surface, less effort to update
      • Goal - provide a scalable API for developers and single page application for users
    • Shuttles Backoffice Application - Rails application for CRUD operations on routes, stops, vehicles, alerts, and trips (for GTFS integration)
      • Goal - enable self-service modification/addition of data by RPI Parking and Transportation without contacting the Web Tech Group
    • Optional/Aspirational Shuttles API Portal - Rails application for developers to receive vehicle location notifications over HTTP push.
      • Goal - enable self-service registration of applications by RPI student groups, students, and third parties to receive real-time notifications.
  • End-to-end push - The goal of the new design. Updates are delivered faster to users, push-based architecture provides better monitoring and metrics collection implementation. HTTP Push (maybe use SNS)
  • GTFS support - expose stop, route, trip, and real-time data in the GTFS format. This standards-based format is used by public transit providers. It also paves the way for Google Maps integration.
• Official Mobile Apps - We should control our own destiny when it comes to mobile apps. Students, maintainers, and RPI have been bitten several times by the unofficial shuttles apps that are out there.
• Remove single point of failure - Shuttles server in the VCC keeps going offline. When it goes offline, shuttles.rpi.edu goes down. Polling our upstream data source for vehicle locations, notifying interested clients (shuttles web site, mobile apps, etc.) are things that can be pulled out of shuttles.

Migration Plan

1. Extract polling code for upstream data provider into a separate application. Send updates using remote access API and over AWS SNS. Prerequisite for push updates over SNS and RPI Mobile arrival alerts.
2. Build Grape-Rack app to handle registration for arrival alerts per route-stop pair. Handles device push registration and subscription to SNS topics (one per route-stop pair). Also contains HTTP endpoint for AWS SNS location updates.
3. Standardize format for stop arrival notifications with RPI Mobile team.