Key Design Decisions
Why two API styles?
Why two API styles?
Google-compatible (
/directions/v2:computeRoutes) lets teams migrate from Google Routes API by changing only the base URL. RESTful routes (/v1/routes) adds statefulness, async processing, and webhooks for production use cases. Both hit the same enrichment pipeline.Why this resource design?
Why this resource design?
We adopted industry best practices: ULID-prefixed IDs (
route_), an object field on every resource, idempotency keys, consistent error envelopes, and a processing/complete/failed state machine.Why physics enrichment?
Why physics enrichment?
Google Routes API tells you distance and duration - but not road grade, curvature, or fuel consumption. For a 36-ton semi on a 6% grade, fuel burn can be 3× higher than flat road. Motion fills that gap using real elevation models and road-load physics equations.
Why cursor-based pagination?
Why cursor-based pagination?
Telemetry segments can number in the hundreds. We use cursor-based pagination with
hasMore/nextCursor for predictable performance. Offset pagination would be fragile for large segment lists.Architecture
Motion is a freight routing API built for hackathon speed and production-grade design. It wraps the open-source Valhalla routing engine and layers on physics-based enrichment computed from real USGS elevation data and road geometry.Tech Stack
Local Development
Prerequisites: Docker and Docker Compose installed.
1
Clone and start
2
Verify
3
Run without Docker (optional)