Open bboure opened 5 years ago
Thank you for your comment. This feature request is in the backlog but I have noted this feedback for prioritization.
This feature was developed?
@mikeparisstuff kindly, is there some sort of ballpark eta on this feature?
Is there an update on this feature request?
Is their an update on this?
+1 for this :)
Any update?
I'm here. Any update?
Is there any update on this issue? Is it still prioritised? Would very much like to have custom scalar types.
Any update on this feature ?
I would be a fan of this feature as well!
3 years and still nothing done for this?
Yes please
+1
+1 ??
+1
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
CurrencyAmount
type 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
CurrencyAmount
to 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.
+1
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
+1
+1
+1
+1
+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.
+1
Happy new year guys, this is the most wanted feature.
I think this is difficult for them to implement. So I don't see it coming anytime soon.
Furthermore, I would make the case that Federation would be a much more impactful feature release. (Although it is technically supported, there is no support for a managed apollo router or federated schema in the console)
Are there any workarounds for this issue?
+1
+1
+1
+1
+1
+1
We want to have custom scalars so that:
+1
I sort of made this work in a specific context for binary. Just built might be lots of bugs lol. https://www.npmjs.com/package/graphql-binary-transformer https://github.com/austinamorusoyardstick/graphql-binary-transformer Also only supports v1 transformer
This is also a blocker for us to adopt AppSync at the moment, as we need to implement a common Schema that required user defined types. We would really love to avoid having to implement self hosted severless subscription if possible and leverage AppSync
+1
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.