Separating Your Application from Rails - Brian Hughes

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