Backend-for-Frontend and Client-Specific API Design Questions

Requirements clarification:

• Mobile: intermittent/low bandwidth, background sync, small payloads, battery-sensitive.
• Web: rich interactivity, low-latency real-time updates, complex queries.
• Cross-cutting: security (auth, encryption), scale, observability.

Protocol choices (hybrid):

• REST/JSON over HTTPS for simple CRUD, cacheable endpoints, and where broad compatibility is needed (mobile, proxies, CDN).
• gRPC-Web for high-performance RPC from browsers where binary efficiency and strict typed contracts matter (useful for telemetry-heavy flows).
• GraphQL (single endpoint) for flexible, client-driven queries; use persisted queries to reduce payloads.
• Real-time: GraphQL subscriptions over WebSocket or server-sent events for web; for constrained mobile, use lightweight push (APNs/FCM) to wake device and fetch deltas via REST/gRPC.

Caching:

• Edge/CDN for GETs and persisted GraphQL responses when safe; use cache keys with Vary and short TTLs for dynamic content.
• HTTP caching and ETags/If-None-Match to minimize payloads.
• Client-side: normalized cache (Apollo/Relay) on web; mobile local cache layer with eviction policies and size limits.

Offline strategies & sync:

• On-device authoritative local store (SQLite/Room/Realm) and operation queue (command log).
• Optimistic updates in UI with rollback on error.
• Background sync: schedule exponential backoff retries; use push notifications to trigger immediate sync.

Conflict resolution:

• For commutative data (counters, presence), use CRDTs to achieve automatic merge.
• For complex domain objects, combine server-side merge rules + versioning:
  • Use vector clocks or per-field timestamps to detect concurrent edits.
  • Default policy: per-field merge where possible; otherwise surface conflict to user with contextual diff and allow manual resolution.
  • Provide last-write-wins only for low-risk fields; log conflicts and expose metrics/alerts.
• Support idempotent APIs and opaque operation IDs to prevent duplicate application.

Trade-offs & implementation notes:

• Start with REST + GraphQL read layer; add gRPC-Web for performance hotspots.
• Keep real-time limited to web subscribers; use push+delta fetch for mobile to save battery.
• Invest in monitoring (conflict rates, sync failures) and tooling to help support teams debug client state.

This hybrid approach balances compatibility, efficiency, offline resilience, and developer ergonomics while keeping clear escalation paths for conflict cases.

Below are practical techniques to minimize payload size for mobile API clients. For each I list server & client implications, CPU vs bandwidth tradeoffs, and schema-evolution/compatibility concerns.

1. Field projections (selective fields)

• Server: support query params or GraphQL selections; add logic to filter/serialize only requested fields.
• Client: request only needed fields per screen; handle missing/null fields.
• CPU/BW: low CPU, high BW savings when large objects trimmed.
• Compatibility: safe if server tolerates unknown fields; prefer additive changes and versioning if removing fields.

2. Compression (gzip, brotli)

• Server: compress responses conditionally (Content-Encoding) and manage CPU/latency; cache compressed variants.
• Client: advertise Accept-Encoding, decompress on device; consider streaming decompression.
• CPU/BW: CPU cost on server/client vs significant bandwidth reduction for text/JSON.
• Compatibility: standard HTTP headers keep compatibility; avoid compressing already compressed binary blobs.

3. Binary encodings (Protocol Buffers, CBOR, FlatBuffers)

• Server: serialize to binary formats and provide content-type; maintain schema definitions.
• Client: include deserialization libs and schema handling; faster parsing for some formats.
• CPU/BW: lower bandwidth and often lower CPU for parsing (FlatBuffers allows zero-copy); initial integration cost higher.
• Compatibility: choose formats with forward/backward compatibility (protobuf optional fields); manage schema registry and field numbers carefully.

4. Delta sync / incremental updates

• Server: produce change sets, support operations (patch), or provide change streams with versioning.
• Client: maintain local state, apply patches, handle conflict resolution and version checkpoints.
• CPU/BW: small bandwidth but extra server logic and client apply/merge CPU; increases complexity.
• Compatibility: design stable patch formats and clear migration paths; maintain full-sync fallback.

5. Pagination & windowing

• Server: support limit/offset or cursor-based paging; enforce sensible defaults.
• Client: request pages as needed, prefetch strategically.
• CPU/BW: reduces per-request payload; more requests may increase overhead/latency.
• Compatibility: cursor semantics must be stable; changing sort keys can break paging.

6. Server-driven content negotiation

• Server: negotiate representation (compact vs verbose, binary vs JSON) based on client capabilities.
• Client: send Accept headers or client capability metadata; fall back gracefully.
• CPU/BW: optimizes per-client bandwidth; server must maintain multiple serializers (CPU cost).
• Compatibility: negotiation reduces breaking changes risk; ensure clear defaults and version negotiation.

Best practices:

• Measure end-to-end (real device networks).
• Use TLS-aware compression and avoid double-compressing.
• Provide graceful fallbacks and full-sync endpoints.
• Document schemas, versioning policy, and maintain automated compatibility tests.
  These techniques are complementary; combine (e.g., protobuf + compression + pagination + delta sync) guided by device profiles and business SLAs.