Description
A demo app can be found in the spec here.
An implementation of role-based policies and operations to help controllers lose weight.
The goal of this project is to help API apps be more slim, and separate logic as much as possible.
If you have an idea or suggestion for improved defaults, please submit an issue or pull request. :-)
skinny_controllers alternatives and similar gems
Based on the "Abstraction" category.
Alternatively, view skinny_controllers alternatives based on common mentions on social networks and blogs.
-
Trailblazer
The advanced business logic framework for Ruby. -
Interactor
Interactor provides a common interface for performing complex user interactions. -
wisper
A micro library providing Ruby objects with Publish-Subscribe capabilities -
Responders
A set of Rails responders to dry up your application -
ActiveInteraction
:briefcase: Manage application specific business logic. -
Decent Exposure
A helper for creating declarative interfaces in controllers -
Mutations
Compose your business logic into commands that sanitize and validate input. -
Rails Event Store
A Ruby implementation of an Event Store based on Active Record -
dry-types
Flexible type system for Ruby with coercions and constraints -
Light Service
Series of Actions with an emphasis on simplicity. -
Amoeba
A ruby gem to allow the copying of ActiveRecord objects and their associated children, configurable with a DSL on the model -
SimpleCommand
A simple, standardized way to build and use Service Objects (aka Commands) in Ruby -
Waterfall
A slice of functional programming to chain ruby services and blocks, thus providing a new approach to flow control. Make them flow! -
u-service
Represent use cases in a simple and powerful way while writing modular, expressive and sequentially logical code. -
PageletRails
Improve perceived performance of your rails application with minimum effort -
Surrounded
Create encapsulated systems of objects and focus on their interactions -
Smart Init - Simple service objects in Ruby
A simple gem for eliminating Ruby initializers boilerplate code, and providing unified service objects API -
SuperModule
SuperModule allows defining class methods and method invocations the same way a super class does without using def included(base). This also succeeds ActiveSupport::Concern by offering lighter syntax -
Rocketman
๐ Rocketman help build event-based/pub-sub code in Ruby -
Strategic
Strategic - Painless Strategy Pattern in Ruby and Rails -
Invokable
Objects are functions! Treat any Object or Class as a Proc (like Enumerable but for Procs). -
Lionshare
A Ruby interface to the Lionshare API (cryptocurrency prices) -
EasilyTypable
Ruby module that facilitates English-like type checking in an inheritance hierarchy via "type_name?" methods -
grpc_serializer
A simple library to encode nested hash to grpc object and vice versa -
simple_active_link_to
Simple rails view helper to manage "active" state of a link -
dry-rb
dry-rb is a collection of next-generation Ruby libraries, each intended to encapsulate a common task.
Static code analysis for 29 languages.
* Code Quality Rankings and insights are calculated and provided by Lumnify.
They vary from L1 to L5 with "L5" being the highest.
Do you think we are missing an alternative of skinny_controllers or a related project?
README
skinny_controllers
skinny_controllers is a thin layer on top of rails with the goal of allowing for much easier unit-testability, inspired by ember
A demo app can be found in the spec here.
An implementation of role-based policies and operations to help controllers lose weight.
The goal of this project is to help API apps be more slim, and separate logic as much as possible.
If you have an idea or suggestion for improved defaults, please submit an issue or pull request. :-)
Overview
- Controllers only contain render logic. Typically,
render json: model
- Business logic is encapsulated in operations.
- Without creating any new classes,
render json: model
will give you default CRUD functionality in your controller actions. - There is one operation per controller action.
- Without creating any new classes,
- Policies help determine whether or not the
current_user
is allowed to perform an action on an object. - Click here to see how this is different from trailblazer
Installation
gem 'skinny_controllers'
or
gem install skinny_controllers
Usage
In a controller:
include SkinnyControllers::Diet
# ...
# in your action
render json: model
and that's it!
What if you want to call your own operations?
Sometimes, magic is scary. You can call anything you want manually (operations and policies).
Here is an example that manually makes the call to the Host Operations and passes the subdomain parameter in to filter the Host
object on the subdomain.
def show
render json: host_from_subdomain, serializer: each_serializer
end
private
def host_from_subdomain
@host ||= HostOperations::Read.new(current_user, params, host_params).run
end
def host_params
params.permit(:subdomain)
end
The parameters for directly calling an operation are as follows:
# | Parameter | Default when directly calling an operation | Implicit default | Purpose |
---|---|---|---|---|
0 | current_user | n/a | current_user |
the user performing the action |
1 | controller_params | n/a | params |
the full params hash from the controller |
2 | params_for_action | controller_params |
create_params , index_params , etc |
e.g.: requiring a foreign key when looking up index |
3 | action | controller_params[:action] |
action_name |
the name of the current action |
4 | options | {} |
skinny_controllers_config options |
For JSON-API
Strong parameters must be used on create/update actions.
Here is an example params method
private
def event_params
params
.require(:data)
.require(:attributes)
.permit(:name)
end
Note that we don't need the id under the data hash, because in a RESTful api, the id will be available to us through the top level params hash.
How is this different from trailblazer?
This may not be horribly apparent, but here is a table overviewing some highlevel differences
Feature | - | skinny_controllers | trailblazer |
---|---|---|---|
Purpose | - | API - works very well with ActiveModel::Serializers | General - additional features for server-side rendered views |
Added Layers | - | Operations, Policies | Operations, Policies, Forms |
Validation | - | stay in models | moved to operations via contract block |
Additional objects | - | none | contacts, representers, callbacks, cells |
Rendering | - | done in the controller, and up to the dev to decide how that is done. ActiveModel::Serializers with JSON-API is highly recommended |
- |
App Structure | - | same as rails. app/operations and app/policies are added |
encourages a new structure 'concepts', where cells, view templates, assets, operations, etc are all under concepts/{model-name} |
Contributing
Please refer to each project's style guidelines and guidelines for submitting patches and additions. In general, we follow the "fork-and-pull" Git workflow.
- Fork the repo on GitHub
- Clone the project to your own machine
- Commit changes to your own branch
- Push your work back up to your fork
- Submit a Pull request so that we can review your changes