aws-appsync-community
aws-appsync-community copied to clipboard
aws
Custom scalar types
AppSync comes with the default GraphQL scalar types and with some handy additional AWS types. It would be nice, however, to be able to add custom scalar types as well.
Thank you for your comment. This feature request is in the backlog but I have noted this feedback for prioritization.
@mikeparisstuff kindly, is there some sort of ballpark eta on this feature?
Is there any update on this issue? Is it still prioritised? Would very much like to have custom scalar types.
Or at least rename AWSTimestamp, AWSDateTime etc. to Timestamp, DateTime. Revealing the cloud provider for customers is a potential security problem for that company.
This feature would make a difference for us. It would improve expressiveness of the schema, and on the other hand it would allow us to map the custom scalar type from the schema to the strongly typed module in the app. For example, we'd like to have a CurrencyAmount type that serializes to a String, but it is not the same to see:
... on Product {
price: CurrencyAmount!
}
and
... on Product {
price: String!
}
Imagine now we set up our tooling to convert CurrencyAmount to whatever type would make our life easier in the app, certainly not a string.
This feature would make a difference for us. It would improve expressiveness of the schema, and on the other hand it would allow us to map the custom scalar type from the schema to the strongly typed module in the app. For example, we'd like to have a
CurrencyAmounttype that serializes to aString, but it is not the same to see:... on Product { price: CurrencyAmount! }and
... on Product { price: String! }Imagine now we set up our tooling to convert
CurrencyAmountto whatever type would make our life easier in the app, certainly not astring.
I strongly agree with you. If we could match a custom scalar with a particular regex in order to efficiently check the validity of a given value, that would be great.
We definitely need this feature; it actually is a blocker for us, when trying to adopt AppSync in our current architecture.
Custom scalars aside, I think at least adding support for graphql-scalars would probably make most of us happy.
https://www.graphql-scalars.dev/docs
As @ottosipe mentioned, support for graphql-scalars is a must for adoption of projects I'm involved in. We have String data types that need to conform with specific rules and require that validation provided with that above package.
Not confident of traction with this feature though having been opened over 3 years ago...
+1, lack of custom scalars is a huge blocker for AppSync adoption for us, the whole purpose of GraphQL is expressive type system. We have a "no String" policy in our schema.
