Skip to main content

Saheb App Design System

Screenshot 2026-01-01 at 14.04.11.png

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?

    Team is more experienced with

    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