Flutter Interview Handbook

Cloud & Microservices Integration

100%

Cloud & Microservices Integration

Mobile Flutter applications in enterprise environments connect directly to cloud services (GCP, AWS, Firebase) and backend microservices. Integrating cloud services requires secure authentication protocols (OAuth2 with PKCE), direct cloud storage uploads (Pre-signed URLs), and client-side resilience patterns (Circuit Breakers).


1. Cloud Architecture Integration Architecture

                               β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
                               β”‚                 CLOUD INFRASTRUCTURE                   β”‚
                               β”‚                                                        β”‚
                               β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”‚
                               β”‚  β”‚ AWS S3 / GCS      β”‚        β”‚ Auth (AWS Cognito / β”‚  β”‚
                               β”‚  β”‚ Storage Bucket    β”‚        β”‚ Firebase / OIDC)    β”‚  β”‚
                               β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β–²β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜        β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β–²β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β”‚
                               β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                                            β”‚ Direct Upload               β”‚ OAuth2 PKCE
                                            β”‚ (Pre-signed URL)            β”‚ Token Exchange
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                    β”‚                             β”‚
β”‚ Mobile App (Flutter) β”‚ ───────────────────┴─────────────────────────────┴─────────────
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
           β”‚
           β”‚ Authenticated REST / gRPC Requests
           β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚  Cloud Microservices β”‚ (Protected by Circuit Breakers & Retries)
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

2. Pre-signed URLs for Direct Cloud Storage Uploads

The Bottleneck Problem

Uploading heavy media files (images, audio, videos) through application backend servers wastes server CPU, memory, and bandwidth.

The Pre-signed URL Solution

  1. Request: Mobile app requests an upload URL from backend API (POST /api/v1/media/upload-url).
  2. Generation: Backend generates an S3 / GCS Pre-signed PUT URL with a short expiration time (e.g. 15 minutes) and specific MIME type constraints.
  3. Direct Upload: Mobile app streams binary bytes directly to AWS S3 or Google Cloud Storage using Dio or http, completely bypassing backend app servers!
Future<void> uploadImageDirectly(File imageFile) async {
  // 1. Fetch pre-signed URL from API
  final response = await api.getPresignedUrl(filename: 'avatar.png');
  final String uploadUrl = response.data['uploadUrl'];

  // 2. Stream bytes directly to Cloud Storage bucket
  final bytes = await imageFile.readAsBytes();
  await Dio().put(
    uploadUrl,
    data: Stream.fromIterable([bytes]),
    options: Options(headers: {'Content-Type': 'image/png'}),
  );
}

3. Secure Mobile Authentication: OAuth2 with PKCE

Mobile apps cannot securely store OAuth2 client_secret strings because binary binaries can be decompiled.

Proof Key for Code Exchange (PKCE)

OAuth2 PKCE replaces static client secrets with dynamic cryptographic verification:

  1. Mobile app generates a random string (code_verifier) and computes its SHA-256 hash (code_challenge).
  2. App sends user to authorization server passing code_challenge.
  3. After user logs in, authorization server returns an authorization code.
  4. App exchanges authorization code for JWT tokens by passing the original code_verifier. Server verifies SHA256(code_verifier) == code_challenge.

4. Resilience: Client-Side Circuit Breaker Pattern

When a backend microservice experiences an outage, continuous mobile client retries worsen server overload (thundering herd problem).

The Circuit Breaker States

  • Closed: Normal operations. Requests pass through.
  • Open: Microservice failed repeatedly. Incoming calls fail instantly (fail-fast) on the client without firing network requests.
  • Half-Open: Trial period testing if microservice has recovered.
  [ CLOSED ] ──(Failures exceed threshold)──► [ OPEN ] ──(Timeout expires)──► [ HALF-OPEN ]
      β–²                                          β”‚                                  β”‚
      └─────────────────(Successes pass)─────────┴────────(Failure recurs)β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

5. Trade-offs & Production Considerations

  • Pre-signed URL Expiration: Pre-signed URLs must have short expiration windows (e.g. 5-15 minutes) to prevent unauthorized reuse if intercepted.
  • Circuit Breaker UI Fallbacks: When a circuit breaker opens, the UI must render an informative offline/degraded UI state instead of showing a generic error crash dialog.