An Epimetrics Epicenter web site consists of a “stack” of technologies that include the following components:

Virtually all current database-backed web sites use a similar stack, the main variations being in the specific components. For instance, many sites are based on “LAMP” — Linux, Apache, MySQL, and PHP. We have a strong bias in favor of Postgresql over MySQL but Apache (with an add-on technology called Passenger) is an alternative we may consider to nginx.

However, Ruby on Rails is vastly superior to PHP for many reasons in our view, so we are a committed Rails shop. One of the most useful features of Rails is its emphasis on built-in tests. Writing code in the “test-driven development” style that Rails not only encourages but makes hard not to do is that as complex applications evolve, one can remain confident that new changes don’t introduce problems to existing code.

Anyway, if you’re still reading this, the technical issues probably don’t really concern you. If you know the technical issues, you’ve probably not bothered to read this far. So we’ll conclude this explanation with a brief description about how all this works:

  1. When someone requests a page from one of our sites, the request goes to the site’s nginx web server.
  2. nginx sends the request to the Rails application — which is where all the Ruby code goodness of the Epicenter applications exists.
  3. Our Ruby on Rails application processes the request, doing many things including checking to see who made the request, what they’re able to do at the site, and what precisely they are trying to do now — which involves queries to the Postgresql database.
  4. Our Ruby on Rails application then assembles the page based on all this processing and returns it to nginx.
  5. nginx then sends the resulting page back to the browser.

The important take-away is to realize that a site that generates pages dynamically from database information can do sophisticated things tailored to the context of a specific user’s needs. That’s the way all Epimetrics Epicenter systems work.

Code Repository

All of the other parts of the “stack” are written and maintained by their respective developers — and all are open source projects that have been written collaboratively by programmers around the world. Rails itself is also an open source toolkit that has been used in tens of thousands of web site applications. It has become so popular that innumerable add-on projects are in active development. There is a remarkably vigorous ecosystem around Rails.

Many of these Rails projects have been released to open source and are hosted at Github — a collaborative code repository based on the most popular version control system, Git.

At this point, we still use the previously most popular version control system Subversion. However, we are nearly at the point of moving toward converting to Git, at which point we will move all client source code to Github, which provides among other things robust offsite backup of the source code. For those clients who choose it, we will set up a unique Git account for the client to house the client’s customized code apart from all other code we’re managing — which will allow clients to access their code directly if they choose.

We have not open sourced our Epimetrics Epicenter application code because some of our primary client code depends on proprietary algorithms belonging to the clients. However, we have a near-term plan to release components of our platform to open source on Github, where they too can receive the useful review and additions from others in the Rails community.


The Linux server computer on which all this runs obviously has to be connected to the Internet, and there are various options:

  • servers on our own internal network
  • dedicated servers on a client’s network
  • Virtual Private Servers (VPSs) at a managed hosting vendor
  • dedicated servers at a managed hosting vendor
  • “the cloud” — such as Amazon Web Services or Engine Yard

We do our own development/testing on our own servers of course, and run some very small-scale clients there. We have not yet encountered a client who wanted to run the box themselves on their own network, but we are open to this even if we think it isn’t a great idea. None of our clients to date have bandwidth needs that would require dedicated servers, and we haven’t yet stepped into the fast-changing new world of the cloud.

Instead, to date our clients have been very well served by VPS solutions from Slicehost. This has been a good match because our client sites function more like “intranets” used by well-defined groups of users — as opposed to popular media web sites. Our sites process high-complexity/low-bandwidth — not low-complexity/high-bandwidth —operations. However, at whatever point client needs grow so that the Rails application needs to scale, we can readily move the site to a higher performance host setting.

Created: October 09, 2009 22:51
Last updated: December 10, 2009 22:16


No comments yet.

To comment, you must log in first.