How ashok-a15/go_laari works
1. Workspace shape
- This repo is not a single app; it is a two-app Flutter workspace for the Go Laari logistics platform.
- The two independent client apps are:
- Customer app: golorry_customer_app-master
- Owner/driver app: golorry_owner_driver_app_master
- They are built, tested, and deployed separately, but share the same product domain: bookings, location tracking, and Firebase-backed state.
2. Customer app: primary user-facing flow
- The customer app is the booking and trip-following client.
- Its main screens cover the lifecycle from onboarding/authentication to booking, fare estimation, live tracking, and trip history/settings.
- Key UI areas include auth, booking_summary, estimate, live_tracking, map, tracking, profile, and several settings pages.
3. Customer app: presentation-to-service boundary
- The Flutter UI is split from logic-heavy services in lib/services.
- Core service responsibilities include:
- authentication
- booking creation and retrieval
- directions and geocoding
- driver tracking and map camera control
- user/profile access
- A tracking_provider suggests state is propagated through provider-style reactive state management.
4. Customer app: mapping and trip computation
- The customer side contains a dedicated mapping subsystem:
- route/direction handling
- map styling and constants
- marker generation
- fare calculation
- location interpolation for smoother movement
- This is the part of the app that turns location and booking data into a route visualization and trip progress experience.
5. Customer app: backend/data dependencies
- The customer app is wired to Firebase through Android config and Firestore rules/indexes.
- The presence of google-services.json, firestore.rules, and firestore.indexes.json indicates Firestore is a central persistence layer.
- The app also includes platform shells for Android, iOS, web, macOS, Windows, and Linux, so Flutter is the main runtime with native wrappers only for embedding/configuration.
6. Customer app: separate Python backend
- The backend/ folder is a distinct service from the Flutter client.
- It contains:
- main.py
- train_model.py
- intents.json
- intent_model.pkl
- serviceAccountKey.json
- This strongly suggests a Python-based NLP/chatbot backend that is trained from intents and likely uses Firebase/admin credentials for integration with the app.
7. Owner/driver app: primary operational flow
- The owner/driver app is the operational side of the platform.
- Its UI is organized around:
- role selection and login
- dashboard and main shell
- driver management
- available jobs/bookings
- live tracking
- earnings and profile/settings pages
- The structure indicates this app is meant for job acceptance, trip execution, and account/driver operations rather than customer booking.
8. Owner/driver app: real-time operations layer
- The service layer includes:
- authentication
- Firestore access
- geocoding
- tracking
- background service support
- background_service.dart is a key architectural clue: the app likely continues publishing location or tracking updates even when not foregrounded.
- tracking_service.dart and owner_map.dart indicate it is responsible for feeding live driver position data into the system.
9. Shared platform pattern between the two apps
- Both apps appear to use a Firebase-centered architecture for identity and shared state.
- The customer app consumes trip/driver location state; the owner/driver app produces that state.
- In other words, the platform likely uses Firestore as the coordination layer between booking requests, job acceptance, and live tracking updates, with Flutter UI on both sides and Firebase as the shared backend.
10. Ancillary web/login assets
- Both repos contain assets/lamp_login/ with HTML/CSS/JS.
- This looks like an embedded or auxiliary login/landing asset bundle rather than the primary app shell.
- The exact integration point is not visible, but it is part of the app packaging rather than a separate service.
11. Build, delivery, and automation
- The repositories include CI/CD workflows and mobile build configuration:
- customer app: GitHub Actions and Codemagic, plus a Firebase distribution workflow
- owner app: GitHub Actions CI/CD and firebase.json
- This means the deployment pipeline is split from runtime concerns and likely targets Firebase distribution/hosting or app release automation.
12. Architecture diagram takeaway
- A useful diagram should show two Flutter clients at the edges:
- Customer app: booking, estimation, trip monitoring
- Owner/driver app: job handling, tracking, trip execution
- Between them sits Firebase/Firestore as the shared coordination plane.
- The customer app also has a Python chatbot/NLP backend, while the owner app has a separate Node/Firebase-oriented backend entrypoint.
- Mapping, routing, and geocoding are cross-cutting concerns in both apps and are central to the trip/tracking experience.
Main entry points: screens Customer UI · lib/services Owner Services · lib/services Customer Services · pages Owner UI
Components 19
Customer App
Flutter client for booking, fare estimation, and live trip following
- Customer Shell · App bootstrap and navigation root
golorry_customer_app-master/lib/main.dart - Customer UI · Onboarding, auth, booking, tracking, profile, and settings screens
golorry_customer_app-master/lib/screens - Customer Services · Auth, booking, directions, tracking, geocoding, and user access
golorry_customer_app-master/lib/services - Map Logic · Fare, markers, styles, and interpolation for trip visualization
golorry_customer_app-master/lib/utils - Tracking State · Reactive propagation of tracking and trip updates
golorry_customer_app-master/lib/providers/tracking_provider.dart - Chatbot API · Intent-driven backend entrypoint for customer-side assistant and integration
golorry_customer_app-master/backend/main.py - Model Train · Trains the intent model used by the customer assistant
golorry_customer_app-master/backend/train_model.py - Intent Data · Intents, trained model, and service credentials for the Python backend
golorry_customer_app-master/backend/intents.json
Owner/Driver App
Flutter client for job acceptance, driver operations, and live tracking
- Owner Shell · App bootstrap and navigation root
golorry_owner_driver_app_master/lib/main.dart - Owner UI · Role selection, login, dashboard, jobs, earnings, profile, and settings
golorry_owner_driver_app_master/lib/pages - Owner Services · Auth, Firestore access, geocoding, tracking, and background support
golorry_owner_driver_app_master/lib/services - Owner Map · Map presentation and driver location display
golorry_owner_driver_app_master/lib/widgets/owner_map.dart - Background Sync · Keeps driver location and tracking updates running in the background
golorry_owner_driver_app_master/lib/services/background_service.dart - Firestore Bridge · Owner-side Firestore coordination for jobs and driver state
golorry_owner_driver_app_master/lib/services/firestore_service.dart
Shared Platform
Firebase-backed coordination and delivery assets used across both apps
- Firestore Config · Firestore rules, indexes, and Android Firebase wiring
golorry_customer_app-master/firestore.rules - Login Assets · Embedded HTML/CSS/JS login or landing assets
golorry_customer_app-master/assets/lamp_login - Backend Entry · Owner-side backend entrypoint for Firebase-oriented server logic
golorry_owner_driver_app_master/backend/index.js - Customer CI/CD · GitHub Actions and Codemagic workflows for customer app delivery
golorry_customer_app-master/.github/workflows/flutter_build.yml - Owner CI/CD · GitHub Actions workflows for owner app build and release
golorry_owner_driver_app_master/.github/workflows/ci.yml
Connections 20
- Customer Shell → Customer UI: boots · Launches the customer navigation and screen flow
- Customer UI → Customer Services: uses · Screens call services for auth, booking, and trip data
- Customer UI → Tracking State: subscribes · UI reacts to live tracking state
- Customer Services → Map Logic: computes · Transforms booking and location data into routes, markers, fare, and camera behavior
- Customer Services → Firestore Config: reads/writes · Uses Firebase-backed persistence and shared trip state
- Tracking State → Firestore Config: syncs · Streams trip and driver updates from the shared backend state
- Customer Shell → Chatbot API: integrates · Connects the app to the customer assistant backend
- Chatbot API → Model Train: loads model · Uses trained intent model artifacts
- Model Train → Intent Data: trains from · Builds the model from intent data and credentials
- Customer UI → Login Assets: embeds · Uses packaged login/landing assets
- Owner Shell → Owner UI: boots · Launches the owner/driver navigation and page flow
- Owner UI → Owner Services: uses · Pages call services for auth, jobs, and tracking
- Owner UI → Owner Map: renders · Displays driver position and live trip maps
- Owner Services → Background Sync: starts · Keeps tracking active outside the foreground
- Owner Services → Firestore Bridge: reads/writes · Coordinates bookings, driver state, and operational data
- Owner Services → Owner Map: feeds · Provides live location data to the map view
- Firestore Bridge → Backend Entry: coordinates with · Shared operational state flows through the backend boundary
- Firestore Config → Firestore Bridge: shared plane · Both apps coordinate through Firebase/Firestore state
- Customer CI/CD → Customer Shell: builds · Customer app delivery pipeline
- Owner CI/CD → Owner Shell: builds · Owner app delivery pipeline