Backend case study
Route intelligence around changing mobility data and unreliable external dependencies
Wasel Palestine was a university team project focused on backend engineering. The overall system spans mobility data, authentication, moderation, alerts, external APIs, documentation, and performance testing. My verified contribution centered on route-mobility, external routing/configuration, route-related API documentation, and a registration flow.
Wasel Palestine was designed as an API-centric mobility platform for structured information about checkpoints, road incidents, crowdsourced reports, alerts, and route conditions. User-interface work was outside the course scope so the team could focus on backend architecture, APIs, data modeling, integrations, reliability, and performance.
The team built a modular NestJS and TypeScript backend with versioned REST endpoints under /api/v1, TypeORM persistence targeting PostgreSQL, JWT-based authentication, DTO validation, external weather/routing integrations, Swagger/OpenAPI documentation, and Docker-based setup.
Domain work across checkpoints, incidents, crowdsourced reporting/moderation, alerts, and broader testing belongs to the team project as a whole and is not presented here as work I completed alone.
I implemented the route-mobility feature as a computation layer rather than a new persistent route model. It can start from an external route estimate and then apply Wasel-specific factors such as route mode, nearby checkpoints, verified incidents, and requested avoid-areas.
Reasoning: route estimates are derived from current mobility conditions, so calculating them from existing data keeps the feature separate from storage concerns. Trade-off: the local fallback is heuristic and does not claim road-graph-level accuracy.
I integrated OpenRouteService behind the external API layer instead of coupling route logic directly to the provider. The integration uses environment-based configuration, cached route responses, configurable timeouts, and a local heuristic fallback when the provider is unavailable or not configured.
Reasoning: an external routing provider can be slow, unavailable, or quota-limited. The trade-off is reduced precision during fallback, but the route-estimation request can still return a useful result instead of failing completely.
The route work uses typed DTOs with class-validator constraints for geographic inputs, alongside the project’s global validation pipe. I also contributed Swagger documentation around route-mobility endpoints and DTOs so API expectations are visible in generated documentation.
Reasoning: rejecting malformed input before business logic runs makes the service easier to reason about and test. Trade-off: DTO and documentation decorators add boilerplate, but keep validation rules and API contracts explicit.
The resulting route endpoint can combine an external driving estimate with Wasel-specific mobility factors and explain the factors that affected the result. The repository also contains team-level automated and k6 performance tests, but those are not attributed to me individually.
The route fallback is deliberately heuristic, and the project is presented as university backend engineering evidence rather than as a production navigation service.