I'm also curious how people are using dry-validation/dry-schema/dry-struct to handle sinatra params from forms or sidekiq job arguments. Do people use the dry-* libraries directly, or do they use one of the other plugin libraries such as sinatra-validation, sinatra-dry_params, or sidekiq-dry?
https://github.com/IzumiSy/sinatra-validation
https://github.com/tiev/sinatra-dry_param
https://github.com/zorbash/sidekiq-dry
#dryrb #sinatra #sidekiq #params
GitHub - IzumiSy/sinatra-validation: Validation helper for Sinatra powered with dry-validation

Validation helper for Sinatra powered with dry-validation - GitHub - IzumiSy/sinatra-validation: Validation helper for Sinatra powered with dry-validation

GitHub
@postmodern In a project I worked a while back in Sinatra we were using directly the dry-* libraries.
@lucian I'm curious where you stored these classes? `lib/schemas/...`? `lib/validators/...`? `lib/forms/...`? `lib/params/...`?

@postmodern There passed some time since I worked on that project but here is the high-level structure:

We defined our own model maybe it was under `lib/model.rb` (that was actually used as composition - via include) that was versioned (as the project was a versioned API) and based on the version the model was instantiate it would call the specific dry::validation

Then we could have something like this:

@postmodern An example could be something:

```
class Accounts
class User
include AppModel

def save(params)
user = parse(params)
end

validations do |v|
v "1.0" do
# call from accounts/validations/user.rb
end
end
end
end

# usage
Accounts::User.new(version: "1.0").save(params)
```

@postmodern I think the structure of that app was domain based where we would have:

```
app/accounts/user.rb # the model
app/accounts/validations/user.rb # the dry-validation
app/accounts/routes.rb # defining the specific routes for /accounts
```
Probably something like that