Mobile App Backend

The backend server supporting our mobile app. Provides data from the V3 API and OpenTripPlanner.

Development

Prerequisites

Install the tools specified in .tool-versions. You can use asdf to help manage the required versions.

External Dependencies

V3 API - docs - mbta/api - dev - prod

The V3 API provides static and realtime GTFS data that we use for most of the information that we pass through to the app frontend.

OpenTripPlanner - docs - mbta/otp-deploy

We're not currently using OTP for anything, but have code in place to connect to it, and will likely rely on it in the future. The otp-deploy repo is used for deploying and configuring the MBTA OTP instance, see its readme for details on running locally.

Algolia - docs - dashboard - keys

Algolia provides well indexed route and stop data for incremental search results.

Sentry - docs - keys

Sentry is used for error logging and aggregation.

Environment Configuration

Install direnv if you don't already have it, copy .envrc.example to .envrc, populate any required values, then run direnv allow.

Running the application

• Run mix setup to install and setup dependencies
• Start Phoenix endpoint with mix phx.server or inside IEx with iex -S mix phx.server

Now you can visit localhost:4000 from your browser.

Running tests

Run command mix test to run all tests.

Integration tests use snapshots of data returned by the MBTA V3 API. To update those data snapshots used by a particular test module, run the UpdateTestData mix task with command mix updateTestData [pathToTestFile]

Editing Code

• Create each new feature in its own branch named with the following naming format: initials-description (for example, Jane Smith writing a search function might create a branch called js-search-function).
• This repo uses pre-commit hooks, which will automatically run and update files before committing. Install with brew install pre-commit and set up the git hook scripts by running pre-commit install.
• Use meaningfully descriptive commit messages to help reviewers understand the changes. Consider following Conventional Commits guidelines.

Code Review

All new features are required to be reviewed by a team member. Department-wide code review practices can be found here.

Some specifics for this repo:

• Follow Conventional Commits for pull request titles.
• New pull requests will automatically kick off testing and request a review from the mobile-app-backend team. If you aren't yet ready for a review, create a draft PR first.
• When adding commits after an initial review has been performed, avoid force-pushing to help reviewers follow the updated changes.
• Once a PR has been approved and all outstanding comments acknowledged, squash merge it to the main branch.

Deploying

Development Deploys

Merging to main will automatically kick off deploys to the staging environment. To trigger a deploy to a particular development environment for testing prior to merge, apply a "deploy to dev-*" label to a PR.

Prod Deploys

Create a GitHub release with a tag based on the current date, with a suffix counting the number of deploys on this day. For example, the first prod deploy of the day on June 20, 2024 would be 2024-06-20-1, a second deploy that day would be 2024-06-20-2, and a deploy the next day would be 2024-06-21-1.

Prod deploys are set to require manual approval in GitHub.