Validate - simple & flexible input validation

Hey! One thing I’ve been struggling with since switching to elixir and phoenix is validating incoming request data, whether it be from an API route or an html form. Coming from the Laravel world, I was used to having a powerful request validation system baked in that isn’t tied to your data schema.

So I created Validate



TL;DR and examples

Features include:

  • Lots of validation rules built in
  • Custom validation rules via inline functions or modules
  • Plug compatibility (validate and authorise controller actions before reaching the method)
  • Automatically strips keys from maps that aren’t present in the rules, preventing attackers from throwing extraneous data at you
  • Infinite nesting of lists/maps to support complex JSON structures

There are lots of examples in the readme but here’s a quick look at how you could use it:

input = %{
  "email" => "",
  "plan" => "free",
  "team" => %{"name" => "Test Team"}

rules = %{
  "email" => [required: true, type: :string, max: 50],
  "plan" => [required: true, type: :string, in: ["free", "pro"]],
  "team" => [
    required: true,
    type: :map,
    map: %{"name" => [required: true, type: :string]}

# depending on the result
{:ok, data} = Validate.validate(input, rules)
{:error, errors} = Validate.validate(input, rules)

Why not just ecto?

Although you can technically do form validation through ecto changesets directly on your schemas, and embedded changesets for other data, I found I was constantly typing the same stuff over again, and it quickly gets complicated once you start working with nested and optional data.

Why not library x/y/z?

There are a few great validation libraries out there already but I wanted more than seemed to be offered. Stripping extraneous keys, nesting of maps/lists, and built-in plug support were all hard to find in one single library.

Is it fast?

Honestly, not sure. I have not benchmarked it on massive lists or multi-MB payloads yet. Since we are potentially stripping keys out of the input it means we have to keep a second copy of the data as we loop through and validate. I’m sure this could be optimised more than I have it currently, but I am still learning :slight_smile:

Will more validation rules be added?

Yes! Right now I’ve been using Laravel’s validation rules as inspiration for rules but there are still a few missing which I will add over time. In the meantime, if you find that a rule is not present you can write an inline custom validator really easily.

Would love any feedback/critique! I’ve been using elixir off and on over the years but only recently started writing it daily these past few months, so some of the code has room to be improved.

This package was a lot of fun to build :smile:


I like the library, but one thing that’s been bothering me recently is that when you specifiy an :id in a path, the resulting value in your params will be a string even though you want it to be an integer.
I’d love for the type: :integer check to allow for this and return the integer value.

1 Like

you’re right that is a common issue, we could maybe add a built in cast: :integer rule that handles this automatically by trying to cast to the provided type, and returning a validation error if it fails.

in the mean time, you could accomplish this with a custom validation rule that passes the transformed value to the success result like:

rules = %{
  "id" => [
    required: true,
    custom: fn %{ value: value } ->
      case Integer.parse(value) do
        {id, _} -> Validate.Validator.success(id)
        _ -> Validate.Validator.halt("must be an integer")

input = %{"id" => "123"}

{:ok, data} = Validate.validate(input, rules)

data["id"] == 123

Or maybe just cast: true as it would be strange to cast to en integer with a string type.

just released v1.3.0 which added a bunch of new validation rules:

  • cast
  • characters
  • ip
  • url
  • uuid
  • date_string
  • ==
  • >
  • >=
  • <
  • <=