Thoughts on a domain based white label app?

Greets!

I was wondering if there might be any pitfalls I should be aware of in order to create a domain based white label app.

By that I mean, a single app that will change the layout/css/routes of an app depending on the domain name that accesses it

example.com gets example.css, layouts/example-application.html.erb, and whatever /slug-names the user defines for URL friendly CMS pages

foobar.com would get foobar.css, layouts/foobar-application.html.erb, and it's /slug-names

My reasoning for wanting to do this:

1) The app functionality is the same for all clients, say they are all book stores. Everyone has a book search of local inventory, a CMS to edit content and create /seo-friendly-slugs, and a shopping cart

1b) I have 8 people now on individual apps, but if this grows I don't want to fix bugs across x00 apps

2) None of the clients get a ton of traffic, however I have to run at least 1 instance of each app all the time so no one has to deal with a first load rails boot. It would be nice if I could have x instances of 1 app running serving requests for all the domains. This would let me fill up my VPS and handle spikes from any source while not having to worry about keeping the seat warm for low traffic domains

I realize this means I will have to have a bunch of if/case/lookup statements sprinkled about the app to handle all of the switching of layouts/views/css/(potentially js). I'll also need some lookup for the "dynamic routes" to check if /about/foobar exists for example.com, if so show the content otherwise display a 404.

Would Redis make sense for this kind of stuff, or should I create some yml configs to hold all of this?

I am not a seasoned veteran, only have 2 years of experience with Rails, am I nuts, biting off more than I can chew, or sounds reasonable enough to proceed?

Thanks for any advice -Rick

I've done a similar thing before, and no you don't have to sprinkle client-choosing logic throughout your views. What we did, to enable mobile-friendly views IF the client was on the mobile domain, was to check the domain and, if it was the mobile one, simply prepend a mobile-friendly dir onto the view path. That included the layout, which specified the mobile version of the css. What you could do is check the domain and prepend a client-specific dir. Very simple and efficient, especially if you ONLY put in those dirs the things that absolutely MUST change, while everything else remains the same and is drawn from the common dir.

-Dave

Dave Aronson wrote in post #1118796:

I've done a similar thing before, and no you don't have to sprinkle client-choosing logic throughout your views. What we did, to enable mobile-friendly views IF the client was on the mobile domain, was to check the domain and, if it was the mobile one, simply prepend a mobile-friendly dir onto the view path. That included the layout, which specified the mobile version of the css. What you could do is check the domain and prepend a client-specific dir. Very simple and efficient, especially if you ONLY put in those dirs the things that absolutely MUST change, while everything else remains the same and is drawn from the common dir.

-Dave

Very clever idea, thanks Dave!

Dave Aronson wrote in post #1118796:

...

check the domain and, if it was the mobile one, simply prepend a mobile-friendly dir onto the view path.

Very clever idea, thanks Dave!

Thanks! The *really* funny part though is that the client had an almost identical situation on their "test" for hiring programmers (whether as employee or contractor). Anybody who had already passed that test, should have been able to trivially come up with the solution we went with.

-Dave