How to keep DRY with a ActiveAdmin or RailsAdmin, separate from the main application

Question

I am building a JSON-only application, it is basically a leaner Rails, with fewer middleware and fewer modules. This is an application being built in Rails 4.

I want to to develop a simple app that can administrate the data in the database for the main-app. For this I would like to use Active Admin or Rails Admin. But both options somehow use the underlying models and their validations, requirements and such to build on top of.

This means that I need to share at least the models between the main application and the RailsAdmin application.

How would I best do this? Is there a good guide on how to build an administration-application in a separate rails app next to your main one, instead of having it integrated?

As a side note: another good reason to keep the admin in a separate application from the main app, but on a shared database, is the myriad of dependencies, a gem like ActiveAdmin comes with.

Also note that I am not simply interested in running admin on a different domain or different server, but mostly to keep main app lean and focused. And to keep the dependencies with which something like ActiveAdmin comes, out of my main app.

---

footnotes:

• Neither ActiveAdmin nor RailsAdmin are problems for performance in themselves. It's that they require middleware, whereas a JSON-only Rail-app, needs only very few modules, helpers and middleware! Rails-API, offers such a slim stack. Performance is not about Admin vs. no admin, but Full-Rails vs Rails-API.
• Performance is not my main problem, the dependencies and bloat is! I now have a Rails application that is so slim, focused and lean, that it can measure itself with most Sinatra apps :). With only three additional gems (each with a few dependencies of their own) and a very thin stack of middleware, I can upgrade, manage and debug very easily.

More practical: I don't have Devise (It's a JSON-API, so token-authenticated), don't have any views or template-engine. No Formtastic, No Paperclip, Rmagic, Kminari (pagers) and so on and so forth. All of which will be added to my app when I pull in "just an admin".

Percent

I would look into extracting the model classes to a gem that you could require in both apps. I'm afraid I can't offer specific advice, as I've never actually done this, but in theory it should work. You'll need to share the database.yml file somehow, or just make sure it stays up-to-date in both places. – Blotto

Thank for the hint. This, indeed, sounds like a very good solution for me. – Percent

Any update on what you ended up doing? I'm finding myself to be in the same situation – Cyan

Answer 1

This blog post describes an interesting approach: https://content.pivotal.io/blog/migrating-from-a-single-rails-app-to-a-suite-of-rails-engines

They use a nearly empty app as a container and mount their actual apps as Rails Engines.

Thoreau

Answer 2

did you measure the impact of adding tools like ActiveAdmin to the speed of your rest API? if not, this sounds like a case of premature optimization to me.

in the case that the API speed really has an impact by a library that is loaded but not used, then you could create multiple applications and share the models in a git submodule.

Riegel

Yes, I did, albeit rough and very unscientifically :). Adding the full rails stack nearly doubles the amount of memory in use. It Quadruples the startuptime (mostly irrelevant for production) and it makes (several of) the responses up to three times slower. But, like I said, having all the dependencies in there is actually more of a problem. I've had several apps breaking on updates because of incompatbility with e.g. the jQuery version that ActiveAdmin needs, or the uploader that RailsAdmin needs. – Percent

i find it quite interesting, that you have slower responses in production when using an admin. did you have a look where this comes from? but as i already wrote and Zach pointed out too, just share your models via a git submodule or a gem. bundler is very helpful with this. – Riegel

phoet and others: I've added some footnotes to make my points about performance a bit clearer. – Percent