Tech Stack Discussion: Better Commute Route App

[jofftiquez]

Project Overview

We're building Better Commute Route - a web-based commute planning application inspired by Sakay.ph that helps users find optimal routes from point A to point B with detailed information including:

• Multiple public transportation modes (jeepneys, buses, trains, UV Express, etc.)
• Fare information and cost comparisons for each route option
• Step-by-step directions with estimated travel times
• Real-time and crowd-sourced transportation data
• Route optimization based on user preferences

Current Scope: Web application first - no mobile development initially.

Key Technical Requirements

Core Features

• Interactive Mapping: Route visualization and stop/station locations
• Multi-Modal Routing Engine: Calculate routes across different transport types
• Crowd-Sourced Data Management:
  • User-submitted route information
  • Data validation and moderation system
  • Community feedback and corrections
• Real-time Information: Live updates on delays, fare changes, service disruptions
• Search & Discovery: Location search, landmark recognition, route suggestions
• User Accounts: Save preferences, route history, and contribute data
• Responsive Design: Works well on desktop and mobile browsers

Technical Considerations

• Data Accuracy: Validate and moderate crowd-sourced information effectively
• Performance: Fast route calculations and smooth map interactions
• Scalability: Handle growing route database and user base
• SEO-Friendly: Public routes should be discoverable via search engines
• Offline Capability: Basic functionality when connectivity is poor
• API Integration: External mapping services, government transit APIs
• Geospatial Processing: Efficient handling of location data and route calculations

Tech Stack Options to Evaluate

Frontend Framework

Web Frontend:

• React + TypeScript: Large ecosystem, good mapping library support
• Vue.js + TypeScript: Simpler learning curve, good performance
• Next.js: React-based with SSR/SSG for better SEO and performance
• SvelteKit: Modern, fast, smaller bundle sizes
• Nuxt.js: Vue-based with SSR/SSG capabilities

Mapping & Visualization

Mapping Services:

• Mapbox GL JS: Excellent customization, good pricing for startups
• Google Maps API: Comprehensive but expensive at scale
• OpenLayers + OpenStreetMap: Open source, full control, no API costs
• Leaflet: Lightweight, good for simpler mapping needs

Geospatial Libraries:

• Turf.js: Geospatial analysis in the browser
• PostGIS: Server-side geospatial processing
• OSRM: Open source routing machine

Backend Architecture

Runtime/Framework:

• Node.js + Express/Fastify: JavaScript everywhere, good for rapid development
• Python + FastAPI: Excellent for data processing and ML for route optimization
• Go: High performance, good for concurrent route calculations
• PostgreSQL + PostGIS: Essential for geospatial data storage and queries

Database Strategy

Primary Database:

• PostgreSQL + PostGIS: Industry standard for geospatial applications
• MongoDB: Document-based, good for flexible route data structures

Caching & Performance:

• Redis: Route caching, user sessions, real-time data
• ElasticSearch: Fast location search and route discovery

Infrastructure & Deployment

Hosting Options:

• Vercel/Netlify: Excellent for frontend deployment with edge functions
• Railway/Render: Good for full-stack applications
• AWS/GCP: More control, better for scaling
• Docker + VPS: Cost-effective for bootstrapping

Discussion Questions

1. Mapping Strategy

• Given Sakay.ph's success, should we prioritize open-source mapping (OpenStreetMap) to avoid API costs?
• How important is custom map styling vs using standard map themes?
• Should we pre-generate static route images for faster loading?

2. Crowd-Sourced Data Architecture

• How do we implement effective data validation similar to Sakay.ph's approach?
• What's the best way to handle conflicting route information from different users?
• Should we implement a reputation system for data contributors?

3. Route Calculation Engine

• Build custom multi-modal routing or integrate existing GTFS/OSRM solutions?
• How do we handle the complexity of informal transport systems (like jeepneys)?
• Real-time route adjustments vs pre-computed route variants?

4. Data Sources & Integration

• Which government/transit agency APIs should we prioritize for integration?
• How do we bootstrap initial route data before crowd-sourcing takes off?
• Strategy for handling different data formats from various transport operators?

5. Performance & Scalability

• How do we optimize for fast route searches across large datasets?
• Caching strategy for frequently searched routes?
• Database indexing approach for geospatial queries?

6. User Experience & SEO

• Should we implement server-side rendering for better SEO of popular routes?
• How important is offline functionality for web users?
• Progressive Web App (PWA) vs traditional web app?

Proposed Evaluation Criteria

Rate each option (1-5) on:

• Development Speed: How quickly can we build a functional MVP?
• Geospatial Performance: Efficiency with maps, routing, and location data
• Community & Documentation: Quality of mapping/GIS library ecosystem
• Scalability: Can it handle growth similar to Sakay.ph's success?
• Data Management: How well does it handle crowd-sourced data workflows?
• Cost Efficiency: Development and operational costs, especially for mapping APIs
• SEO & Discoverability: Can users find routes via search engines?

Success Metrics (Inspired by Sakay.ph)

• Route Quality: User satisfaction with route suggestions
• Data Accuracy: Community validation of crowd-sourced information
• Performance: Route calculation speed and map responsiveness
• Adoption: User growth and route searches per month
• Community Engagement: User contributions and data submissions

Research Phase Tasks

Week 1-2: Technical Research

• Mapping Solutions: Compare Mapbox vs OpenStreetMap implementation costs and features
• Routing Engines: Evaluate OSRM, GraphHopper, and custom routing approaches
• Database Design: Design schema for multi-modal route data with PostGIS
• Frontend Performance: Test mapping performance across different frameworks

Week 3: Prototyping

• Build simple route search with top 2 tech stack combinations
• Test geospatial query performance with sample data
• Evaluate mapping library integration complexity

Next Steps

1. Research Assignment: Team members take ownership of specific areas above
2. Community Research: Study how other successful transit apps handle similar challenges
3. Technical Prototype: Build proof-of-concept with most promising stack
4. Architecture Design: Detailed system design based on research findings

---

Key Questions for the Team:

• Any experience with geospatial applications or mapping libraries?
• Thoughts on open-source vs commercial mapping solutions?
• Ideas for bootstrapping initial route data before crowd-sourcing?
• Experience with real-time data processing for transportation?

References:

• Sakay.ph - Our primary inspiration
• OpenStreetMap Routing - Open source routing resources
• GTFS Specification - Standard for public transportation data

[whinee]

2. What's the best way to handle conflicting route information from different users?

I think we can handle conflicting route information from different users by thinking of a route that a PUV, specifically a PUJ, as a decision tree.

One thing I have noticed is that Jeepney drivers always ask "May bababa ba ng [X]?" (lit. "Will someone go off at [X]?"), [X] being someone's stop; Or if we get on a Jeepney in a transport terminal, the Jeepney driver is already thinking of a route to go thru, to optimize the ride. For example, if no passengers need to go to Establishment X, then the jeep wont go to the road going to X, unless mandated by their registration and whatever Jeepney Groups.

This means that users can log if some passengers needs to be dropped off at [X] that changes the route that the PUJ goes thru.

For the extroverts, we can ask around Jeepney drivers and their associations in order to absolutely ascertain the accuracy of the data.

However, this specific question probably did not ask for this. But, I thought I would answer it this way anyways, as it is still relevant.

For other cases, we can implement a voting system, to avoid erroneous or outright troll entries. However, we should also have a commenting system for a way to other commuters to communicate things such as "did passengers needed to be dropped off to [X], as this route was different from the route that I had taken" and such.

[mrjxtr]

Tech Stack Options to Evaluate

Frontend Framework > Web Frontend:

• "React + TypeScript" or "Vue.js + TypeScript".

Mapping & Visualization > Mapping Services:

• I've worked with Google Maps API (but it is hella expensive 100%)

Backend Architecture > Runtime/Framework:

I would suggest Go for the backend, but not a lot of peeps know it so it will probably hinder "Development Speed".
Reasons to choose it tho would be "High performance, good for concurrent route calculations" + it is practically made for the cloud and deploys easily.

We can also do the micro services route to split up the calculations and stuff

Reasonable options would still probably be "Python + FastAPI" since we would probably be dealing with a lot of data and a lot of devs would probably contribute faster and easier with a stack like this.

[Kands221]

Suggestion: Users can report real-time conditions (e.g. “walang UV sa Tikling”, “bumaha sa España”, “wala nang jeep sa gantong oras”)