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:
- 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
- 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
On Thu, Aug 15, 2013 at 8:43 AM, Rick S. [email protected]
wrote:
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
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 A., the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/.
Dave A. 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!
On Thu, Aug 15, 2013 at 7:43 PM, Rick S. [email protected]
wrote:
Dave A. 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
–
Dave A., the T. Rex of Codosaurus LLC,
secret-cleared freelance software developer
taking contracts in or near NoVa or remote.
See information at http://www.Codosaur.us/.