Migrating with gradual type validations

[viralpraxis]

After migrating ~100 legacy services to Actor I can say that the most annoying and error-prone aspect of the process was adding type validations. We'd like to have have these validations defined for every input and output (both for correctness and self-documenting), but in many cases it was hard to say if runtime-generated objects would satisfy type constraints. For example, for User::Destroy actor we'd do something like

class User::Destroy < ApplicationService
  input :id, type: Integer

  play ->(actor) { User.find_by(id: actor.id)&.destroy! }
end

which is a correct actor unless we forget to apply to_i conversion somewhere in client code:

# users_controller.rb
def destroy
  User::Destroy.call(id: params[:id]) # parameter `id` might be either of type `Integer` or `String`
end

Note that User::Destroy is parametrically polymorphic due to silent ActiveRecord conversions (i.e. find(...) works both with String and Integer if numeric primary keys are used)

So I've come up with some sort of gradual migration mechanism with the following implementation:

# app/services/application_service.rb
class ApplicationService < Actor
  SAFE_TYPE_VALIDATOR = ->(type_specification, input_name) do
    ->(value) do
      return true if Array.wrap(type_specification).any? { value.is_a?(_1) }

      if Rails.env.local?
        false
      else
        Sentry.capture_message(...) # might report `input_name` for clarification

        true
      end
    end.freeze
  end.freeze
end

Actors utilize this feature like this:

class User::Destroy < ApplicationService
  input :id, must: {
    have_valid_type: SAFE_TYPE_VALIDATOR[[Integer, String], :id]
  }

  play ->(actor) { User.find_by(id: actor.id)&.destroy! }
end

In case of type mismatch in local environments an exception will be raised; in production it will be simply reporter and the actor will be executed just like there were no type validations.

NOTES:

1. SAFE_TYPE_VALIDATOR generated lambdas should implicitly return true in order to avoid type-check failrue
2. Array.wrap is an AS feature, use [*type_specification] for rails-less environments
3. These safe checks should be replaced with "normal" type checks after some time

[dmkl]

Wouldn't input :id, type: [Integer, String] be enough? You still want to fail if decimal is passed as a user ID for some reason, right? And with SAFE_TYPE_VALIDATOR it will pass it through on production.

[viralpraxis]

hey @dmkl, long time no see 🙂

Wouldn't input :id, type: [Integer, String] be enough?

In this particular example (which is probably oversimplified) -- yes, that would be enough (and I actually did the same in some cases). But there were, for instance, parametrically polymorphic actors with input types (e.g. [Type_1, Type_2, Type_3]) so that their lowest common ancestor is Object (or just too generic). And I couldn't be sure there's not Type_4 passed in runtime so I wanted to have some gradual migration mechanics.

You still want to fail if decimal is passed as a user ID for some reason, right? And with SAFE_TYPE_VALIDATOR it will pass it through on production.

In case of migrating battle-tested service object we can assume no decimals are passed in runtime -- so in that case I'm just trying to safely detect if only integers are passed. After running with SAFE_TYPE_VALIDATOR production for some time and making sure it doesn't fire I can safely remove it in favor of input :id, type: [...]

So the entire strategy is "using legacy validation-less services" -> "using actors with SAFE_TYPE_VALIDATOR for a few days" -> "using actors with normal validations"

[dmkl]

Thanks for more context details. Sounds great! Thank you for sharing!