ParkLocator
A parking idea became a multi-surface platform with mobile discovery, admin operations, geospatial search, and reservation flow.
How the project is put together
6 layers / 5 directed links
100%
- 01Interface
Mobile parking discovery and admin management surfaces share one platform model.
Flutter / Angular 20 / PrimeNG / Maps - 02Application
Client-side state, venue workflows, reservations, payments, and admin operations.
Bloc / Angular services / Guards / Interceptors - 03Services/API
Auth, venues, reservations, payments, notifications, dashboard, reports, and audit modules.
NestJS 11 / TypeORM / Socket.IO / PayMongo - 04Data
Spatial venue search, reservation locks, realtime availability, and uploaded venue assets.
PostgreSQL / PostGIS / Redis / Uploads - 05Auth/Permissions
Role access and manager scoping keep users, admins, and venue operators separated.
JWT / Passport / Roles / Venue scoping - 06Runtime
PostGIS/Redis local stack, CI checks, API containerization, and contention/load testing.
Docker Compose / GitHub Actions / k6 / Node 22
From broken workflow to operating system
Parking discovery and venue operations were split across generic maps, manual status checks, and missing admin tools.
Flutter mobile, Angular admin, NestJS API, PostGIS, Redis, and PayMongo connect into one reservation platform.
The workflow constraint
Existing parking apps are either too generic (Google Maps) or lack proper admin tools and spatial querying. A dedicated platform was needed with a mobile app for users to find nearby parking spots, an API with geospatial search, and an admin portal for parking spot management.
What changed
Decisions and trade-offs
Flutter over React Native
Needed a cross-platform mobile framework with strong performance for map rendering and geolocation to display parking spots.
Decision: Chose Flutter for its native performance, rich widget library, and strong geolocation/maps ecosystem (Very Good CLI for project structure).
Trade-off: Dart learning curve vs JavaScript familiarity, but better performance for map-heavy UI and type safety built into the language.
NestJS over Express for the API
API needs structured patterns for auth, validation, and module separation as it grows.
Decision: Used NestJS for its opinionated architecture with dependency injection, decorators, and built-in validation pipes.
Trade-off: More boilerplate than Express, but enforced structure prevents code organization problems at scale.
PostGIS over application-level geospatial calculations
Parking spot search requires efficient radius queries and spatial indexing.
Decision: Used PostGIS extension for PostgreSQL to handle spatial queries natively with GiST indexes.
Trade-off: Requires PostGIS-specific Docker image and spatial SQL knowledge, but orders of magnitude faster than application-level distance calculations.
Constraints, architecture, and proof
Monorepo structure: apps/mobile (Flutter/Dart), apps/api (NestJS), apps/admin (Angular). PostGIS database via Docker Compose. NestJS API serves REST endpoints with spatial queries for parking spots. Flutter app uses Very Good CLI structure with flavors (development/staging/production). Load tests directory for performance benchmarking.
Deployment, security, and maintenance
Load testing infrastructure for API performance benchmarking, Docker Compose for reproducible database setup, independent test suites per app (Flutter test, NestJS lint + test, Angular test).