Web Project Integration: Architecture, Deployment & Real-World Apps

TAKEAWAYS:

• Understand the three-tier architecture (client-server-database) and how each layer interacts in a real web app like eSewa’s payment gateway.
• Learn session management (cookies, tokens) with a worked example of how Daraz tracks your shopping cart across pages.
• Compare local vs. cloud deployment (XAMPP vs. AWS) using a cost/performance table for Nepalese startups.
• Trace a full request cycle (HTTP handshake → database query → response) in a Mermaid sequence diagram for a Kathmandu traffic route API.
• Identify security risks in project integration (SQL injection, XSS) with real-world fixes from Ncell’s app vulnerabilities.
• Plan a project workflow using Agile/Waterfall, with a Gantt chart example for a Pathao driver app feature.

1. Web Project Architecture: The Three-Tier Model

Web projects are built using a three-tier architecture to separate concerns and improve scalability. Each tier has a distinct role:

classDiagram
    class ClientTier {
        +HTML5/CSS3
        +JavaScript (React/Angular)
        +User Interface
    }
    class ServerTier {
        +Node.js/Python/Php
        +APIs (REST/GraphQL)
        +Business Logic
    }
    class DatabaseTier {
        +MySQL/PostgreSQL
        +MongoDB (NoSQL)
        +Data Storage
    }
    ClientTier --> ServerTier : "HTTP Requests"
    ServerTier --> DatabaseTier : "SQL/NoSQL Queries"
    ServerTier --> ClientTier : "JSON/XML Responses"

How It Works: A Real Example (eSewa)

When you pay a bill on eSewa:

1. Client Tier: Your browser sends a request to https://esewa.com.np/pay (HTML5 + JavaScript).
2. Server Tier: The eSewa backend (Node.js) validates your input, checks your balance, and generates a payment token.
3. Database Tier: The server queries the PostgreSQL database to update your account and log the transaction.
4. Response: The server sends a success/failure message back to your browser.

Why This Matters:

• Separation of concerns: Frontend developers can work on UI without touching the database.
• Scalability: eSewa can add more servers (horizontal scaling) without rewriting the entire app.
• Security: Sensitive data (passwords, card details) stays in the server/database tier.

2. Session Management: How Web Apps Remember You

Sessions allow web apps to track users across multiple pages. Two common methods:

1. Cookies: Small text files stored in the user’s browser.
   • Example: Daraz stores cart_id=12345 in your cookies to remember items.
2. Tokens (JWT): Secure, server-generated tokens sent with each request.
   • Example: Ncell’s app uses JWT to authenticate users without storing passwords.

How Sessions Work: A Worked Example (Daraz Shopping Cart)

1. You add a product to your cart → Daraz’s server generates a session ID (e.g., session_abc123) and stores it in a cookie.
2. The server also logs this session in its database:

   -- Database table: user_sessions
   CREATE TABLE user_sessions (
       session_id VARCHAR(255) PRIMARY KEY,
       user_id INT,
       cart_items JSON,
       expires_at TIMESTAMP
   );
   

3. When you navigate to another page, your browser sends the cookie (session_abc123) with the request.
4. Daraz’s server checks the database: "This session belongs to user 456 with 3 items in cart."

Visual: Session Flow

sequenceDiagram
    participant User as Browser
    participant Daraz as Daraz Server
    participant DB as Database
    User->>Daraz: GET /add-to-cart?id=789 (Cookie: empty)
    Daraz->>DB: Check if user logged in
    DB-->>Daraz: No active session
    Daraz->>User: Set Cookie: session_id=abc123
    User->>Daraz: GET /cart (Cookie: session_id=abc123)
    Daraz->>DB: Fetch cart for session_id=abc123
    DB-->>Daraz: [{"id":789, "name":"Laptop"}, ...]
    Daraz->>User: Display Cart

Real-World Example: eSewa Login

• When you log in, eSewa creates a server-side session (stored in memory or Redis) and sends a cookie.
• The cookie is just a reference; the actual session data (your balance, transaction history) is on the server.
• Why? Cookies can be stolen, but server-side sessions are harder to hack.

3. Deployment Strategies: Local vs. Cloud

Where and how you deploy your web project affects performance, cost, and security.

How Daraz Might Deploy

1. Frontend: Hosted on AWS S3 (static HTML/CSS/JS files).
2. Backend: Node.js servers on AWS EC2 (handles orders, payments).
3. Database: Amazon RDS (PostgreSQL) for user data and orders.
4. CDN: CloudFront to speed up delivery to Kathmandu/Pokhara users.

4. Security in Project Integration

Common vulnerabilities and how to fix them:

Real-World Example: Ncell App Vulnerability

In 2022, Ncell’s app was found to have a session fixation bug:

1. Attacker tricks a user into clicking a malicious link with a predefined session_id.
2. The app reuses this session ID, giving the attacker access. Fix: Ncell updated their backend to regenerate session IDs after login.

5. Project Workflow: Agile vs. Waterfall

Choose a methodology based on your project’s needs.

Agile Workflow for a Pathao Driver App Feature

1. Sprint 1 (2 weeks): Design UI for "Request Ride" button.
   • Tools: Figma (UI), React (frontend).
2. Sprint 2: Backend API for ride requests.
   • Tools: Node.js, PostgreSQL.
3. Sprint 3: Integrate payment (Khalti/eSewa API).
4. Sprint 4: Test with real drivers in Kathmandu.

Visual: Agile Gantt Chart

gantt
    title Pathao Feature Development
    dateFormat  YYYY-MM
    section Sprint 1
    UI Design           :a1, 2023-10-01, 14d
    Frontend Dev        :after a1, 14d
    section Sprint 2
    Backend API         :2023-10-15, 14d
    Database Setup      :2023-10-15, 7d
    section Sprint 3
    Payment Integration :2023-11-01, 14d
    section Sprint 4
    Testing             :2023-11-15, 14d

6. Full Request Cycle: Kathmandu Traffic API

Let’s trace how a traffic route API (like Kathmandu Traffic Police’s real-time updates) works:

sequenceDiagram
    participant User as Mobile App (User)
    participant API as Traffic API Server
    participant DB as Database (Routes)
    participant Cache as Redis Cache

    User->>API: GET /routes?from=Thamel&to=Koteshwor (HTTP)
    API->>Cache: Check cache for "Thamel-Koteshwor"
    Cache-->>API: No data (Cache Miss)
    API->>DB: SELECT * FROM routes WHERE start='Thamel' AND end='Koteshwor'
    DB-->>API: [{"route":"Ring Road", "time":"20 mins", "traffic":"Medium"}]
    API->>Cache: Store response for 5 mins
    API-->>User: Return JSON: {"route":"Ring Road", "time":"20 mins"}
    User->>User: Display to driver

Key Takeaways:

• Caching (Redis): Speeds up repeated requests (e.g., multiple users asking for the same route).
• Database: Stores static data (route names, distances).
• API: Handles logic (e.g., "If traffic is high, add 5 mins to estimate").

7. Project Integration Checklist

Before submitting your project, verify:

1. Functionality: Does every feature work? (Test with Postman or browser dev tools.)
2. Security: Are passwords hashed? Are inputs sanitized?
3. Performance: Does the site load in <2s? (Use Google PageSpeed Insights.)
4. Deployment: Is the live version accessible? (e.g., http://yourproject.herokuapp.com)
5. Documentation: Does your README.md explain:
   • How to install dependencies?
   • How to run locally?
   • API endpoints and examples?

In the Real World

1. eSewa’s Payment Gateway

   • Idea Used: Three-tier architecture + session management.
   • How: When you pay a bill, eSewa’s frontend (HTML5) sends a request to their Node.js backend, which validates your session (JWT token) and queries PostgreSQL to deduct the amount. The session ensures you can’t pay twice without re-entering details.

2. Daraz’s Shopping Cart

   • Idea Used: Server-side sessions + cookies.
   • How: Daraz stores your cart items in a database linked to a session ID (stored in a cookie). If you close the browser and reopen it, the cookie is gone—but Daraz’s backend remembers your cart if you’re logged in (using a persistent session).

3. Pathao’s Driver App

   • Idea Used: Agile workflow + cloud deployment.
   • How: Pathao uses Scrum sprints to release features (e.g., "Add electric vehicle support"). Their backend runs on AWS, with Redis caching frequent requests like "Nearby rides" to reduce database load.

Exam Tip

This unit is application-heavy. Expect questions like:

• "Explain how session management works in a real web app like eSewa." → Answer: Use the three-tier model + cookies/JWT + a sequence diagram of the login flow.
• "Compare local and cloud deployment for a Nepalese startup." → Answer: Use the comparison table above, then pick AWS for scalability or XAMPP for low-cost testing.
• "How would you secure a project like Daraz’s cart system?" → Answer: SQL injection (prepared statements), XSS (input sanitization), session hijacking (HTTP-only cookies).

Pro Tip: Draw one diagram per question. Even if the exam doesn’t ask for it, visuals (sequence diagrams, architecture layers) boost your score. For example:

• For session questions, always include a sequence diagram of the login/request flow.
• For deployment, compare local vs. cloud in a table with real-world examples (eSewa on AWS, a student project on XAMPP).