
<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I’ll chime in with Graham about using a single app. There’s a certain appeal to software purity, but I’ve found in the past (when I’ve carefully written separate apps, or had clear delineations between parts of an app, assuming a largely overlapping set of users) that as the application matured, the two apps increasingly became one, and an eventual rewrite forcibly made them one. </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I would satisfy my desire for code order by looking to the commonalities of the application — the overlapping user base, for example — and writing a single app that addresses those commonalities. Make the domain of your application broader than it actually is so that your components/modules are implicitly included in that broad domain. Your users don’t care that it’s all one app — in fact, they’ll probably prefer it without being able to express why — and you’ll have a lower long term maintenance burden on account of it. </div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Paul.</div> <br> <div id="bloop_sign_1432043680030273024" class="bloop_sign"><span style="font-family:helvetica,arial;font-size:13px"></span>-- <br>Paul Doerwald<br>Chancellor, Liquid Media Inc.<div>902-412-2492</div><div><br></div></div> <br><p class="airmail_on" style="color:#000;">On May 19, 2015 at 11:37:41, Graham Ashton (<a href="mailto:graham@effectif.com">graham@effectif.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Are there any relationships (in the business domain) between the data that the two apps deal with? I'm wondering whether it would (user interface and code-complexity issues aside) make sense to store them together. It could provide another useful angle on whether keeping things separate makes sense.<br><br>If putting it all in one database sounds good (or at least, doesn't feel uncomfortable) I'd favour the cheapest approach approach to maintain that delivered a good end-user experience.<br><br>I suspect that means I'd favour a single app, organising the code in namespaces, and sharing all the stuff that's common. It's easy to over engineer stuff like this, and force yourself to jump through costly hoops.<br><br>Namespaces are great. In my experience, we Rails developers don't use them enough.<br><br>If you're reluctant to use namespaces, is there a specific problem you'd be trying to avoid?<br><br>Cheers,<br>Graham<br><br><br>On Tuesday 19 May, Kerry Buckley wrote:<br><br>> Hi LRUG,<br>> <br>> I have a small Rails app used by a closed set of internal users, and am<br>> about to create another, for the same users (or at least an overlapping<br>> group). They've asked that the two apps (and potentially more over time)<br>> are presented as one integrated front end, rather than users having to<br>> visit multiple URLs, log in separately etc.<br>> <br>> I'm wondering what the best approach to this is. I don't want to go to the<br>> extreme of a JS front end with the Rails apps just presenting JSON APIs, so<br>> the main options seem to be:<br>> <br>> * Separate apps with matching layouts, and headers, with some kind of<br>> single sign-on<br>> * One big app with namespaced routes, controllers etc to try and keep<br>> things vaguely separated<br>> * Separate apps into Rails engines, mounted in a master app that manages<br>> sessions etc<br>> <br>> I'm kind of leaning towards the third option, but I've never used Rails<br>> engines before, and I'm not 100% sure how that approach would work out. My<br>> main concern is acceptance/integration tests – it seems to me like they'd<br>> have to live in the wrapper app as most of them would rely on users,<br>> sessions etc.<br>> <br>> Has anyone had experience of this kind of thing, and if so, which of the<br>> above approaches would you recommend (or discourage)? Is there a better<br>> solution I've missed? I'm about to start spiking something with engines to<br>> see how things fall together, but some opinions from someone who's done it<br>> in anger would be great!<br>> <br>> Thanks,<br>> <br>> Kerry<br><br>> _______________________________________________<br>> Chat mailing list<br>> Chat@lists.lrug.org<br>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org<br>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org<br>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org<br><br>_______________________________________________<br>Chat mailing list<br>Chat@lists.lrug.org<br>Archives: http://lists.lrug.org/pipermail/chat-lrug.org<br>Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org<br>List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org<br></div></div></span></blockquote></body></html>