Allow for (optional) _deleted filter in GraphQL API when Conflict detection (DataStore) is enabled

[PeblTech]

Is this related to a new or existing framework?

No response

Is this related to a new or existing API?

GraphQL API, DataStore

Is this related to another service?

No response

Describe the feature you'd like to request

When a GraphQL API is created with Conflict detection (i.e. the DataStore features) turn on... then the _deleted flag should be filterable by systems that use the GraphQL API directly.

For example:-

listTenants(
   id: ID,
   filter: ModelXFilterInput,
   limit: Int,
   nextToken: String,
   sortDirection: ModelSortDirection): ModelXConnection @aws_iam

syncTenants(
   filter: ModelXFilterInput,
   limit: Int,
   nextToken: String,
   lastSync: AWSTimestamp): ModelXConnection @aws_iam

Currently has the following FIlterInput

input ModelXFilterInput {
  id: ModelIDInput
  title: ModelStringInput
  and: [ModelXFilterInput]
  or: [ModelXFilterInput]
  not: ModelXFilterInput
}

It should have the following instead

input ModelXFilterInput {
  id: ModelIDInput
  title: ModelStringInput
  _deleted: ModelBooleanInput
  and: [ModelXFilterInput]
  or: [ModelXFilterInput]
  not: ModelXFilterInput
}

The impact on DataStore sync processes are unchanged... but it allows "other" modes of engagement to filter out _deleted items on the SERVER SIDE rather than the CLIENT SIDE (and this makes all pagination aspects of the Connection valid for such requests).

Describe the solution you'd like

See above

It should have the following instead

input ModelXFilterInput {
  id: ModelIDInput
  title: ModelStringInput
  _deleted: ModelBooleanInput
  and: [ModelXFilterInput]
  or: [ModelXFilterInput]
  not: ModelXFilterInput
}

Describe alternatives you've considered

Client side filtering is the only real option and that is inadequate because of paging.

Additional context

No response

Is this something that you'd be interested in working on?

• [ ] 👋 I may be able to implement this feature request
• [ ] ⚠️ This feature might incur a breaking change

[chrisbonifacio]

Hi @PeblTech 👋 we're aware needing to filter out on the client is not ideal but we are curious what you mean by "other modes of engagement?" What would a possible solution look like for you? For example, being able to filter by _deleted in a graphql query?

[PeblTech]

My request is based on the following assumption that MAY be incorrect

The Amplify GraphQL API DOESNT expose a _deleted flag unless it's configured for DataStore use (i.e. Conflict resolution) ... Instead deleted data is simply removed (or at the very least not exposed through the API)

If this assumption is incorrect. Forget about the "other modes of engagement" bit (though the request is still valid).

If it IS correct what I mean is ... some clients use the GraphQL API are using DataStore; whereby the use of _deleted filters should be discouraged ... however "other clients" (the aforementioned "other modes of engagement") use it as a raw/standard GraphQl API and don't expect to have to sift through deleted data

The particular use case for this is:-

• One set of clients are Web/Mobile apps
• Another set of clients are other Lambdas etc (the reason for having the other Lambdas use the GraphQL API rather than directly accessing the DB is to allow AppSync to trigger necessary subscription triggers)

IMHO a consumer of a "standard" GraphQL API would not expect deleted data to show up in requests