170 likes | 1.04k Views
Intellectual Scalability - Solving a Large Problem With Multiple Cooperating Rails Apps
E N D
Intellectual ScalabilitySolving a Large Problem with Multiple Cooperating Rails Apps Frederick Cheung, Chief Wizard, Texperts Paul Butcher, CTO, Texperts
Our Problem +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC | Classes | Methods | M/C | LOC/M | +----------------------+-------+-------+---------+---------+-----+-------+ | Controllers | 7435 | 6169 | 116 | 687 | 5 | 6 | | Helpers | 1726 | 1504 | 0 | 167 | 0 | 7 | | Models | 18030 | 14598 | 359 | 1428 | 3 | 8 | | Libraries | 4357 | 2934 | 38 | 227 | 5 | 10 | | APIs | 91 | 74 | 11 | 0 | 0 | 0 | | Components | 0 | 0 | 0 | 0 | 0 | 0 | | Functional tests | 12808 | 10286 | 178 | 1177 | 6 | 6 | | Unit tests | 24099 | 18762 | 237 | 1514 | 6 | 10 | +----------------------+-------+-------+---------+---------+-----+-------+ | Total | 68546 | 54327 | 939 | 5200 | 5 | 8 | +----------------------+-------+-------+---------+---------+-----+-------+ Code LOC: 25279 Test LOC: 29048 Code to Test Ratio: 1:1.1
The Solution • Multiple Apps! • … but … • How do they talk to each other? • How do they share code? • How do we roll them out? • How do we test them? • … and most importantly … • How do we make it all appear seamless?
Headlines • Apps developed and rolled out in “lock-step” • Simple directory structure • All apps under a single root directory • Code sharing through shared plugins* • Hacked version of Capistrano • All applications rolled out simultaneously • Cross-application testing with Selenium • * http://www.texperts.com/2007/06/21/on-sharing-code-between-rails-apps/
Inter-App Communication • Each app has its own database • No communication via the database • Apps could run on separate machines • Hybrid server- and client-side communication • Server-side communication via RESTful APIs • Client-side communication via UI framework
UI Framework • Integrated UI • Multiple URLs • Multiple logins • Multiple windows • Appears to be a single app • Problems • Efficient client-side communication • Single Origin Policy
Architecture foo.example.com app.example.com/foo bar.example.com app.example.com/bar app.example.com/baz Load Balancer/ Rewriter baz.example.com
Apache Rewrite Rules <VirtualHost *:80> ServerName app.example.com ... RewriteEngine On RewriteRule ^/foo/(.*)$ http://foo.example.com/$1 [P,QSA,L] RewriteRule ^/bar/(.*)$ http://bar.example.com/$1 [P,QSA,L] RewriteRule ^/baz/(.*)$ http://baz.example.com/$1 [P,QSA,L] </VirtualHost>
UI Framework • Single “portal” application • Applications implement “widgets” • Widgets loaded via AJAX Portal App1 App3 App1 App2 App2
Status • In production since June 2008 • 5 applications integrated (and counting) • Texperts report: • Better UI responsiveness • Higher productivity • Doesn’t work well on high-latency connections
Why IFRAMEs Don’t Work • Each IFRAME is its own independent HTML document • Difficult to resize • Difficult to communicate between • Difficult to style consistently • Makes Darren (our web-standards guy) cry