Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Rails Contained: A Container for Web Application Development and Deployment

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.

Comments
  1. Steve C says:

    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.

  2. Mike Barinek says:

    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

  3. 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

  4. 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

  5. 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

  6. Sumonaven says:

    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…

  7. 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.

  8. 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.

  9. Raja Sekar says:

    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

  10. 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

  11. Hi this application fully based on the web deployment information and it will create a new way of concepts regards this.

  12. Casey Provost says:

    How do you deploy each component separately and test in isolation?

  13. Stephan Hagemann says:

    Hi Casey,

    Testing in isolation is achieved by adding the appropriate tests for a component directly into its gem/engine. For an example, check out the “teaser” engine in my sample project “the next big thing”: https://github.com/shageman/the_next_big_thing/tree/master/engines/teaser. Teaser has a bunch of tests that only apply to this component. Tests run in isolation when the test script in this directory is run.

    Since all components are contained within they same app they can not really be deployed separately, but a proxy can be used to achieve quasi separation for production needs. Imagine an application with two engines A and B that are mounted at /a and /b respectively. Now, this app gets deployed to two boxes X and Z. A load balancer can then be used to forward all requests to /a to X and all requests to /b to Z, effectively separating the two apps.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *