The AWS Amplify CLI is a toolchain for simplifying serverless web and mobile development. This plugin provides functionality for the API category, allowing for the creation and management of GraphQL and REST based backends for your amplify project.
I want the keys property to be required, but there's no required() method on customType. So the only way to achieve this is to extract it to its own customType and use a ref to it:
SubscriptionKeys: a
.customType({
p256dh: a.string().required(),
auth: a.string().required(),
}),
NotificationSubscription: a
.customType({
endpoint: a.string().required(),
keys: a.ref('SubscriptionKeys').required(),
}),
As discussed heavily in other issues, this is also the only way to have a nested customType be an array or to set authorization rules on it.
If a data model is even moderately hierarchical this rapidly becomes hard to read, hard to maintain, and generally unwieldy. I think this really needs to be setup so we can do:
NotificationSubscription: a
.customType({
endpoint: a.string().required(),
keys: a.customType({
p256dh: a.string().required(),
auth: a.string().required(),
}).array().required().authorization(), // etc.
}),
If it's possible with the verbose syntax, it should be possible with simplified syntax allowing a more complicated model that's stored in one table to be expressed much more succinctly.
Hi @jpangburn 👋 thanks for raising this issue. I'll mark it as a feature request for the team to consider since it seems more like a potential improvement to DX than a bug.
Environment information
Data packages
Description
Suppose I have the following model or customType:
I want the
keys
property to be required, but there's norequired()
method oncustomType
. So the only way to achieve this is to extract it to its own customType and use a ref to it:As discussed heavily in other issues, this is also the only way to have a nested customType be an array or to set authorization rules on it.
If a data model is even moderately hierarchical this rapidly becomes hard to read, hard to maintain, and generally unwieldy. I think this really needs to be setup so we can do:
If it's possible with the verbose syntax, it should be possible with simplified syntax allowing a more complicated model that's stored in one table to be expressed much more succinctly.
Thank you for your consideration!