Saheb App Design System
1. Purpose of This Documentation
This presentation explains the design and technical decisions behind our application features.
a. We will be covering:
1. Technology Stack
-
Backend framework
-
Web frontend framework
-
Mobile frontend framework
-
Database technology (PostgreSQL, MySQL, etc.)
-
UI libraries
-
Supporting libraries and tools (state management, datafetching, utilities)
2. Application Architecture & Project Structure
-
Technical decisions
-
Backend folder structure
-
Frontend folder structure
-
Design patterns and development strategies
3. Localization & Language Support
-
Multi-language database translation strategy
-
RTL (Right-to-Left) support on web and mobile
-
Hijri calendar localization
4. Core Domain Logic
-
Qibla calculation logic
-
Prayer time calculation methods
-
Hijri time caulculation methods
5. Media Management
-
Audio resource handling (Sermon / موعظة)
-
Video hosting and streaming strategy
6. Notifications & Communication
-
Timezone-aware push notification system
-
Email notification architecture
-
Notification reliability and crash handling
-
Scheduling notificaiton with cron
8. Application Standards
-
Request logging
-
User event and activity tracking
-
Error and crash reporting
-
API versioning
b. How Each Section Is Documented
For every section in this documentation, we consistently answer the following questions:
-
What solution did we choose?
-
Why did we choose this solution?
-
What are the pros and cons of this solution?
-
What alternative approaches were considered?
1. Technology Stack
a. Backend Framework
What solution did we choose?
We chose Nodejs + Expressjs + NestJS as the backend framework.
Why did we choose this solution?
- Team is more experienced with
- Widely used on our code base
-
Built with TypeScript by default
-
Supports modular development and scalability
-
Fits well for APIs serving web and mobile apps
- One backend server for both mobile and web
Pros
-
Clear module-based architecture
-
Strong TypeScript support
-
Easy integration with databases, authentication, and queues
-
Express Rich community
Cons
-
Slightly more boilerplate
-
Integration Complexity with Some Legacy Libraries
Alternative Approaches
-
Express.js
-
Fastify
-
Laravel (PHP)
-
Spring Boot (Java)
b. Web Frontend Framework
What solution did we choose?
We chose Next.js using the App Directory.
Why did we choose this solution?
-
Built-in support for modern React features
-
File-based routing with the App Directory
-
Server Components
-
Good integration with backend APIs
- Built-in layouts, and loading states, server errors handlings
Pros
-
Clear and scalable project structure
-
Server-side rendering and static generation
-
Built-in routing, layouts, and loading states, server errors handlings
-
Strong support for SEO and web performance
Cons
-
Some ecosystem libraries are still adapting
-
Build & Deployment Complexity
-
Rapidly Changing Features
Alternative Approaches
-
React ( Vite )
-
React (Tanstack start )
-
Nuxt.js
-
Angular
c. Mobile Frontend Framework
What solution did we choose?
We chose React Native with Expo.
Why did we choose this solution?
-
Allows building iOS Android apps and web from a single codebase
-
Expo provides a managed workflow for faster development
-
Built-in support for push notifications, sensors, and device APIs
-
Large community and ecosystem
- Easy to test during development and on real devices
- Quick testing on simulators, emulators, and real devices
Pros
-
Cross-platform development saves time and resources
-
Expo handles native build processes, reducing setup complexity
-
Easy to integrate with backend APIs (REST / GraphQL)
-
Hot-reloading for fast development
-
Strong developer and community support
-
Deployment built-in
-
Easy to test during development and on real devices
-
Quick testing on simulators, emulators, and real devices
Cons
-
Some native modules require custom development (Ejecting from Expo)
Alternative Approaches
-
Pure React Native (without Expo)
-
Flutter
-
Native iOS (Swift) / Android (Kotlin) development
d. Database Technology
What solution did we choose?
We chose PostgreSQL as the database for our application.
Why did we choose this solution?
Reliable and stable relational database
Supports advanced features like JSON, full-text search, and indexes
Strong support for transactions
Widely used in the industry with large community and resources
Works well with TypeORM for backend integration
Pros
Good ecosystem and tooling support
Open-source and actively maintained
Cons
Can be more complex to set up than simpler databases (like SQLite)
Overkill for very small projects
