The document discusses the transition from a monolithic web application to an ecosystem of 30 interconnected applications, emphasizing benefits such as independent development cycles and improved scalability. It details the implementation of common interfaces, data sharing methodologies, and access control, all while maintaining a consistent user interface across applications. The approach aims to enhance developer autonomy and operational efficiency while ensuring each application can function independently.

1. From 1 To 30How To DisassembleOne Monster App Into An Ecosystem Of 30Jonathan Palley, CTO/COOGuo Lei, Chief Architect© 2010 Idapted, Ltd.

2. AnExperience

3. A Tale of Two Buildings

4. ShanghaiLotus Riverside Community1909 BeijingForbidden City

5. 130

6. What is one?

7. The entire web application/system/platform runs as one single rails application(We are talking about really large systems. Multiple different types of clients/functions)

8. ProblemsConfused new staffHard to test/extend/scale

9. What is 30?

10. A ecosystem of applications

11. Independent

12. Linked and Seamless

13. Basic features of each appSeparate databaseRuns independently (complete story) Lightweight (single developer)Tight internal cohesion and loose external couplingAdvantagesIndependent Development Cycle

14. Developer autonomy

15. Technology (im)maturity safetyAPPEAL TO DEVELOPER LAZINESS

16. What’s the mystery of the forbidden city?

17. Consistent UIShared CSS/JS/StyleguideCommon Helpers in Shared GemSafely try new things

18. interfaceAll applications use the same base CSS/JSKeep all the application the same style<%=idp_include_js_css%># =><script src ="/assets/javascripts/frame.js" type="text/javascript"></script><link href="/assets/stylesheets/frame.css" media="screen" rel="stylesheet" type="text/css" />

19. interfaceCSS Framework

20. interfaceAbstract Common Helpers to GemSearch function for models

21. interfaceCommon Helpers: Combo search (cont)View:<%= search_form_for(HistoryRecord, :interaction_id, :released,[:rating, {:collection=>assess_ratings}],[:mark_spot_num,{:range=>true}], [:created_at, {:ampm=>true}]) %>Controller:@history_records= HistoryRecord.combo_search(params)

22. interfaceCommon Helpers: List tablewell formattedwith pagination sortablecustomizable

23. interfaceCommon Helpers: List table (cont)<%=idp_table_for(@history_records,:sortable=>true,:customize => "history_records") do |item, col|col.add:id, link_to(item.id, admin_history_record_path(item)),:order=>:idcol.build:duration, :waiting_time, :review_timecol.add:scenario, item.scenario_title, :order => :scenario_titlecol.add:mark_spot_num end%>

24. interfaceDevelopment LifecycleImplement new View code/plugin in a second applicationAbstract intoplugin using existing “idp” helpersPut it into main view gem

25. interfacedata

26. dataHow do applications share data? (remember: each app has its own data)“Read Only” Database Connections

27. Services

28. AJAX Loaded View SegmentsBusiness exampledatauserpurchasecourselearning process

29. Purchase AppdataRequirement: List course packages for user to select to purchasebutThe course package data is stored in the “course” application

30. Solutiondatareadonly db connectioncourse

31. CodedataModel:class CoursePackage< ActiveRecord::Baseacts_as_readonly:courseendView:<ul><%CoursePackage.all.eachdo |package| %><li><%= package.title %> <%= package.price %></li><%end %></ul>

32. dataWhy doesn’t this break the rule of loose coupling?

33. dataacts_as_readonly in Depthdef acts_as_readonly(name, options = {})config = CoreService.app(name).databaseestablish_connectionconfig[Rails.env]set_table_name(self.connection.current_database + (options[:table_name]||table_name).to_s)end

34. dataacts_as_readonly in Depthdef acts_as_readonly(name, options = {})config = CoreService.app(name).databaseestablish_connectionconfig[Rails.env]set_table_name(self.connection.current_database + (options[:table_name]||table_name).to_s)end

35. dataCore serviceclassCoreService < ActiveResource::Baseself.site = :userdefself.app(app_name)CoreService.find(app_name)endend

36. dataCentralized configurationHow does Core know all the configurations?

37. dataEach app posts its configuration to core when it is started

38. dataconfig/site_config.ymlapp: courseapi:course_list: package/coursesconfig/initializers/idp_initializer.rbCoreService.reset_config

39. datacore_service.rb in idp_libAPP_CONFIG = YAML.load(Rails.root.join(“config/site_config.yml”))defreset_configself.post(:reset_config, :app => { :name => APP_CONFIG["app"], :settings => APP_CONFIG, :database => YAML.load_file(Rails.root.join("config/database.yml"))})end

40. data

41. dataAgain, implemented in gemconfig/environment.rbconfig.gem ‘idp_helpers’config.gem ‘idp_lib’

42. datagems

43. dataWeb services for “write” interactionsclass CoursePackageService< ActiveSupport::Baseself.site = :courseend

44. exampledataRoadmap needs to be generated after learner pays.

45. codesdataCourse: app/controllers/roadmap_services_controller.rbdef createRoadmap.generate(params[:user_id], params[:course_id])endPurchase: app/models/roadmap_service.rbclass RoadmapService < ActiveSupport::Baseself.site = :courseendPurchase: app/models/order.rbdefactivate_roadmapRoadmapService.create(self.user_id, self.course_id)end

46. dataAJAX Loaded Composite View<div><%=ajax_load(url_of(:course, :course_list)) %></div>Ecosystem url_forFetched from different applications

47. interfacedatauser

48. Features of User ServiceuserRegistration/loginProfile managementRole Based Access Control

49. Access ControluserEach Controller is one Node* Posted to user service when app starts

50. Access Controluserbefore_filter:check_access_rightdefcheck_access_rightunlessxml_request?orinner_request?access_deniedunlesshas_page_right?(params[:controller])endend* Design your apps so access control can be by controller!

51. userHow to share?

52. Step 1: User Authuser

53. Step 1: User Authuserconfig/initializers/idp_initializer.rbActionController::Base.session_store = :active_record_storeActiveRecord::SessionStore::Session.acts_as_remote:user, :readonly=> false

54. Step 2: Access ControluserTell core its controllers structureCoreService. reset_rightsdefself.reset_rightsdata = load_controller_structureself.post(:reset_rights, :data =>data)end

55. Step 2: Access Controluserbefore_filter:check_access_rightdefcheck_access_rightunlessxml_request?orinner_request?access_deniedunlesshas_page_right?(params[:controller])endend

56. Step 2: Access Controluserhas_page_right?Readonly dbconn again

57. Step 2: Access Controluserclass IdpRoleRight < ActiveRecord::Baseacts_as_readonly:user, :table_name=> "role_rights"enddef has_page_right?(page)roles = current_user.rolesroles_of_page = IdpRoleRight.all(:conditions => ["path = ?", page]).map(&:role_id)(roles - (roles - roles_of_page)).size > 0end

58. userAgain, gems!config/environment.rbconfig.gem ‘idp_helpers’config.gem ‘idp_lib’config.gem ‘idp_core’

59. interfaceservicedatauser

60. serviceSupport applicationsFileMailComet service

61. Fileclass Article < ActiveRecord::Basehas_filesend Specify Class that Has FilesUpload File in Background to FileServiceIdp_file_formStore with app_name, model_name, model_idUse readonly magic to easily display@article.files.first.url

62. serviceCometclassChatRoom < ActiveRecord::Baseacts_as_realtimeend <%= realtime_for(@chat_room, current_user.login) %><%= realtime_data(dom_id, :add, :top) %>@chat_room.realtime_channel.broadcast(“hi world", current_user.login)

63. servicemailMail servicesMailService.send(“test@idapted.com”, :welcome, :user => “test”)

64. Host all in one domainLoad each rails app into a subdir, we use Unicorn unicorn_rails --path /user unicorn_rails --path /studycenter unicorn_rails --path /scenario

65. Host all in one domainuse Nginx as a reverse proxylocation /user { proxy_pass http://rails_app_user; } location /studycenter { proxy_pass http://rails_app_studycenter; }

66. Host all in one domainAll you see is a uniform URL www.eqenglish.com/user www.eqenglish.com/studycenter www.eqenglish.com/scenario

68. Pair-deploy

69. How to split one into many?

70. By Story Each App is one group of similar features.By Data Each App writes to the same data

71. ExampleUser ManagementCourse packagePurchaseLearning process…

72. Iteration

73. Be adventurous at the beginning.Split one into as many as you think is sensitive

74. Then you may findSome applications interact with each other frequently.Lots of messy and low efficiency code to deal with interacting.

75. Merge them into one.

76. MeasurementCritical and core task of single app should not call services of others.One doesn’t need to know much about others’ business to do one task (or develop).Independent Stories

77. PitfallsApplications need to be on the same intranet. No “right place” for certain cases.

78. Results: Higher ProductivityFaster build to deploy

79. More developer autonomy

80. Safer

81. Scalable

82. Easier to “jump in”

83. Greater HappinessThank you!Q&Ahttp://www.idapted.comhttp://developer.idapted.comhttp://t.sina.com.cn/eqenglishhstjpalley@idapted.com (@jpalley)guolei@idapted.com (@fiyuer)© 2010 Idapted, Ltd.