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
Pros
-
Clear module-based architecture
-
Strong TypeScript support
-
Easy integration with databases, authentication, and queues
-
Express Rich community
-
Supports modular development and scalability
-
Fits well for APIs serving web and mobile apps
-
One backend server for both mobile and web
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
-
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
-
Server Components
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?
- Team is more experienced with
- Good ecosystem and tooling support
-
Reliable and stable relational database
-
Widely used in the industry with large community and resources
-
Works well with TypeORM for Nestjs integration
Pros
-
Good ecosystem and tooling support
-
Open-source and actively maintained
-
Supports advanced features like JSON, full-text search, and indexes
-
Strong support for transactions
Cons
-
Can be more complex to set up than simpler databases (like SQLite)
-
Overkill for very small projects
e. UI Libraries
What solution did we choose?
We chose shadcn/ui integrated with Tailwind CSS, and Figma designs for reference.
Why did we choose this solution?
Provides a ready-to-use component library built on Tailwind CSS
Open Code: The top layer of your component code is open for modification AI-Ready: Open code for LLMs to read, understand, and improve.Tailwind allows fast and consistent styling across the app
Figma designs give a visual reference for UI consistency
Components are customizable and responsive
Fits well with React and Next.js
Pros
Fast development using prebuilt components
Consistent design across web and mobile platforms
Easy to extend and customize with Tailwind
Direct mapping from Figma to code speeds up implementation
Lightweight and modern styling approach
Cons
Some components may require custom adjustments for unique use cases
Learning curve for Tailwind if new to utility-first CSS
Shadcn library updates may require small adjustments in code
Alternative Approaches
Material-UI (MUI)
Ant Design
Chakra UI
Custom components from scratch
