[LRUG] Multiple Rails apps sharing common UI

[Karl Entwistle]

I recently created a Rails Engine for the agency I work at. We wanted to
share some commonality between our apps. We've found the Rails engine
approach useful to achieve this. 

>From a testing perspective you might have to look at the source code for
Devise, Spree and ActiveAdmin to see how they've achieved this. They
typically have a dummy rails app within their test directoy that they
use to perform integration tests against. In your case this dummy app
could include the basic authentication dependency you mentioned.

https://github.com/plataformatec/devise/tree/master/test/rails_app

http://ryanbigg.com/2012/04/integration-testing-engines/

Cheers
Karl 

On Tue, May 19, 2015, at 10:10 AM, Alejandro Andres wrote:
> I've done something similar, sepparating the apps by subdomain, using the
> same rails app. That way you have a 'namespace' for each app (the
> subdomain). For shared data I had an api subdomain (but beware because
> then
> you'll have to use CORS)
> 
> Hope it helps :)
> 
> -
> Alejandro Andrés
> Partner at redradix.com
> 
> On Tue, May 19, 2015 at 11:08 AM, Kerry Buckley <kerryjbuckley at gmail.com>
> wrote:
> 
> > Hi LRUG,
> >
> > I have a small Rails app used by a closed set of internal users, and am
> > about to create another, for the same users (or at least an overlapping
> > group). They've asked that the two apps (and potentially more over time)
> > are presented as one integrated front end, rather than users having to
> > visit multiple URLs, log in separately etc.
> >
> > I'm wondering what the best approach to this is. I don't want to go to the
> > extreme of a JS front end with the Rails apps just presenting JSON APIs, so
> > the main options seem to be:
> >
> > * Separate apps with matching layouts, and headers, with some kind of
> > single sign-on
> > * One big app with namespaced routes, controllers etc to try and keep
> > things vaguely separated
> > * Separate apps into Rails engines, mounted in a master app that manages
> > sessions etc
> >
> > I'm kind of leaning towards the third option, but I've never used Rails
> > engines before, and I'm not 100% sure how that approach would work out. My
> > main concern is acceptance/integration tests – it seems to me like they'd
> > have to live in the wrapper app as most of them would rely on users,
> > sessions etc.
> >
> > Has anyone had experience of this kind of thing, and if so, which of the
> > above approaches would you recommend (or discourage)? Is there a better
> > solution I've missed? I'm about to start spiking something with engines to
> > see how things fall together, but some opinions from someone who's done it
> > in anger would be great!
> >
> > Thanks,
> >
> > Kerry
> >
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> > Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> > List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> >
> >
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org