Mobile App Backends

A Backend for Frontend is an API layer purpose-built for a specific client (in this case, a mobile app). Instead of the mobile app calling ten different microservices and assembling the data itself, the BFF does that aggregation on the server and returns exactly what the app needs in a single call.

This matters for mobile for several reasons: it reduces the number of round trips over a potentially slow mobile connection, it keeps the client code simpler, and it means changes to downstream services can be absorbed by the BFF without forcing an app update. It also gives you a single place to handle cross-cutting concerns like auth, rate limiting, and logging.

Usually a combination. REST is the default for most mobile-facing APIs: it's simple, well-understood, cacheable, and works well with API gateways and CDN caching. GraphQL is worth considering when the app UI is data-rich and evolving quickly, or when different clients (mobile, web, partner) need different shapes of the same data. gRPC is our choice for high-throughput internal communication between services, not typically for the mobile client directly.

The right answer depends on your data model, your team, and your traffic patterns. We'll give you an honest recommendation in the architecture phase.

Azure App Service and Azure Container Apps both scale horizontally, and we design stateless services so any instance can handle any request. We use Azure Cache for Redis for hot data, Azure CDN for static and semi-static responses, and Azure Front Door for global distribution and WAF when required.

Reliability engineering starts at architecture stage: we identify single points of failure, design for graceful degradation, and build circuit breakers for external integrations. SLAs are agreed upfront and monitored through Azure Application Insights dashboards.

We assess the integration pattern the SaaS platform supports (REST API, webhook, event stream, SDK), build an adapter layer in the BFF or a dedicated integration service, and test it against the real platform. We handle auth, rate limiting, retry logic, and data mapping so the mobile app works with a stable internal contract even if the SaaS vendor changes their API.

Common integrations we have done: HubSpot, Stripe, GoCardless, DocuSign, and various identity providers. For HubSpot specifically, our HubSpot mobile integration service covers bidirectional CRM sync, triggered push notifications via custom workflow actions, in-app messaging, and transactional email.

Legacy integration is something we do regularly. The approach depends on what the system exposes: SQL database (direct query with an adapter layer), SOAP/WCF service (wrapper that presents a modern REST or GraphQL surface), file-based exchange (Azure Functions or Logic Apps watching blob storage), or something more bespoke.

In most cases we recommend building an anti-corruption layer: a service that translates between the legacy system's data model and the domain model your mobile app uses. That keeps the mobile app insulated from the complexity and constraints of the legacy system.

We follow the OWASP API Security Top 10 throughout. Specifics depend on the threat model, but standard measures include: OAuth2/OIDC with short-lived access tokens and secure refresh flows, Azure API Management for rate limiting, IP filtering, and request validation, TLS enforced throughout, no sensitive data in URLs or logs, and WAF rules for common attack patterns.

For enterprise staff apps on managed devices, we can add certificate-based mutual TLS and restrict API access to Intune-enrolled devices. For consumer apps with high fraud risk, we add additional signals: device attestation, anomaly detection, and step-up auth for sensitive operations.