Switch branches/tags
Nothing to show
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
..
Failed to load latest commit information.
README
fake_raptor.rb
posts.rb
posts_spec.rb
records.rb
routes.rb
users.rb

README

This is a thought experiment for how Raptor apps might be designed. The module
hierarchy is:

Routes
Injectables
  .current_user
  .post_params
Interactors
  CreatePost
    PostSaved
    ValidationFailure
Models
  User
  AnonymousUser
  Post
Records
  User
  Post

Responsibility breakdown:
  - Routes are the same Raptor routes as ever. They can route out to different
    actions/redirects based on the interactor's response.
  - Injectables provide objects for Raptor's implicit DI. For example, the
    `post_params` injectable does what it sounds like, so that
    Interactors::CreatePost can take a `post_params` argument without worrying
    about where it came from. These are class methods directly on the
    Injectables module.
  - Interactors contain the application's logic. They return (or raise)
    response models that are usually defined directly in the interactor's class
    (or maybe from a shared location if appropriate).
  - Models wrap database records to provide simple mutations and data wrappers.
    For example, Post#publish updates the published flag and saves.  These
    don't necessarily map to records one-to-one. For example, the AnonymousUser
    model exists to avoid a nil current_user, and doesn't map to anything in
    the database.
  - Records are straight-up database records. No methods; just field
    definitions.

This hierarchy doesn't correspond to the file layout. Instead, files are
grouped by topic. For example, posts.rb contains Interactors::CreatePost, the
post_params injectable, and the Post model. Modules in the system will be
reopened many times as code is loaded, giving us lasagna files instead of
ravioli files.