Architecture Over Framework: Rethink Your App Structure

Architecture Over Framework: Rethink Your App Structure

With the kind of maturity Rails has gained over the past few years, saying our business logic resides in app/ makes us look like we are from 2009. However, that is also a truth we are bound to, as Rails exhibits a very rigid app structure. Every app has models, views, concerns, mailers etc. However, they don't have to always be in app/views, they could be in src/authentication/templates for what it's worth.

In this talk, we'll take a typical Rails app and completely mess it up by restructuring the content. We'll fragment it in a way that is relevant to the application context. No more app/models and app/controllers and such. What we will get as a result, is a big screaming pile of fail!

But, this is a start of a new red-green-refactor cycle. We will try to make it work by changing one thing at a time, looking at one error at a time. And in the end we'll make it all work, or give up hopelessly, but with a far more understanding of the magic happening under the hood.

A9e271fb1622f8dbb6d652993f5a23a7?s=128

Swanand Pagnis

July 19, 2014
Tweet

Transcript

  1. Architecture Over Framework Rethink Your App Structure

  2. Tweet@_swanand GitHub@swanandp StackOverflow@18678 Build { Simplero } swanand@pagnis.in Ruby, Clojure,

    Lisp, Rails, Android, Emacs, TextMate, RubyMine, Minitest, MySQL, Zsh, Curl, Gmail, Hadoop, Mavericks, Solarized, Retina-MBP, Nexus 5 Oscar Wilde, Robert Jordan, J K Rowling, Quentin Tarantino, Chris Nolan, Leonardo DiCaprio, Charlize Theron, Metallica, Dream Theatre, Pink Floyd
  3. ! if magic_code puts "I am in IF block" else

    puts "In ELSE block I am" end ! => I am in IF block => In ELSE block I am how?
  4. ! if fork puts "I am in IF block" else

    puts "In ELSE block I am" end ! => I am in IF block => In ELSE block I am how?
  5. Looking Ahead Why do this ? Case Study: Discourse

  6. Looking Ahead Why do this ? Case Study: Discourse

  7. Why do this ? Clear Intent Better Understanding

  8. Why do this ? Clear Intent Better Understanding

  9. Architecture Elements of a system and their relationship with each

    other
  10. Architecture Designed such that intent is apparent and palpable

  11. Framework An abstraction you build upon, to provide app specific

    software
  12. This picture screams RAILS!

  13. –Robert Martin “This is good for DHH; but not So

    good for you.” http://www.confreaks.com/videos/759-rubymidwest2011-keynote-architecture-the-lost-years
  14. Why do this ? Clear Intent Better Understanding

  15. Debugging bad code: Frustration

  16. Debugging good code: Enlightenment

  17. Debugging good code: Learning

  18. Looking Ahead Why do this? Case Study: Discourse

  19. None
  20. None
  21. That’s not a lot, but if you are new to

    the project, then …
  22. http://media0.giphy.com/media/KE9cblgPK6EPS/200_s.gif

  23. Before

  24. After

  25. None
  26. None
  27. File lookups are fixed by managing load path

  28. Const lookups are fixed by managing auto-load path

  29. None
  30. config/application.rb

  31. $ rails console

  32. $ rails console

  33. http://38.media.tumblr.com/tumblr_maeu8e5wuj1rxmai6o1_500.gif

  34. None
  35. First real limitation: namespace based look ups

  36. application_controller

  37. None
  38. Second limitation: unfriendly helper customisation

  39. Second limitation: unfriendly <foo> customisation

  40. action_controller/helpers

  41. rails/railtie

  42. config/helper_railtie

  43. None
  44. Looking Back File structure (Load Path) Const lookups (Auto Loads)

    View Paths (Namespacing) Helper Paths (Railties)
  45. Rearrange tests Rearrange assets Custom Rake tasks Possibilities

  46. Muddle with Metal Build your Rackware Examine pre-forking Possibilities

  47. Thank you!

  48. Questions?