Screen-Shaped Responses & Aggregation — Mobile API Best Practices

A home screen that needs the profile, feed, notifications count and promos should not make four sequential round trips on a 300 ms RTT network. Options: an aggregation endpoint shaped for the screen, a Backend for Frontend (BFF) owned by the mobile team, or GraphQL where the client selects exactly the fields it needs. Use sparse fieldsets (fields=) and embedding (include=) on REST resources for lighter cases.

Ways to shape responses for screens

Criterion	Generic REST	REST + include/fields	Mobile BFF	GraphQL
Round trips per screen	Many	Fewer	One	One
Over-fetching	High	Low	None (tailored)	None (client selects)
Who owns shape	Platform team	Platform team	Mobile team	Client (query)
HTTP caching	Easy	Easy	Moderate	Harder (POST, persisted queries help)
Old client compatibility	Version per resource	Add fields freely	Version per app release	Deprecate fields, never remove fast
Extra infra	None	None	A service	Server + tooling

HTTP

GET /v1/home?include=notifications_count,promos&fields[feed]=id,title,thumb_url
Accept-Encoding: br, gzip
If-None-Match: "home-7f3a"

HTTP/1.1 200 OK
ETag: "home-81c2"
Cache-Control: private, max-age=30
Content-Encoding: br

Common pitfalls

A BFF that grows business logic duplicated from core services.
Screen endpoints with no versioning story.
GraphQL queries that fan out to N+1 backend calls.

Key points

Count round trips per screen
BFF or GraphQL to aggregate
Sparse fields + compression for payload size

Further reading: Sam Newman: Backends For Frontends

Practice questions

What is a Backend for Frontend?

Answer

A server-side layer owned by a client team that aggregates and adapts backend APIs to exactly what one client (e.g. iOS/Android) needs, reducing round trips and coupling.

Why are sequential requests particularly expensive on mobile?

Answer

Each request costs at least one RTT (often 100–500 ms on cellular) plus possible radio wake-ups; waterfalls multiply latency and battery use.