daily pastebin goal
75%
SHARE
TWEET

Untitled

a guest Sep 20th, 2013 130 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. SOA without the tears (A pragmatic alternative with embedded Rails engines) - Jon Wilkinson, Anthony Zacharakis - Lumosity
  2.  
  3. - Overview
  4.   - failed attempts and why
  5.   - what are embedded engines?
  6.   - when can I use embedded engines?
  7. - Lumosity have:
  8.   - 15 devs
  9.   - 45mm users
  10.   - Application since 2007
  11.   - 28k commits, 160 new commits/week
  12.   - a 'large' application
  13. - Large app problems
  14.   - slow
  15.     - loading gems and files
  16.     - build takes 1 hr 7 mins 13 secs (358 tests 2 pending) w/ 24 cores on ruby-1.9.3-p327 [from screen-shot]
  17.   - complicated
  18.     - end up with a lot of god models
  19.     - data flow complexity
  20.   - fragile
  21.     - adding new features breaks existing features
  22. - Solutions
  23.   - SOA (service oriented architecture)
  24.   - Basically breaking down your App into several Apps which communicate w/ well defined APIs and explicitly specified dependencies
  25.   - A /lot/ of work to break down an existing application into an SOA model
  26.     - new bugs (dealing with time-outs)
  27.     - dealing with lots of legacy (*cruft*)
  28.     - dev friction
  29.     - difficult to test
  30.     - difficult to secure
  31.   - A compromise
  32.     - broke code out into modules
  33.     - trouble
  34.       - discourage code independence
  35.     - engines!
  36. - Engines
  37.   - miniature applications which provide functionality to the host applications
  38.   - engines are isolated and unable to reach into host state
  39.   - engine construction is easy ``` rails plugin new <name> --mountable ```
  40.   - a trick
  41.     - to embed engines in your repo:
  42.       - use #local_engine in the GemSpec ``` def local_engine(name); gem name, path: "engines/#{name}"; end ```
  43.   - when extracting Tables, prefix tables with the engine name (to prevent conflicts)
  44.   - associations, don't use associations because they encourage tight coupling
  45.   - paths, ( /login -> /<engine>/login ) they're mounted in a namespace
  46.   - seems complicated
  47.     - engine specific config
  48.       - such as: configuration options, route helpers, feature flags, AB tests, external model data, callbacks, hooks
  49.       - make an initialiser and adjust it to do your engine specific config
  50. ```
  51. # in config/initializers/user_auth.rb
  52. class UserAuth::LoginsController
  53.   def show
  54.     @allow_facebook = Feature.enabled?(:facebook)
  55.   end
  56. end
  57. ```
  58.       - refactor engine to depend on config
  59.     - dependencies
  60.       - cross-engine and host dependency is evil, do not depend on the host app or other engines -- you will regret it
  61.       - example:
  62. ```
  63. Dearest <%= first_name_or_whatever %>,
  64.  We're <%-= deeply_touching_sentiment %> that you joined and thought you should check this out:
  65.  
  66.  <%= image_tag(purchase_driving_gaph_path %>
  67. Warm regards,
  68. Lumosity
  69. ```
  70.       - If you want to CDN that image, you add:
  71. ```
  72. UserAuth.cdnize = ->(path) do # lambda notation
  73.   UrlMethods.cdnize(path)
  74. end
  75. ```
  76.       - in the engine:
  77. ```
  78. cdnized_url = UserAuth.cdnize(<url>)
  79. ```
  80.       - avoid main app knowledge of engine internals
  81.         - isolate data by putting all main app accesses into a module which explicitly conveys the API
  82.     - testing
  83.       - use a dummy application.. you don't need to load all your dependencies of your main app
  84.       - dummy apps expose hidden dependencies (ex. translation error, the engine was expecting translations which only lived in the main app)
  85.       - faster feedback loops
  86.         - faster tests better tests
  87.       - do not forget about your integration tests (you'll need them since you've got inter-engine dependencies in terms of data flow)
  88.   - When should I use engines
  89.     - old applications with lots of functions? yes.
  90.     - large teams? yes. more independence.
  91.   - Lumosity have over a dozen engines in production today inside their app
  92.   - benefits
  93.     - lightening fast specs
  94.     - peace of mind
  95.     - self describing
  96. - Thanks
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top