Simplifying internal validations using Dry-Validation

When building APIs for other developers, it’s often important to draw the line between other programmers input data and the internal world of your library. This process is called data validation and you’re probably familiar with this name.

What you may not know, is the fact that it can be achieved in many ways.

One that I particularly like is by using the dry-validation library. Here’s an example on how you can separate the validation from the actual business logic without actually changing the API of your library.

The inline way

The easiest way to provide validations is to embed the checks in a place where you receive the data.

This approach is great for super simple cases like the one below:

def sum(arg1, arg2)
  raise ArgumentError unless arg1
  raise ArgumentError unless arg2

  arg1.to_i + arg2.to_i
end

sum(2, nil) #=> ArgumentError (ArgumentError)

However, if you decide to follow this road, you will quickly end up with something really unreadable.

This code sample is taken from the ruby-kafka library and it’s used to validate the method input. I’ve removed the business logic parts as they aren’t relevant to the context of this article:

def build(
  ca_cert_file_path: nil,
  ca_cert: nil,
  client_cert: nil,
  client_cert_key: nil,
  client_cert_chain: nil,
  ca_certs_from_system: nil
)
  return nil unless ca_cert_file_path ||
                    ca_cert ||
                    client_cert ||
                    client_cert_key ||
                    client_cert_chain ||
                    ca_certs_from_system

  if client_cert && client_cert_key
    # business irrelevant to the checks
    if client_cert_chain
      # business irrelevant to the checks
    end
  elsif client_cert && !client_cert_key
    raise ArgumentError, "initialized with ssl_client_cert` but no ssl_client_cert_key"
  elsif !client_cert && client_cert_key
    raise ArgumentError, "initialized with ssl_client_cert_key, but no ssl_client_cert"
  elsif client_cert_chain && !client_cert
    raise ArgumentError, "initialized with ssl_client_cert_chain, but no ssl_client_cert"
  elsif client_cert_chain && !client_cert_key
    raise ArgumentError, "initialized with ssl_client_cert_chain, but no ssl_client_cert_key"
  end

  # business
end

Despite looking simple, the if-elsif validation is really complex and it brings many things to the table:

• it checks several variables,
• mixes the checks together due to the if-flow,
• in the end it actually only checks the presence of the variables,
• despite expecting string values, it will work with anything that is provided,
• it forces us to spec out the validation cases with the business logic as they are coupled together.

Luckily for us, there’s a better way to do that.

The private schema way

We can achieve the same functionality and much more just by extracting the validations into a separate internal class. Let’s build up only the interface for now.

Note, that I’m leaving the ArgumentError and the external API intact, as I don’t want this change to impact anything that is outside of this class:

require 'dry-validation'

# Empty schema for now, we will get there
SCHEMA = Dry::Validation.Schema {}

def build(
  ca_cert_file_path: nil,
  ca_cert: nil,
  client_cert: nil,
  client_cert_key: nil,
  client_cert_chain: nil,
  ca_certs_from_system: nil
)
  input = {
    ca_cert_file_path: ca_cert_file_path,
    ca_cert: ca_cert,
    client_cert: client_cert,
    client_cert_key: client_cert_key,
    client_cert_chain: client_cert_chain,
    ca_certs_from_syste: ca_certs_from_system
  }

  # Do nothing if there's nothing to do
  return nil if input.values.all?(&:nil?)

  results = SCHEMA.call(input)
  raise ArgumentError, results.errors unless results.success?

  # Business logic
end

We’ve managed to extract the validation logic outside.

Thanks to that, now we have:

• separation of responsibilities,
• business applying method that we can test against only valid cases,
• validation object that we can test in isolation,
• much cleaner API that can be easier expanded (new arguments, new data types supported, etc) and/or replaced,
• way to handle more complex validations (types, formats, etc),
• support for reporting multiple issues with the input at the same time.

We can now perform all the checks and only when everything is good, we will run the business. But what about the validation itself?

Actually all the validations below are copy-pasted from the karafka repository. Here’s the dry-validation documentation.

require 'dry-validation'

SCHEMA = Dry::Validation.Schema do
  %i[
    ca_cert
    ca_cert_file_path
    client_cert
    client_cert_key
    client_cert_chain
  ].each do |encryption_attribute|
    optional(encryption_attribute).maybe(:str?)
  end

  optional(:ca_certs_from_system).maybe(:bool?)

  rule(
    client_cert_with_client_cert_key: %i[
      client_cert
      client_cert_key
    ]
  ) do |client_cert, client_cert_key|
    client_cert.filled? > client_cert_key.filled?
  end

  rule(
    client_cert_key_with_client_cert: %i[
      client_cert
      client_cert_key
    ]
  ) do |client_cert, client_cert_key|
    client_cert_key.filled? > client_cert.filled?
  end

  rule(
    client_cert_chain_with_client_cert: %i[
      client_cert
      client_cert_chain
    ]
  ) do |client_cert, client_cert_chain|
    client_cert_chain.filled? > client_cert.filled?
  end

  rule(
    client_cert_chain_with_client_cert_key: %i[
      client_cert_chain
      client_cert_key
    ]
  ) do |client_cert_chain, client_cert_key|
    client_cert_chain.filled? > client_cert_key.filled?
  end
end

The execution effect is also really good:

build(ca_cert: 2) #=> {:ca_cert=>["must be a string"]} (ArgumentError)

Summary

Whenever you find yourself adding some inline validations, stop and think twice, there’s probably a better and more extendable way to do it.

---

Originally published at The Castle blog.

The post Simplifying internal validations using Dry-Validation appeared first on Running with Ruby.