DIU Turf

DIU Turf is a mobile-first turf booking platform developed for hostel students of Daffodil International University. It replaces manual booking through calls, messages, and informal records with a structured system for viewing available slots, making reservations, joining waitlists, and reviewing booking activity.

The central problem is fair allocation of a limited university facility. Without server-enforced rules, the same slot can be requested by multiple students, frequent users can dominate availability, and administrators have little reliable history of bookings, cancellations, attendance, or overrides.

The platform combines a React Native application with a FastAPI backend and PostgreSQL database. Students receive a live booking experience, while administrators manage slots, maintenance days, students, bookings, attendance, announcements, and audit records.

• Real-time slot availability
• Server-enforced fair-use limits
• First-come-first-served waitlists
• Administrative control room
• Auditable booking history
• Analytics-ready operational data

The mobile application handles student and administrator interaction, while the backend owns authentication, eligibility checks, booking transactions, waitlist promotion, notifications, and authorization.

The production backend is deployed and accessible over a secure HTTPS connection. The application uses environment-specific API configuration, and the Android build must be regenerated when production endpoint settings change.

The project’s deployment work included backend hosting, database migrations, HTTPS configuration, API verification, EAS Android builds, and production-device testing.

A working browser endpoint did not initially guarantee a working installed application. The final mobile build required the correct production API URL, HTTPS configuration, rebuild, and device retesting.

The booking workflow is supported by a normalized PostgreSQL schema designed for transaction integrity, waiting order, administrative accountability, and future analysis.

The schema is managed through Alembic migrations 001–009. Primary identifiers use UUIDs, production timestamps use TIMESTAMPTZ, and email uniqueness is case-insensitive through PostgreSQL citext.

Relationship Architecture:

• User → Booking or Waitlist → Slot Template → Turf
• Booking → Attendance
• User or Admin Action → Activity Log or Audit Log

The mobile interface does not decide booking eligibility. Fair-use and conflict rules are enforced by the backend transaction layer and PostgreSQL constraints. When a booking is cancelled, the first eligible waitlisted student can be promoted automatically and notified.

Transaction Execution Workflow:

1. 1.

   Select slot

   Student selects a date and slot.

2. 2.

   Optimistic update

   The app shows an optimistic booking state.

3. 3.

   Lock acquisition

   The backend acquires the booking transaction lock.

4. 4.

   Validate constraints

   Eligibility, maintenance, suspension, cap, and conflict rules are checked.

5. 5.

   Commit record

   The booking is committed and activity or notification records are created.

6. 6.

   Broadcast update

   A WebSocket event tells affected screens to refresh authoritative server data.

The platform separates roles to coordinate bookings, manage access boundaries, and enforce credentials protection across the application client and backend API.

Authentication

• Google OAuth using PKCE
• DIU email and password registration
• Server-side DIU email-domain validation
• Student ID validation
• HS256 JWT with jti
• JWT stored in Expo SecureStore
• Server-side revocation on logout

Roles and administration

User roles are strictly divided into student, admin, and super_admin:

• Student capabilities: Book, cancel, join waitlist, manage profile, view activity and notifications.
• Administrative capabilities: Manage students, manage slots, review bookings, block maintenance dates, mark attendance, broadcast announcements, force-cancel bookings, review audit history, view analytics preview.

Security controls

• bcrypt password hashing
• Server-side authorization
• Parameterized SQL
• Authentication rate limiting
• PostgreSQL-backed shared rate-limit counters
• Environment-based CORS
• Production startup validation
• HTTPS and security headers
• Suspension enforcement
• JWT revocation
• Authenticated WebSocket connections
• Secrets stored outside source control

DIU Turf uses authenticated WebSocket events to keep booking screens synchronized after bookings, cancellations, waitlist changes, maintenance updates, and announcements. The event acts as a refresh signal; clients then retrieve authoritative state from the backend.

Verified user-facing notification features include:

• Personal notification inbox
• Mark-read and mark-all-read actions
• Local 30, 15, and 5-minute reminders
• Expo push-token registration
• Waitlist-promotion alerts

The platform also produces normalized operational data suitable for analysis of slot demand, waiting queues, cancellation behavior, attendance, and resource-allocation fairness. Advanced analytics notebooks and demand forecasting remain planned extensions.

Implementation integrity is maintained through automated tests, typed serialization, and strict schema management.

Engineering Evidence

• GitHub Actions backend CI
• Strict TypeScript frontend
• Pydantic backend validation
• Zod frontend validation
• OpenAPI documentation
• Health checks
• Optional Sentry integration
• Production startup safeguards

Limitations

• Frontend automated tests are not yet established.
• Google Play publication is still in progress.
• iOS and TestFlight are not configured.
• Refresh-token rotation is not implemented.
• WebSocket authentication currently uses a query-string token.
• Advanced analytics and demand forecasting remain planned.
• The current 26-user adoption does not establish high-scale performance.

Current Status

DIU Turf currently has 26 active users. The initial adoption target is 100 users, and the target must be presented as a future objective rather than an achieved result.

The Android application is progressing through the Google Play publication process. The mobile application and production backend are functioning, but the portfolio must not describe the app as publicly available through Google Play until approval is complete and a verified store URL exists.