Application Architectures - Learning Module

Loading content...

0/228

Mobile Backends

The Mobile-First Backend

Mobile backends power the server-side infrastructure for iOS, Android, and cross-platform mobile applications. While sharing many patterns with web backends, mobile applications introduce unique networking constraints that fundamentally shape backend architecture.

Mobile devices operate in challenging network environments—switching between WiFi and cellular, experiencing variable bandwidth, and frequently losing connectivity entirely. Users expect applications to remain functional offline, sync seamlessly when connectivity returns, and consume minimal battery and data. These requirements demand backend architectures specifically designed for mobile constraints.

The relationship between mobile clients and backends is inherently different from web applications:

Native clients bundle application code, requiring thoughtful API versioning
Push notifications enable server-initiated communication when apps aren't active
Offline operation requires synchronization protocols and conflict resolution
Resource constraints demand efficient data formats and bandwidth optimization

Understanding these mobile-specific patterns is essential for building backends that deliver excellent user experiences across the spectrum of devices and network conditions.

Learning Objectives

By the end of this page, you will understand the unique networking requirements of mobile applications, API design patterns optimized for mobile clients, push notification infrastructure, offline synchronization strategies, and Backend-as-a-Service platforms that accelerate mobile development.

Mobile Network Characteristics

Mobile networks present challenges that rarely exist for desktop browsers or server-to-server communication. Backend architectures must account for these realities.

Network Variability:

Network Type	Latency (RTT)	Bandwidth	Characteristics
WiFi (good)	5-50ms	10-100+ Mbps	Stable, low latency
4G LTE	30-100ms	5-50 Mbps	Good, variable
3G	100-500ms	0.5-5 Mbps	High latency, limited
2G/EDGE	300-1000ms	0.1-0.5 Mbps	Very slow, unreliable
Offline	∞	0	Complete disconnection

Connection State Transitions:

Mobile devices frequently transition between states:

┌─────────────────────────────────────────────────────────────┐
│                Mobile Connection States                      │
│                                                             │
│   WiFi ◄──────► Cellular ◄──────► Offline ◄──────► WiFi    │
│    │              │                   │               │     │
│    │   Handoff    │    Signal Loss    │   Reconnect   │     │
│    │              │                   │               │     │
│    └──────────────┴───────────────────┴───────────────┘     │
│                                                             │
│   Each transition may:                                      │
│   • Change IP address (breaking connections)                │
│   • Alter available bandwidth                               │
│   • Introduce packet loss during handoff                    │
└─────────────────────────────────────────────────────────────┘

Backend Design Implications:

Timeout Configuration: Mobile requests need longer timeouts than desktop
Retry Logic: Exponential backoff with jitter for unstable connections
Request Idempotency: Retried requests must not create duplicate effects
Graceful Degradation: Return partial data when full response unavailable
Connection Resumption: Support resumable uploads/downloads for large files

Battery and Data Consciousness

Every network request consumes battery (radio activation) and potentially metered data. Efficient mobile backends batch requests, use efficient serialization, enable response compression, and avoid polling in favor of push notifications. Users notice apps that drain battery or consume excessive data.

Mobile API Design Patterns

APIs designed for mobile clients require different optimization strategies than web APIs. The goal is minimizing round trips, reducing payload size, and enabling efficient caching.

Backend for Frontend (BFF) Pattern:

Dedicated API layers optimized for specific client types:

┌─────────────────────────────────────────────────────────────┐
│                    BFF Architecture                          │
│                                                             │
│   iOS App ────► iOS BFF ─────┐                              │
│                              │                              │
│   Android ───► Android BFF ──┼───► Internal Services        │
│                              │     (User, Order, Payment)   │
│   Web App ────► Web BFF ─────┘                              │
│                                                             │
│   Each BFF:                                                 │
│   • Aggregates data from multiple services                  │
│   • Formats responses for specific client needs             │
│   • Handles client-specific authentication                  │
│   • Versions independently of other clients                 │
└─────────────────────────────────────────────────────────────┘

Response Optimization:

Technique	Benefit	Implementation
Field Selection	Send only needed fields	`?fields=id,name,avatar`
Pagination	Limit response size	Cursor-based for consistency
Compression	Reduce bandwidth	gzip/Brotli (30-70% reduction)
Binary Protocols	Faster serialization	Protocol Buffers, MessagePack
Delta Sync	Send only changes	Sync tokens with incremental updates

API Versioning Strategies:

Unlike web apps that load new code on refresh, mobile apps bundle their API client code. Multiple app versions in the wild must be supported simultaneously.

Strategy	Example	Trade-offs
URL Path	`/v1/users`, `/v2/users`	Clear, but hard to deprecate paths
Header	`API-Version: 2`	Clean URLs, harder to test
Query Param	`/users?version=2`	Easy testing, clutters URL
Content Negotiation	`Accept: application/vnd.api+json;v=2`	RESTful, complex

Recommended Approach:

1. Use URL-based major versions: /v1/, /v2/
2. Additive changes within versions (new fields, endpoints)
3. Never remove or rename fields without version bump
4. Maintain old versions for 12-24 months
5. Track version usage via analytics to plan deprecation

GraphQL for Mobile:

GraphQL's query flexibility suits mobile well:

# Mobile client requests exactly what it needs
query HomeFeed {
  user {
    id
    name
    avatar(size: THUMBNAIL)  # Size-appropriate image
  }
  feed(first: 10) {
    edges {
      node {
        id
        title
        # No unnecessary fields like 'fullContent'
      }
    }
  }
}

Benefits: Reduced over-fetching, single request for complex screens, strongly typed.

Offline-First API Design

Design APIs assuming offline operation. Include ETags and Last-Modified headers for cache validation. Use sync endpoints that accept 'since' timestamps. Return data structures that support local persistence and conflict resolution.

Push Notification Infrastructure

Push notifications enable servers to reach mobile devices even when apps aren't running. This server-initiated communication is essential for real-time updates, messaging, and re-engagement.

Push Architecture:

┌─────────────────────────────────────────────────────────────────────────┐
│                    Push Notification Flow                                │
│                                                                         │
│  1. App Registration                                                    │
│     Mobile App → Platform SDK → APNs/FCM → Device Token                 │
│     Mobile App → Token → Your Backend (store token with user)           │
│                                                                         │
│  2. Sending Notification                                                │
│     Your Backend → Push Service → APNs/FCM → Device → Notification      │
│                                                                         │
│  ┌──────────────┐    ┌───────────────┐    ┌──────────────┐             │
│  │ Your Server  │───►│ Push Service  │───►│ APNs (iOS)   │──► Device   │
│  │              │    │ (Firebase,    │    │              │             │
│  │              │    │  OneSignal,   │    └──────────────┘             │
│  │              │    │  SNS)         │    ┌──────────────┐             │
│  │              │    │               │───►│ FCM (Android)│──► Device   │
│  └──────────────┘    └───────────────┘    └──────────────┘             │
└─────────────────────────────────────────────────────────────────────────┘

Platform Services:

Platform	Service	Connection	Payload Limit
iOS	APNs (Apple Push Notification service)	HTTP/2, TLS	4 KB
Android	FCM (Firebase Cloud Messaging)	HTTP/2, TLS	4 KB
Web	Web Push (VAPID)	HTTP/2	Browser-specific

Notification Types:

Type	User Visibility	App State	Use Case
Alert	Displayed	Any	User-facing messages
Silent	Hidden	Background	Data sync triggers
Background Update	Hidden	Background	Content refresh
Rich	Expanded content	Any	Images, actions

Push Notification Best Practices

•Token Management: Tokens can change or become invalid. Handle token refresh events and clean up stale tokens.
•Delivery Tracking: Implement delivery receipts to monitor notification success rates.
•Rate Limiting: Respect platform rate limits. Batch notifications for bulk sends.
•Personalization: Segment users and personalize content for better engagement.
•Silent Pushes for Sync: Use silent notifications to trigger background data synchronization.
•Fallback Strategies: Have fallback delivery methods (email, SMS) for critical notifications.

Push Reliability

Push notifications are best-effort delivery—they may be delayed or not delivered at all. Don't rely on push for critical workflows. Always provide in-app mechanisms to retrieve information that might have been sent via push.

Offline Synchronization Strategies

Robust mobile applications must function when offline and synchronize seamlessly when connectivity returns. This requires careful design of both client storage and backend sync APIs.

Sync Patterns:

1. Last-Write-Wins (LWW):

Client A:  Update record at T1
Client B:  Update same record at T2 (T2 > T1)
Server:    Accepts B's update (most recent wins)

Simple but can lose data from Client A.

2. Operational Transform (OT):

Client A:  Insert 'X' at position 5
Client B:  Insert 'Y' at position 3
Server:    Transform operations to apply both correctly
           Result: Both insertions preserved

Complex but preserves all edits. Used in collaborative editing.

3. CRDTs (Conflict-free Replicated Data Types):

Mathematically guaranteed to merge without conflicts.
Examples: Grow-only counters, sets, registers
No server coordination required.

Sync Protocol Design:

┌─────────────────────────────────────────────────────────────┐
│                    Delta Sync Protocol                       │
│                                                             │
│  1. Client Request                                          │
│     GET /sync?since=2024-01-15T10:30:00Z                    │
│                                                             │
│  2. Server Response                                         │
│     {                                                       │
│       "changes": [                                          │
│         {"id": "1", "op": "update", "data": {...}},        │
│         {"id": "2", "op": "delete"},                       │
│         {"id": "3", "op": "create", "data": {...}}         │
│       ],                                                    │
│       "syncToken": "2024-01-15T11:45:00Z",                 │
│       "hasMore": false                                      │
│     }                                                       │
│                                                             │
│  3. Client applies changes to local database                │
│  4. Client stores syncToken for next sync                   │
└─────────────────────────────────────────────────────────────┘

Conflict Resolution Strategies
Strategy	How It Works	Best For
Last-Write-Wins	Timestamp determines winner	Low conflict likelihood
Server Wins	Server version always wins	Authoritative data
Client Wins	Client version always wins	User-controlled data
Manual Resolution	User chooses between versions	High-value documents
Merge	Combine non-conflicting changes	Structured data

Queue Offline Operations

Implement an offline operation queue on the client. Record user actions while offline, then replay them against the server when online. Include retry logic and handle conflicts gracefully. Users should never lose work due to connectivity.

Backend-as-a-Service (BaaS)

Backend-as-a-Service (BaaS) platforms provide pre-built backend infrastructure for mobile applications, accelerating development by handling common functionality like authentication, databases, storage, and push notifications.

Common BaaS Capabilities:

Feature	What It Provides
Authentication	Social login, email/password, MFA, session management
Database	Real-time sync, offline support, queries
Storage	File uploads, CDN distribution, image processing
Push Notifications	Cross-platform delivery, targeting, analytics
Functions	Server-side logic without managing servers
Analytics	Usage tracking, crash reporting, A/B testing

Popular BaaS Platforms:

Platform	Strengths	Considerations
Firebase	Real-time DB, excellent mobile SDKs, Google ecosystem	Vendor lock-in, NoSQL only
Supabase	PostgreSQL, open source, real-time subscriptions	Newer, smaller community
AWS Amplify	Full AWS integration, GraphQL, enterprise features	Complexity, AWS learning curve
Appwrite	Self-hosted option, open source	Younger ecosystem

Firebase Architecture Example:

┌─────────────────────────────────────────────────────────────┐
│                    Firebase-Powered App                      │
│                                                             │
│   Mobile App                                                │
│      │                                                      │
│      ├─► Firebase Auth ───────► Authentication              │
│      │                                                      │
│      ├─► Firestore ──────────► Real-time Database           │
│      │   (offline-first,      (automatic sync when online)  │
│      │    real-time sync)                                   │
│      │                                                      │
│      ├─► Cloud Storage ──────► File Upload/Download         │
│      │                                                      │
│      ├─► Cloud Functions ────► Server-side Logic            │
│      │   (triggered by DB changes, HTTP, schedule)          │
│      │                                                      │
│      └─► FCM ────────────────► Push Notifications           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Trade-offs:

Aspect	BaaS Advantage	BaaS Disadvantage
Development Speed	Immediate functionality	Less control
Scalability	Automatic	Cost at scale
Customization	Pre-built is fast	Custom logic limited
Vendor Lock-in	N/A	Migration difficulty
Cost	Free tiers, pay-per-use	Can be expensive at scale

When to Use BaaS:

✅ MVPs and prototypes needing rapid development ✅ Small teams without backend expertise ✅ Apps with standard CRUD patterns ✅ Real-time features (chat, collaboration)

When to Build Custom:

✅ Complex business logic requirements ✅ Specific compliance/security needs ✅ High scale with cost sensitivity ✅ Must avoid vendor lock-in

Hybrid Approaches

Many successful apps combine BaaS with custom backends—using Firebase for auth and real-time features while maintaining custom APIs for complex business logic. This balances development speed with flexibility.

Mobile Backend Security

Mobile backends face unique security challenges because apps can be decompiled and API keys extracted. Security must assume the client is compromised.

Key Security Principles:

1. Never Trust the Client:

❌ Client says: "I'm admin user, give me all data"
✅ Server verifies: Token signature, permissions, rate limits

2. Certificate Pinning: Prevent man-in-the-middle attacks by validating specific certificates:

App stores expected certificate hash
During TLS handshake, app verifies server cert matches
Blocks proxies with different certificates

3. API Key Protection:

API Key Type	Exposure Risk	Protection
Client-embedded	High (extractable)	Use only for non-sensitive operations
Server-only	Low	Never embed in mobile apps
User-scoped tokens	Medium	Short expiry, refresh tokens

Mobile Backend Security Checklist

•Transport Security: Enforce HTTPS with TLS 1.2+. Implement certificate pinning for sensitive apps.
•Authentication: Use short-lived tokens with refresh. Implement device binding for sensitive operations.
•Authorization: Validate permissions server-side for every request. Never trust client claims.
•Rate Limiting: Protect against abuse with per-user and per-IP rate limits.
•Input Validation: Validate and sanitize all input server-side. Mobile clients can be modified.
•Sensitive Data: Never expose sensitive data in API responses. Filter fields based on permissions.
•Logging: Log security events for audit and detection. Don't log sensitive data.

Client-Side Security is Insufficient

Any validation, obfuscation, or security measure implemented only on the mobile client can be bypassed. All security controls must be enforced server-side. Client-side measures are speed bumps, not barriers.

Summary: Mobile Backend Architecture

We've explored the unique requirements and patterns for mobile backend development—understanding how mobile network constraints, offline operation needs, and push communication shape server-side architecture.

Key Takeaways

•Mobile networks are variable and unreliable—backends must handle high latency, intermittent connectivity, and complete offline scenarios.
•API design for mobile emphasizes efficiency—minimize round trips, support field selection, use efficient serialization, and enable aggressive caching.
•API versioning is critical—multiple app versions coexist, requiring backward compatibility and graceful deprecation strategies.
•Push notifications enable server-initiated communication—essential for real-time updates but require robust token management and fallback mechanisms.
•Offline synchronization requires careful conflict resolution—choose strategies appropriate for your data's characteristics and user expectations.
•BaaS platforms accelerate development—powerful for MVPs and standard patterns but consider lock-in and customization limits.
•Security must be server-side—never trust the mobile client; all validation and authorization must be enforced on the backend.

Transition to Architecture Selection:

With our examination of monolithic, microservices, web, and mobile architectures complete, we're now prepared to synthesize this knowledge into architecture selection criteria—understanding how to choose the right architectural approach based on requirements, constraints, team capabilities, and business context.

Page Complete

You now understand the unique requirements of mobile backend development—from network constraints and API design through push notifications, offline sync, and security considerations. This knowledge enables you to design and build backends that deliver excellent mobile user experiences.