Info on scalar types, field authZ, field validations

[skryshi]

The docs are really sparse on details. As we move to integrate Amplify, some basic questions are coming up:

1. How can we add our own scalar types? For example, Int64 and Double.

2. How do we create models where fields have different authZ rules? For example,

type User @model {
  username: ID!
  password: String!
  first_name: String!
}

Record owner has read/write permissions to all fields. Other users only have read permission to first_name field. How do we set this up?

3. How and where do we put validation logic? For example,

type Message @model {
  sender_id: ID!
  chat_id: ID!
  text: String!
}

The server needs to verify that sender_id is equal to logged in user's id. That chat_id is valid and that sender_id is part of that chat. That text is less than 140 characters long. How do we set these up?

[lawmicha]

Hi @skryshi , thanks for the questions. I'll answers these to the best of my knowledge, while some details I may not be too sure about and we can follow up on your additional questions

1. Scalar types

I believe you can use Float for Double.

type Todo @model {
  id: ID!
  name: String!
  description: String
  someValue: Float
}

The scalar types can be found here https://docs.aws.amazon.com/appsync/latest/devguide/scalars.html When running amplify codegen models, I can see that the generated Model class contains public var someValue: Double?

In Swift, i believe the Int can hold up to Int64. However, if using the AppSync service through Amplify API or Amplify DataStore with sync to cloud enabled would then mean that the values persisted should only be between -(2^31) and (2^31 - 1) or else calls to the service will fail.

2. Auth Rules

To enable finer grain permission checks, you can annotate the model with the auth directive. This is currently in development when using Amplify DataStore with some limitations. If you are looking to achieve just the API functionality of:

Record owner has read/write permissions to all fields. Other users only have read permission to first_name field

See field level auth for more details, then once you have the schema

1. amplify add api and choose GraphQL, and provide the schema
2. Choose UserPool authorization mode
3. amplify push will provision AppSync and Userpool
4. pod install, use AWSCogniitoAuthPlugin and AWSAPIPlugin
5. Construct the call using GraphQLRequest which takes the query document and query variables.

APIPlugin will automatically add the authorization token to the requests if the user is authenticated via Amplify.Auth.signIn and make the API calls to the AppSync endpoint. If there are additional questions regarding the use case with auth directives, we can create a new issue specifically to address that either here or in the CLI repo

3. Validation Logic

for sender_id: String you can set this as the ownerField in the auth directive such as allow: owner, ownerField: "sender_id", identityClaim: "[Custom value for the identity claim]" which will auto populate the sender_id as the claim value specified in the identityClaim. This should be optional. and the Message should have it's own unique identifier like

type Message @model @auth(rules: [{ allow: owner, ownerField: 'sender_id', identityClaim:"[custom value]"}]{
  id: String
  sender_id: String
  chat_id: ID!
  text: String!
}

If a Message is always part of a chat, you can use the @connection directive to enforce the message is created with a required Chat (chat: Chat!)

type Chat @model {
   id: ID!
   // additional fields
   messages: [Message] @connection(name: "MessageChat")
}
type Message @model {
  id: ID!
   // additional fields
  chat: Chat! @connection(name: "MessageChat")
}

As for service level validation on text i can't really think of a way other than doing this on the client side

[skryshi]

@lawmicha Thank you for detailed answer. Please see my comments below:

1. Scalar types

Right, I meant if we use Amplify DataStore with cloud sync, is it possible to define Int64, Double types? Since DynamoDB supports numbers with up to 38 digits of precision, this seems possible.

2. Auth Rules

Yes, that's exactly what I was looking for. Thank you.

3. Validation Logic

Is it possible to write custom resolvers to validate text field length? Resolvers that invoke a lambda function perhaps? Since the client can never be trusted, any production app requires server-side field validation. Checking usernames validity, verifying passwords strengths, removing javascript from text fields, etc.

[lawmicha]

Right, I meant if we use Amplify DataStore with cloud sync, is it possible to define Int64, Double types? Since DynamoDB supports numbers with up to 38 digits of precision, this seems possible.

I see, so to recap: as long as you use Int in the graphQL schema, provisioned backend will use the AppSync's GraphQL Int Scalar which holds between -(2^31) and 2^31 - 1. When codegenerating the models, that will use the Swift Int which is 64bit i believe on 64bit platforms, so the limitation would be on the service to hold up to 2^31-1 values which is less than Swift's Int type. This looks like an AppSync limitation if DynamoDB supports higher values then i don't think it will be possible since validation happens at the AppSync service before mapping those values to the dynamoDB insert. Maybe there is a way to a custom graphQL type to store Int64 and store that as the number in DynamoDB that supports larger values, but would be outside of using Amplify's graphQL transform and hand rolling your schema and data resolvers on AppSync

Is it possible to write custom resolvers to validate text field length? Resolvers that invoke a lambda function perhaps? Since the client can never be trusted, any production app requires server-side field validation. Checking usernames validity, verifying passwords strengths, removing javascript from text fields, etc.

I've seen a directive here: https://docs.amplify.aws/cli/graphql-transformer/directives#function that lets you trigger a lambda of an AppSync call

Both questions relate to Amplify transformer/AppSync/DynamoDB provisioning. If you have further questions, we could create a new issue over in https://github.com/aws-amplify/amplify-cli to clarify your use case and options you have to achieve it

[skryshi]

Ok, got it, thank you for pointing me in the right direction. I found some relevant info in the amplify-cli rep, eg: aws-amplify/amplify-category-api#447