Summary

At the 11th hour in our app development we have just discovered that after following the official AWS documentation use cases of adding @Auth directives on my GraphQL schema in order to allow for read-only access to a selection of users, and also built it using DataStore, which is promoted as best practice for mobile app development, the two are not compatible with each other.

Example

Here’s a simplified view of the schema and the use case:

type WorkerTimesheet
  @model
  @auth(
    rules: [
      { allow: owner, ownerField: "workerCognitoUserId" }
      { allow: owner, ownerField: "approverCognitoUserIds", operations: [read] }
    ]
  ) {
  id: ID!
  workerCognitoUserId: ID!
  approverCognitoUserIds: [ID!]
  ...
}

Details

In a pure GraphQL subscription, taking DataStore out of the equation, I can only get a subscription to fire when a WorkerTimesheet is updated, if I subscribe with a matching workerCognitoUserId field as follows:

subscription onWorkerTimesheetUpdated {
  onUpdateWorkerTimesheet(workerCognitoUserId: "owner-cognito-user-id") {
    id
    workerCognitoUserId
    approverCognitoUserIds
  }
}

That fires when the workerCognitoUserId parameter matches the owner. But how to inform the approvers?

Well this is the GraphQL subscription automatically generated by Amplify:

onUpdateWorkerTimesheet(workerCognitoUserId: String, approverCognitoUserIds: String): WorkerTimesheet @aws_subscribe(mutations: ["updateWorkerTimesheet"]) @aws_iam @aws_cognito_user_pools

So perhaps I can specify approverCognitoUserIds parameter - it’s a String so that’s promising:

subscription onWorkerTimesheetUpdated {
  onUpdateWorkerTimesheet(approverCognitoUserIds: "approver-cognito-user-id") {
    id
    workerCognitoUserId
    approverCognitoUserIds
  }
}

This doesn’t work, apparently due to quite a large limitation in how AppSync subscriptions work with array fields that I’ve since found in my increasingly desperate research has been around for many years. This begs the question how @Auth directives using multiple owners were ever anticpated would work, since subscriptions are pretty fundamental to AppSync and GraphQL, and absolutely critical for DataStore.

What is confusing to me is why the generated subscription has a approverCognitoUserIds: String field in the first place if it’s never possible to satisfy it given the targeted field is an array. Must be a bug, but this functionality has been available in Amplify for years, without exageration.

This is made much worse by the fact that turning on Amplify debug logging shows that DataStore is using that field for its subscription:

[DEBUG] 47:34.112 AWSAppSyncRealTimeProvider - subscription ready for
 {"query":"subscription operation($approverCognitoUserIds: String!) {
onUpdateWorkerTimesheet(approverCognitoUserIds: $approverCognitoUserIds) ...

And so even for WorkerTimesheets that are created with a matching workerCognitoUserId, DataStore never gets any updates for that type.

The only way it shows up is if we force it through a DataStore.stop() followed by a DataStore.start() and then it pulls the data for the matching workerCognitoUserId as well as for any user logged in that appears in the approverCognitoUserIds list. But that’s because of the initial load of the data rather than through any subscription.

If this is all correct it basically makes using the @Auth directive with a list of authorized users incompatible with using DataStore and yet I never read about any such limitation. We are at the 11th hour in our app development and it looks like we have a fundamental design change required. This is not something to be treated lightly since it’s going to affect both frontend and backend teams who have integrated around this design.

I don’t understand how this sort design limitation has been tolerated for so long and viewed as an acceptable user experience by the Amplify + AppSync teams. At the very least there should be clear documentation about these limitations to avoid wasting dozens of hours on implementations that won’t work. But even that wouldn’t really be good enough for something like this. If DataStore is not compatible with @Auth directives like this, it should fail fast, perhaps on DataStore.start() and not just silently never update its DataStore. Honestly, it makes a mockery of the first-class experience Amplify and DataStore is intending to provide.

This report may perhaps sound a bit overblown, but we have kept running into fairly serious impediments as we’ve wholeheartedly attempted to embrace both Amplify and AppSync in our latest application. I have refused to believe that a roll-your-own, undifferentiated heavy-lifting approach is better, and actively promoted using higher-level services such as AppSync and libraries such as DataStore, but after several years of them being available and these sorts of issues largely ignored/overlooked/deprioritized, I am struggling to reconcile my beliefs with my experiences unfortunately.

References to other related issues:

• https://github.com/aws-amplify/amplify-js/issues/7069
• https://github.com/aws-amplify/amplify-cli/issues/4794

This scenario I’m documenting here is far from an edge case.

References of other issues we encountered in the very recent past:

• aws-amplify/amplify-category-api#218
• https://github.com/aws-amplify/amplify-cli/issues/6352