如何处理AWS AppSync破坏性更新？保障iOS旧版本应用兼容

Great question—managing breaking changes in AppSync while supporting legacy app versions is a super common pain point, especially when deploying via Serverless Framework. Let’s break down the most reliable approaches and address your core question:

1. API Versioning (The Safest Approach for Breaking Changes) #

When you’re making truly breaking changes (like deleting fields, altering return types, or changing required arguments), the cleanest way to avoid disrupting older app versions is to deploy a new version of your AppSync API alongside the existing one. Here’s how to do this with Serverless:

• Define multiple APIs in your serverless.yml: Use the aws-appsync plugin to configure separate API instances for each version. For example:

  custom:
    appSync:
      # Legacy API (for older iOS app versions)
      - name: my-app-api-v1
        schema: ./schema-v1.graphql
        authenticationType: API_KEY
        apiKey: ${env:APPSYNC_API_KEY_V1}
        # other v1-specific config (datasources, resolvers, etc.)
      # New API (for updated iOS app)
      - name: my-app-api-v2
        schema: ./schema-v2.graphql
        authenticationType: API_KEY
        apiKey: ${env:APPSYNC_API_KEY_V2}
        # v2-specific config with breaking changes
  

• Point app versions to their respective APIs: Update your iOS app’s new version to use the v2 API endpoint and credentials, while leaving the old version configured to use v1. This way, both APIs run in parallel, and users on older versions won’t experience any downtime or errors.

2. Schema Evolution with Fallbacks (For Partial/Non-Critical Changes) #

If your “breaking change” can be softened with backward-compatible tweaks, you might not need a full new API. For example:

• Keep old fields but mark them as deprecated: Add new fields for your updated logic, and use the @deprecated directive on old fields to signal they’ll be removed later.

  type User {
    id: ID!
    oldUsername: String @deprecated(reason: "Use 'username' instead")
    username: String! # New field for v2 app
  }
  

• Use unions/interfaces for flexible return types: If you’re changing a return type, wrap both old and new types in a union so the API can return either, and let the app handle the appropriate case.

This works for minor changes, but if your change is truly destructive (e.g., removing a field that older apps rely on), schema evolution won’t cut it—stick to API versioning.

Do You Need a New API for Every App Version? #

No, you don’t need a new API for every single app update—only for changes that break backward compatibility with older app versions. For small, non-breaking updates (adding new fields, optional arguments), you can safely update the existing API without creating a new version.

That said, for major breaking changes, spinning up a new API is the most reliable way to isolate changes and avoid impacting users who haven’t updated their apps yet.

Bonus: Deprecation Strategy #

Once most users have migrated to the new app version (track this via analytics or API usage metrics), you can start phasing out the old API:

1. Add warning logs to the v1 API to track remaining usage.
2. Notify remaining users (via in-app messages) to update their app.
3. Finally, delete the v1 API resources via your Serverless deployment once usage drops to zero.

内容的提问来源于stack exchange，提问作者Quentin Hayot