$30 off During Our Annual Pro Sale. View Details »

Separating Your Application from Rails - Brian Hughes

Las Vegas Ruby Group
December 10, 2014
69

Separating Your Application from Rails - Brian Hughes

Las Vegas Ruby Group

December 10, 2014
Tweet

Transcript

  1. originate.com @brianvhughes
    Brian V. Hughes
    No Hexagons Required
    Separating Your
    Application from Rails

    View Slide

  2. originate.com @brianvhughes
    Brian V. Hughes
    Why separate?

    View Slide

  3. originate.com @brianvhughes
    Brian V. Hughes
    Why separate?
    Rails MVC encourages tight coupling

    Tight coupling inhibits long-term maintenance

    Tight coupling inhibits efficient TDD

    “Standard” Rails Controllers obliterate SRP

    View Slide

  4. originate.com @brianvhughes
    Brian V. Hughes
    “Standard” Controller
    Responsibilities
    Receive HTTP request

    Authentication

    Authorization

    Parameter handling

    Coordinate models/
    associations

    Control Persistence

    Perform business
    logic

    Call external APIs

    Render response data

    Return HTTP
    response

    View Slide

  5. originate.com @brianvhughes
    Brian V. Hughes
    “Standard” Controller
    Responsibilities
    Receive HTTP request

    Authentication

    Authorization

    Parameter handling

    Coordinate models/
    associations

    Control Persistence

    Perform business
    logic

    Call external APIs

    Render response data

    Return HTTP
    response

    View Slide

  6. originate.com @brianvhughes
    Brian V. Hughes
    “Reduced” Controller
    Responsibilities
    Receive HTTP request

    Authentication

    Tell Application to perform work

    Render response data

    Return HTTP response

    View Slide

  7. originate.com @brianvhughes
    Brian V. Hughes
    What does a “separated”
    application look like?

    View Slide

  8. originate.com @brianvhughes
    Brian V. Hughes
    Entities and Interactors

    View Slide

  9. originate.com @brianvhughes
    Brian V. Hughes
    Entities and Interactors
    Architecture, the Lost Years, Bob Martin, Ruby Midwest ‘11

    https:/
    /www.youtube.com/watch?v=WpkDN78P884

    View Slide

  10. originate.com @brianvhughes
    Brian V. Hughes
    Functional Core,
    Imperative Shell

    View Slide

  11. originate.com @brianvhughes
    Brian V. Hughes
    Functional Core, Imperative Shell
    Boundaries, Gary Bernhardt, RubyConf ‘12

    https:/
    /www.youtube.com/watch?v=yTkzNHF6rMs

    View Slide

  12. originate.com @brianvhughes
    Brian V. Hughes
    Hexagonal Architecture

    View Slide

  13. originate.com @brianvhughes
    Brian V. Hughes
    Hexagonal Architecture
    Presented by Matt Wynn at GORUCO ’12

    https:/
    /www.youtube.com/watch?v=CGN4RFkhH2M

    View Slide

  14. originate.com @brianvhughes
    Brian V. Hughes
    Response State

    View Slide

  15. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    Presented by Brian V. Hughes, LVRUG 12/10/14
    C
    V M

    View Slide

  16. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    C
    V M

    View Slide

  17. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    C
    V M

    View Slide

  18. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    C
    V M

    View Slide

  19. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    A new interface in controller actions, aka.
    Response State Pattern

    Response State service classes, that provide
    the new controller interface

    Response Object instances, passed from the
    service class, to the controller. Drives the
    pattern.

    View Slide

  20. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    Replace the body of a controller action with
    a call to a Response State service class.

    The class “responds”, via yield, with an
    object representing the new app state

    Action doesn’t inspect response object, but
    sends directed calls, to named states.

    Only 1 state can be active; that’s the path
    the controller action follows.
    The so-called “Design Pattern”

    View Slide

  21. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    Response State service class exposes only
    a :call method, as its public API.

    Ideally, that :call method returns nil, in the
    process of yielding a Response Object

    Service class responsible for defining the
    allowed states of the Response Object.

    Handles all high-level application logic,
    delegates to services and models.
    The Service Class

    View Slide

  22. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    Response Object always instantiated with 3
    parameters: :state, :message, :context.

    The value of :state determines which
    methods Response Object responds to.

    When called with the current :state method
    value, it yields, otherwise returns nil.

    :message and :context can both be nil.
    The Response Object

    View Slide

  23. originate.com @brianvhughes
    Brian V. Hughes
    Response State
    Presented by Brian V. Hughes, Originate ‘14

    Ruby Gem developed by Alex Peachey

    https:/
    /github.com/Originate/response_state

    View Slide