SoberSwag
SoberSwag is a combination of Dry-Types and Swagger that makes your Rails APIs more awesome. Other tools generate documentation from a DSL. This generates documentation from types, which (conveniently) also lets you get supercharged strong-params-on-steroids.
An introductory presentation is available here.
Further documentation on using the gem is available in the docs/
directory:
- {file:docs/serializers.md Serializers}
Types for a fully-automated API
SoberSwag lets you type your API using describe blocks.
In any controller that includes SoberSwag::Controller
, you get access to the super-cool DSL method define
.
This lets you type your API endpoint:
class PeopleController < ApplicationController
include SoberSwag::Controller
define :patch, :update, '/people/{id}' do
summary 'Update a Person record.'
description <<~MARKDOWN
You can use this endpoint to update a Person record. Note that age cannot
be a negative integer.
MARKDOWN
query_params do
attribute? :include_extra_info, Types::Params::Bool
end
request_body do
attribute? :name, Types::Params::String
attribute? :age, Types::Params::Integer
end
path_params { attribute :id, Types::Params::Integer }
end
def update
# update action here
end
end
Then we can use the information from our SoberSwag definition inside the controller method:
def update
@person = Person.find(parsed_path.id)
@person.update!(parsed_body.to_h)
end
No need for params.require
or anything like that.
You define the type of parameters you accept, and we reject anything that doesn't fit.
Rendering Swagger documentation from SoberSwag
We can also use the information from SoberSwag objects to generate Swagger
documentation, available at the swagger
action on this controller.
You can create the swagger
action for a controller as follows:
# config/routes.rb
Rails.application.routes.draw do
# Add a `swagger` GET endpoint to render the Swagger documentation created
# by SoberSwag.
resources :people do
get :swagger, on: :collection
end
# Or use a concern to make it easier to enable swagger endpoints for a number
# of controllers at once.
concern :swaggerable do
get :swagger, on: :collection
end
resources :people, concerns: :swaggerable do
get :search, on: :collection
end
resources :places, only: [:index], concerns: :swaggerable
end
If you don't want the API documentation to show up in certain cases, you can use an environment variable or a check on the current Rails environment.
# config/routes.rb
Rails.application.routes.draw do
resources :people do
# Enable based on environment variable.
get :swagger, on: :collection if ENV['ENABLE_SWAGGER']
# Or just disable in production.
get :swagger, on: :collection unless Rails.env.production?
end
end
Typed Responses
Want to go further and type your responses too? Use SoberSwag output objects, a serializer library heavily inspired by Blueprinter
PersonOutputObject = SoberSwag::OutputObject.define do
field :id, primitive(:Integer)
field :name, primitive(:String).optional
# For fields that don't map to a simple attribute on your model, you can
# use a block.
field :is_registered, primitive(:Bool) do |person|
person.registered?
end
end
Now, in your define
block, you can tell us that this is the type of your response:
class PeopleController < ApplicationController
include SoberSwag::Controller
define :patch, :update, '/people/{id}' do
request_body do
attribute? :name, Types::Params::String
attribute? :age, Types::Params::Integer
end
path_params { attribute :id, Types::Params::Integer }
response(:ok, 'the updated person', PersonOutputObject)
end
def update
person = Person.find(parsed_path.id)
if person.update(parsed_body.to_h)
respond!(:ok, person)
else
render json: person.errors
end
end
end
Support for easily typing "render the activerecord errors for me please" is (unfortunately) under development.
SoberSwag Input Objects
Input parameters (including path, query, and request body) are typed using dry-struct. You don't have to do them inline. You can define them in another file, like so:
User = SoberSwag.input_object do
attribute :name, SoberSwag::Types::String
# use ? if attributes are not required
attribute? :favorite_movie, SoberSwag::Types::String
# use .optional if attributes may be nil
attribute :age, SoberSwag::Types::Params::Integer.optional
end
Then, in your controller, just do:
class PeopleController < ApplicationController
include SoberSwag::Controller
define :path, :update, '/people/{id}' do
request_body(User)
path_params { attribute :id, Types::Params::Integer }
response(:ok, 'the updated person', PersonOutputObject)
end
def update
# same as above!
end
end
Under the hood, this literally just generates a subclass of Dry::Struct
.
We use the DSL-like method just to make working with Rails' reloading less annoying.
Nested object attributes
You can nest attributes using a block. They'll return as nested JSON objects.
User = SoberSwag.input_object do
attribute :user_notes do
attribute :note, SoberSwag::Types::String
end
end
If you want to use a specific type of object within an input object, you can nest them by setting the other input object as the type of an attribute. For example, if you had a UserGroup object with various Users, you could write them like this:
User = SoberSwag.input_object do
attribute :name, SoberSwag::Types::String
attribute :age, SoberSwag::Types::Params::Integer.optional
end
UserGroup = SoberSwag.input_object do
attribute :name, SoberSwag::Types::String
attribute :users, SoberSwag::Types::Array.of(User)
end
Input and Output Object Identifiers
Both input objects and output objects accept an identifier, which is used in the Swagger Documentation to disambiguate between SoberSwag types.
User = SoberSwag.input_object do
identifier 'User'
attribute? :name, SoberSwag::Types::String
end
PersonOutputObject = SoberSwag::OutputObject.define do
identifier 'PersonOutput'
field :id, primitive(:Integer)
field :name, primitive(:String).optional
end
You can use these to make your Swagger documentation a bit easier to follow,
and it can also be useful for 'namespacing' objects if you're developing in
a large application, e.g. if you had a pet store and for some reason users
with cats and users with dogs were different, you could namespace it with
identifier 'Dogs.User'
.
Adding additional documentation
You can use the .meta
attribute on a type to add additional documentation.
Some keys are considered "well-known" and will be present on the swagger output.
For example:
User = SoberSwag.input_object do
attribute? :name, SoberSwag::Types::String.meta(description: <<~MARKDOWN, deprecated: true)
The given name of the students, with strings encoded as escaped-ASCII.
This is used by an internal Cobol microservice from 1968.
Please use unicode_name instead unless you are that microservice.
MARKDOWN
attribute? :unicode_name, SoberSwag::Types::String
end
This will output the swagger you expect, with a description and a deprecated flag.
Adding Default Values
Sometimes it makes sense to specify a default value. Don't worry, we've got you covered:
QueryInput = SoberSwag.input_object do
attribute :allow_first, SoberSwag::Types::Params::Bool.default(false) # smartly alters type-definition to establish that passing this is not required.
end
Tags
If you want to organize your API into sections, you can use tags
.
It's quite simple:
define :patch, :update, '/people/{id}' do
# other cool config
tags 'people', 'mutations', 'incurs_cost'
end
This will map to OpenAPI's tags
field (naturally), and the UI codegen will automatically organize your endpoints by their tags.
Testing the validity of output objects
If you're using RSpec and want to test the validity of output objects, you can do so relatively easily.
For example, assuming that you have a UserOutputObject
class for representing a User record, and you have a :user
factory via FactoryBot, you can validate that the serialization works without error like so:
RSpec.describe UserOutputObject do
describe 'serialized result' do
subject do
described_class.type.new(described_class.serialize(create(:user)))
end
it 'works with an object' do
expect { subject }.not_to raise_error
end
end
end
Special Thanks
This gem is a mishmash of ideas from various sources. The biggest thanks is owed to the dry-rb project, upon which the typing of SoberSwag is based. On an API design level, much is owed to blueprinter for the serializers. The idea of a strongly-typed API came from the Haskell framework servant. Generating the swagger documentation happens via the use of a catamorphism, which I believe I first really understood thanks to this medium article by Jared Tobin.