You might call this post Part 2 in a component based architecture series. The first post describes a solution for better organizing loosely-coupled, highly-cohesive components within a singe Rails application.
This post describes a component based solution that aims to support vastly different user experiences and client side strategies across multiple web applications that share a common domain while allowing developers to work independently within individual web applications or components.
Here’s the scenario…
You’re tasked with building a fairly large web application, several user roles each packed with handfuls of high-level activities. The larger application could clearly be broken apart into smaller web applications. It’s a clear win to break things down. The smaller applications would have unique responsibilities and developers could work within the context of one application without worrying about introducing breaking changes across applications. However, the smaller applications, although independent, share a common domain or database.
You start thinking about how you’d expose subsets of the domain as RESTful services and maybe introduce a single sign-on approach, although you’re concerned about managing, versioning, and deploying multiple web applications and services, not to mention how this might impact the early development rhythm. There’s no clear path to success, so you write the classic uber app.
The tide could be changing in your direction. Here’s a solution that’s shown early success for developing and deploying large Rails applications: move loosely-coupled, highly-cohesive web applications and components to a components directory within a container Rails project.
Until recently such an approach might be difficult to imagine. Although, with the addition of mountable engines in the latest versions of Rails, the approach is now possible. Here’s an example that describes the project structure…
container_rails_app/
app
config
components/
component_1/
lib/component_1.rb
lib/component_1
test/lib
test/test_helper.rb
Gemfile
component_1.gemspec
Rakefile
component_2/
component_3/
web_app_1/
app
config
test/lib
test/test_helper.rb
Gemfile
Rakefile
web_app_2/
app
config
...
...
The container application simply mounts dependent web applications as Engines, exposing each with their own context or url. Engines in turn reference in any Engines or Gems they depend on.
However, there is one twist, we keep everything in a single Git repository.
Engines are organized as prescribed within their corresponding directories, although they’re not built nor do they have their own Git repository. They’re referenced directly from the containers Gemfile.
As database migrations trigger sweeping changes, the refactorings become simpler and you don’t need to worry about deploying updates to multiple applications/services as all your code is in one place, versioned together.
As important, each Engine or Gem has it’s own Gemfile, test_helper, test suite, and continuous integration environment. As mentioned in the first post, the unique Gemfile and test helper allows you to remove unnecessary dependencies while the individual test suite and continuous integration environment helps to avoid circular dependencies.
Interesting thoughts on how to attempt to split a big Rails app.
“However, the smaller applications, although independent, share a common domain or database.”
The production issues created by having multiple applications with presumably different workloads and SLAs might present a problem – one you might ultimately care much more about than the large codebase.
Also, I haven’t found reuse of domain models and logic across applications to be a big win (if I’m understanding correctly what’s being proposed) – in fact this sort of object reuse leads to objects that do the superset of what all applications want, which gets weird and cumbersome from the POV of any given app.
I wonder whether a more cross-cutting approach to reuse that concentrates on simply extracting and reusing (non-Rails-infected) gems might not be better, with a separation of datastores per app, and with data transferred at the application level via an api (for instance using simple http/json-based feeds). Applications are reduced as much as possible to the domain logic “glue” code – i.e. there’s no attempt to reuse at the domain level, but given good partitioning, each app is responsible for one distinct part of the overall service, so this doesn’t turn out to be a big deal, either.
February 22, 2012 at 2:21 pm
Hi Steve, it’s been a while…
Individual web applications could be isolated via apache/nginx, all apps are deployed although not necessarily accessed. We’ve also thought about being creative when engines are mounted although nothing has solidified.
I think the term service has been a bit overloaded, traditionally service layers were simply components with implicit or explicit contracts depending your language of choice. And agreed, you might not leak active record models, or your persistence implementation, outside of your component. You might start by exposing plain objects which could also be severed up as json if the need arrives.
I’m simply introducing a step before moving to individual Git repositories and http services for large systems.
I would be curious on your comments regarding this post as well http://pivotallabs.com/users/mbarinek/blog/articles/2022
February 23, 2012 at 8:00 am
thanks very good blog.i likes it.Rich Internet Application Development
March 6, 2012 at 3:37 am
Hello there I am so delighted I found your blog page, I really found you by mistake, while I was researching for something else,
Regardless I am here now and would just like to say many thanks for a remarkable post and a all round enjoyable blog.Please do keep up the excellent work.
industrial training indore
March 19, 2012 at 5:21 am
Magnificent items from you, man.I have read your blog and i got a very useful and knowledgeable information from your blog.its really a very nice article.
I really like what you’ve acquired here, certainly like what you’re saying and the way in which by which you assert it. You’re
making it entertaining and you continue to care for to stay it sensible.
web application development
March 23, 2012 at 12:49 am
Outstanding article, all of this is quite similar to a site that I publish. Please check it out sometime and feel free to leave me a comment on it and tell me what you think. I’m always looking for feedback.
website applications Boston
April 1, 2012 at 1:31 am
We are Brockton, MA web site Development company. We build web sites for Brockton, MA. We are Boston, MA web site Development company. We build web sites for Boston, MA. We are South Shore, MA web site Development company. We build web sites for South Shore, MA. We are North Shore, MA web site Devel…
April 6, 2012 at 9:59 pm
Hello there I am so delighted I found your blog page, I really found you by mistake, while I was researching for something else,
Regardless I am here now and would just like to say many thanks for a remarkable post and a all round enjoyable blog.Please do keep up the excellent work.
April 11, 2012 at 4:30 am
Magnificent items from you, man.I have read your blog and i got a very useful and knowledgeable information from your blog.its really a very nice article.
I really like what you’ve acquired here, certainly like what you’re saying and the way in which by which you assert it. You’re
making it entertaining and you continue to care for to stay it sensible.
April 23, 2012 at 3:21 am
web application fully based on how to implement new technique concept to around world and it is exposes the high integrity resolutions further details you can visit this http://www.baalin.in
April 23, 2012 at 4:07 am
Hello there I am so delighted I found your blog page, I really found you by mistake, while I was researching for something else,
Regardless I am here now and would just like to say many thanks for a remarkable post and a all round enjoyable blog.Please do keep up the excellent work.
industrial training indore
May 8, 2012 at 12:47 am
Hi this application fully based on the web deployment information and it will create a new way of concepts regards this.
May 14, 2012 at 1:01 am