RequestValidator
A blazing fast request validator for your phoenix app, which validates a request body before hitting the request handler in the controller.
Why RequestValidator
It's common for a web service to validate incoming data. The most common layer where this is done is at the controller level and this sometimes leads to having a bloated controller. But with RequestValidator, you move the validation logic to a layer just before the controller and your controller is now free from doing validation.
Installation
The package can be installed by adding request_validator to your list of dependencies in mix.exs:
def deps do
[
{:request_validator, "~> 0.6"}
]
endUsage
First of all, you need to define a validation schema to be used against the incoming data.
defmodule App.Requests.Registration do
use Request.Validator
# Get the validation rules that apply to the incoming request.
@impl Request.Validator
def rules(_) do
[
email: ~w[required email]a,
first_name: ~w[required string]a,
last_name: ~w[required string]a,
password: [:required, :string, {:min, 8}, :confirmed]
]
end
# Determine if the user is authorized to make this request.
@impl Request.Validator
def authorize(_), do: true
endThe above validation schema can now be used;
defmodule App.UserController do
use AppWeb, :controller
plug Request.Validation.Plug,
register: App.Requests.Registration
def register(conn, params) do
case App.UserService.create(params) do
:ok ->
conn
|> put_status(201)
|> json(%{message: "Account created successfully"})
{:error, msg} ->
conn
|> put_status(500)
|> json(%{message: msg})
end
end
end
As you can see in the controller, the register handler does not need to worry about validating the incoming request because RequestValidator will handle that automatically and send the right response if the request fails validation based on the given validation schema.
You can specify validation schema for each of the handlers in a controller:
defmodule App.UserController do
use AppWeb, :controller
plug Request.Validation.Plug,
login: App.Requests.Login,
register: App.Requests.Registration
...
endFull documentation can be found at https://hexdocs.pm/request_validator.
Ecto Support
In some cases, your application already makes use of the ecto library. I'm glad to tell you that this library has support when the rule method returns an Ecto.Changeset struct so that you can
make use of the advantages provided by this library without rewriting your validation logic. See the example below:
defmodule App.SomeEctoSchema do
use Ecto.Schema
import Ecto.Changeset
embedded_schema do
field(:name, :string)
field(:email, :string)
field(:age, :integer)
field(:password, :string)
end
@doc false
def changeset(attrs), do: changeset(%__MODULE__{}, attrs)
@doc false
def changeset(struct, attrs) do
struct
|> cast(attrs, [:name, :email, :age, :password])
|> validate_required([:name, :email, :age, :password])
|> validate_number(:age, less_than_or_equal_to: 32)
end
end
defmodule App.Requests.TestRequest do
use Request.Validator
alias App.SomeEctoSchema
@impl Request.Validator
def rules(conn), do: SomeEctoSchema.changeset(conn.params)
@impl Request.Validator
def authorize(_), do: true
endCustom Validation Rules
This library provides a variety of helpful rules, however, you might want to define some rules to house your validation logic. To achieve this, you need to create your own rules module, extend the default rules and update the library configuration;
defmodule App.Validation.Rules do
use Request.Validator.Rules # grab default rules provided by the library
@spec uppercase(binary(), keyword()) :: :ok | {:error, binary()}
def uppercase(value, fields: _fields, field: _field) do
case String.upcase(value) do
^value ->
:ok
_ ->
{:error, "This field must be uppercase."}
end
end
endAfter defining a module with your custom rules, you will need to update your application configuration:
config :request_validator, rules_module: App.Validation.RulesOnce the new rule has been added and configuration updated, it can now be used:
# ...
def rules(_) do
[
name: ~w[required string uppercase]a
]
end
# ...
Note that if your rule accepts options/parameters, its function definition should have an arity of 3, and the second argument will be the option provided when the rule is used, ex: {:custom_rule, options}
TODOS
- Include more validation rules
- Norm validation support
- Ecto schema support
License
RequestValidator is released under the MIT License - see the LICENSE file.