Parameters - declarative schema validation built on top of Ecto

Good day alchemists,

Have you been writing Ecto schemas on the Web layer only to find it all a tad tedious?

Writing one for each controller action can get tiring real fast. Not writing them makes you feel insecure about sending those params to the data layer.

Fret not, I’ve released a small utility library to help with this, and I think you’re going to like it.

It is used in production for almost two years at Fave, and I’ve released some improvements to the library.

Check it out here:

I’m looking to extend the v2 with built-in features provided by Ecto like: validate_inclusion/2, validate_exclusion/2, validate_subset/2, validate_format/2, validate_confirmation/2, validate_acceptance/2 and validate_number/2

I have some ideas on parsing the AST to OpenAPI specification, but I could use some help and guide.

7 Likes

Looks really interesting Imran! Perhaps you could make a few issues on GitHub so people can know exactly how and what they can contribute?

Can you explain what advantages this library has over params (https://github.com/vic/params)?

There are already few libraries that do something similar but AFAIK none use Ecto for validating (which is quite sad and problematic).

1 Like

Can you elaborate on why it’s sad and problematic?

Ecto is not strictly to be used with a database. I’ve used it for Forms, QuerySchema and few others for simple input sanitization and validation.

There are similarities here. However, Parameters approach this differently using function annotation like @doc

The goal is to make it expressive and generate an OpenAPI spec (and maybe also @doc attribute) from the schema definitions. This is possible without additional work because during compile time Parameters has enough information about which Controller and Action it is defined at.

This is really handy.

I am currently using open_api_spex with my own module attribute based UI. My problem is that while it provides params validation it uses their own custom error format which mean that if I want to return unified error responses I need to translate one format into another, and that is pain and reduces adoption.