Rails Engine Patterns

1. Problem Difficulty reusing functionality cutting across: Models Views Controllers Assets (JS, CSS, Images) Duplication across all web application layers.

3. Solution Break common behavior into Rails Engines Customize models/controllers/helpers in each project where needed by reopening classes Customize Rails views in each project as needed by overriding templates Link to Rails Engines in Gemfile via Git repo

4. Example Common Domain Rails Engine Search Map Rails Engine High School Public Athlete Recruiting Profiles Recruiting Rails App Rails App Rails App

7. What is a Rails Engine? Ruby Gem + MVC stack elements

8. What is a Rails Engine? Rails Engines let applications reuse: Models / Views / Controllers / Helpers Assets (JS, CSS, Images) Routes Rake tasks Generators

9. What is a Rails Engine? Rails Engines let applications reuse: Initializers RSpec / Cucumber Rack application with middleware stack Migrations and seed data Libraries

10. Engine Definition An engine structure is similar to a Rails app having app, config, lib, spec, features, etc… lib/engine_name.rb (read online instructions) lib/engine_name/engine.rb (read online instructions) To reuse engine, use “jeweler” gem to generate gemspec (read online instructions)

11. lib/engine_name.rb

12. lib/engine_name/engine.rb

14. Load Order Typically Rails app files load first before Engine files. Strongly recommended to reverse so that engine’s code is customizable in app

15. Load Order Reversing load order can happen in one of two ways: Patching “active_support/dependencies.rb” in Rails 3.1- (see next slide) Adjusting railties_order in Rails 3.2+

16. Ruby Code Customization Model/Helper/Controller behavior can be customized be redefining .rb files in Rails App Customizations get mixed in with files in Engine This allows: Adding new methods/behavior Replacing existing methods Extending existing methods (alias_method_chain)

17. Ruby CodeCustomization Example

18. Ruby CodeCustomization Example

19. View and AssetCustomization Engine View and Asset presentation can be customized by redefining files in Rails App Customizations completely override files in Engine Examples of customizable View and Asset files: ERB/Haml JS CSS Images

20. ViewCustomization Example

21. ViewCustomization Example

22. Recommended EngineCode Management• Each Engine lives in own Repo independent of Rails App• Each Engine has its own Gem dependencies (Gemfile)• Engines preferably share the same Ruby version as Rails App

23. Typical DevelopmentProcess1. Make changes in engine, rake, and commit obtaining a new GIT ref2. Update Gemfile in app with new git ref, run “bundle install” (getting ride of symlink)3. Rake and commit changes in app.4. If more changes in engine are needed go back to step 1

24. Improved Productivity viaSymlinking Multiple engine dependencies can hamper productivity when frequently going back and forth between engines and app Engine gems installed via bundler can be symlinked to allow continuous development until done with both app and engine:http://andymaleh.blogspot.com/2011/09/ more-productive-rails-engine.html

25. Improved DevelopmentProcess1. Open Rails app and symlink all engines “rake engine:symlink[engine_name]”2. Work in app and engine until done WITHOUT running “bundle install”3. Rake and commit changes in engine obtaining a new git ref4. Update Gemfile in app with git ref, run “bundle install” (getting ride of symlink)5. Rake and commit changes in app

26. Engines Reuse Engines Rails engines can reuse other Rails engines Common Domain Rails Engine Search Map Rails Engine High School Public Athlete Recruiting Profiles Recruiting Rails App Rails App Rails App

27. Engines Reuse Engines When multiple levels of depth are involved, commit repos and update Gemfile from the bottom up Example: Engine 2 => Engine 1 => App 1. Commit in Engine 2 2. Update Gemfile in Engine 1 and commit 3. Update Gemfile in App and commit

28. Engine Configuration Engines can be configured to customize rack middleware, load paths, generators, and Rails component paths. More details at: http://edgeapi.rubyonrails.org/classes/Rails/Engi ne.html

29. Isolated Engines To avoid Ruby namespace clash with Models/Helpers/Controllers, you can define an isolated namespaced engine. For more details, go to http://edgeapi.rubyonrails.org/classes/Rails/Engi ne.html

30. Rails Engine Patterns Goals: Keep engine code agnostic of app customizations Prevent bi-directional coupling to simplify reasoning about code Avoid app dependent conditionals to improve code maintainability

31. Pattern - Common Domain Problem: Multiple Rails Apps need to share a basic domain model including default CRUD and presentation behavior Example: need to reuse address model and form entry behavior

32. Pattern - Common Domain Solution: In engine, include basic domain models (base behavior, common associations) with their views, CRUD controllers, and routes. In each app, define domain model specialized behavior, extra associations, and custom views Make sure routes are declared with Rails.application.routes.draw (not Rails App name)

33. Pattern - Common Domain Example: address.rb, addresses_controller.rb, address route, and _address.html.erb

34. Pattern - Expose Helper Problem: need to customize presentation logic for a view in one app only, but keep the same logic in others Example: One App needs to hide address1 and county for non- government users. Other Apps wants to keep the fields displayed. You might start by overriding view, but then realize it is duplicating many elements just to hide a couple fields.

35. Pattern - Expose Helper Solution: In Engine, extract helper logic that needs customization into its own helper. In App, redefine that new helper with customizations.

36. Pattern - Expose Helper(view in Engine)

37. Pattern - Expose Helper(trying to customize view in App)

38. Pattern - Expose Helper Remove custom view from App Use requires_extended_address? helper in Engine wherever the App used government_user? In Engine, define requires_extended_address? to return true In App, define requires_extended_address? to return government_user?

39. Pattern - Expose Helper(view + helper in Engine)

40. Pattern - Expose Partial Problem: need to have different customizations in one part of the view in multiple apps Example: Address form One App needs an extra neighborhood field Another App needs an extra region field

41. Pattern - Expose Partial Example App 1:

42. Pattern - Expose Partial Example App 2:

43. Pattern - Expose Partial Solution: In Engine, extract view part that needs customization as a partial. In App, redefine that partial with customizations.

44. Pattern - Expose Partial Example: Define _address_extra_fields partial with empty content in Engine Redefine _address_extra_fields in Apps needing extra fields

45. Pattern - Extension Point Problem: multiple Apps need to contribute data to a View in different places Example: multiple Apps need to add custom Rows in different spots of a List that comes from an Engine

46. Pattern - Extension Point Engine defines only 3 elements in a list (About Me, News and Noteworthy) 1 2 3

47. Pattern - Extension Point Solution: In Engine, add Helper logic that looks up partials in a specific ext directory, and based on file name (e.g. row_7.html.erb) insert into the right location in the View. In App, define these partials with the right file names and locations.

48. Pattern - Extension Point App 1 adds “nav_bar_list_ext/_row_1.html.erb” 1 2 3 4

49. Pattern - Extension Point App 2 adds “nav_bar_list_ext/_row_4.html.erb” 1 2 3 4

50. Pattern - ConfigurableFeatures Problem: different apps need different features from an engine in different combinations

51. Pattern - ConfigurableFeatures Solution: In Engine, add logic that looks up configuration options In App, configure Engine by overriding configuration options

52. Pattern - ConfigurableFeatures Example: Engine defines engine_config.yml enable_address_extensions: true enable_address_headers: true App overrides some options in engine_config.yml Engine uses config options to customize behavior using conditionals

53. Rails Engine Costs Overhead in establishing a new Rails Engine gem project Continuous switching between projects and engines to get work done Upgrade of ref numbers in Gemfile on every commit (minimized with symlinking)

54. Rails Engine Benefits Code reuse across all application layers Better maintainability due to: Independent project codebases Cleanly defined boundaries between projects and reusable components (engines) Project tests get smaller and run faster

55. Engines vs Services Engines are better when: Reusing small MVC features, especially domain independent (e.g. Search Map) Preferring to avoiding network and infrastructure overhead over establishing a service Wanting to quickly extract and reuse a feature

56. Engines vs Services Web Services are better when: Reusing larger MVC features that depend on domain data Need to consume feature in another programming language or outside the organization boundaries Need to scale up feature performance independently of the application (e.g. separate DB)

57. Engines vs Services To keep an easier to maintain Agile code base, start simple and then move incrementally towards a more complex architecture: Extract an MVC feature as an engine first Convert engine into a service when the need arises

58. Questions & Answers ???

59. Review Basics of Rails Engines Rails Engine Patterns Improved Productivity Tips Summary of Benefits and Trade-Offs

60. More Info http://edgeapi.rubyonrails.org/classes/Rails/Engi ne.html http://andymaleh.blogspot.com/2011/09/more- productive-rails-engine.html http://stackoverflow.com/questions/2964050/rail s-engines-extending- functionality/2990539#2990539

61. Contact Andy Maleh / Software Engineer / Groupon Email: amaleh {at} groupon {dot} com Code Painter Blog: http://andymaleh.blogspot.com Twitter: @AndyMaleh