Absinthe Serialization & Validation

[mmport80]

Most of the time, if I ask for data from an Absinthe API and the data provided doesn’t match the schema types specified I get an error.

Which IMO is a nice default.

Also, if I try to enter raw data into a scalar field through a GraphQL API, the parse function ensures I can only pass in valid data.

However the serialize function for data coming the other way does not give me any assurances

This looks like a similar topic:

Absinthe serialization vs field type mismatch?

I’ve been running into an issue with Absinthe where the type of the data returned in a query doesn’t match up with the type specified in the field. As far as I can tell, for many of the basic scalars (integer, float, boolean), Absinthe passes along whatever is returned by the field’s resolver function without attempting to cast to the declared type. Just to make sure, I started a fresh project and followed the How To GraphQL example through the first query at the bottom of https://www.howtogra…

Any tips on how to add validation in this case?

[f34nk]

Hi @mmport80,

there are, like always, multiple ways of doing validation on a return type.
Check out this thread on the forum: Ecto Changeset vs Absinthe Scalar Type Validation?

@law

Expressing which fields are required and what types they are is important information for people developing your app. With GraphQL, documentation of field types is coupled to validation of field types - you really can’t have one without the other. So for simple types and required validations, I don’t obscure this information.

I hope that helps.

[mmport80]

I kicked that thread off - forgot about it!

Aren’t changesets validating raw data as we try to put them into the DB?

I’d like to validate as we read data from the DB - oh and also if possible have the validations mostly in one place (another plus for Absinthe - it’s flexible and pretty much self documenting).

[benwilson512]

Hey folks.

This is for all intents and purposes an Absinthe bug that came out of I think a misguided attempt to find some optimizations around serialization. I think we can get a patch release out for the current version here shortly that prevents invalid data from being sent to the client.

[f34nk]

@mmport80

Aren’t changesets validating raw data as we try to put them into the DB?

Conceptually you can use changesets for any kind of validation.
Schemaless changesets

[mmport80]

i didn’t think about that! i love the idea of changesets

[f34nk]

Also I agree with @benwilson512 on github:

… we were better off just fixing our app to either maintain the promise of non_null or stop promising something we couldn’t guarantee.

Data integrity

data validation is a pre-requisite for data integrity

[mmport80]

Hi @benwilson512,

was this patch published? I looked around and tried a few things, and couldn’t figure out how to get my serializers to error if they hit upon bad data.

A hint in the right direction, would be great.

John