aws / aws-appsync-community

The AWS AppSync community
https://aws.amazon.com/appsync
Apache License 2.0
506 stars 32 forks source link

Custom scalar types #26

Open bboure opened 5 years ago

bboure commented 5 years ago

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.

mikeparisstuff commented 5 years ago

Thank you for your comment. This feature request is in the backlog but I have noted this feedback for prioritization.

vvenegasv commented 4 years ago

This feature was developed?

klyondx commented 4 years ago

@mikeparisstuff kindly, is there some sort of ballpark eta on this feature?

CorbinAmmanBF commented 4 years ago

Is there an update on this feature request?

Cliftonz commented 4 years ago

Is their an update on this?

th3m477 commented 3 years ago

+1 for this :)

MontoyaAndres commented 3 years ago

Any update?

Danue1 commented 3 years ago

I'm here. Any update?

tglastra commented 3 years ago

Is there any update on this issue? Is it still prioritised? Would very much like to have custom scalar types.

jcvargasGit commented 2 years ago

Any update on this feature ?

ben-elsen commented 2 years ago

I would be a fan of this feature as well!

zerubeus commented 2 years ago

3 years and still nothing done for this?

joekendal commented 2 years ago

Yes please

fes300 commented 2 years ago

+1

mirrorshades commented 2 years ago

+1 ??

samjett247 commented 2 years ago

+1

joekendal commented 2 years ago

Or at least rename AWSTimestamp, AWSDateTime etc. to Timestamp, DateTime. Revealing the cloud provider for customers is a potential security problem for that company.

vknez commented 2 years ago

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.

Cwellan commented 2 years ago

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.

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.

irimiab commented 2 years ago

We definitely need this feature; it actually is a blocker for us, when trying to adopt AppSync in our current architecture.

ottosipe commented 2 years ago

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

younesea commented 2 years ago

+1

byrne-greg commented 2 years ago

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...

Jrodna commented 2 years ago

+1

diegoNutmeg commented 2 years ago

+1

biggytech commented 2 years ago

+1

c-kle commented 1 year ago

+1

neaumusic commented 1 year ago

+1

leehambley commented 1 year 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.

veerendrapatel commented 1 year ago

+1

ivands commented 1 year ago
zerubeus commented 1 year ago

Happy new year guys, this is the most wanted feature.

joekendal commented 1 year ago

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)

andresionek91 commented 1 year ago

Are there any workarounds for this issue?

eduardo-caua commented 1 year ago

+1

NickSun commented 1 year ago

+1

ghost commented 1 year ago

+1

ariksfaradi commented 1 year ago

+1

felipepxavier commented 1 year ago

+1

wireframe-sensei commented 1 year ago

+1

louislarry commented 1 year ago

We want to have custom scalars so that:

Axum666 commented 10 months ago

+1

austinamorusoyardstick commented 9 months ago

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

brendan-fox-shure commented 7 months ago

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

kniffo80 commented 6 months ago

+1