← Back to Upcase

Building admin sections

We add an admin area to basically every application we build. There are a number of approaches that we’ve taken for these:

Writing a custom admin area for basic tasks tends to be tedious and repetitive, but there are some approaches that can be taken to alleviate this. Rails Admin and Active Admin on the other hand try to give you a very painless administrative experience but can cause pain when you need to stray just a bit outside of the box.

How do you approach admin areas? We’ll be discussing the various approaches to admin areas at the thoughtbot Boston developer discussion tomorrow afternoon and I’ll post our notes here.


I’ve used ActiveScaffold with great success; it’s been around since Rails 1.x

My approach here has been to buy an off the shelf template/wrap (for situations where the admin is only used by a tiny few, I tend to work on MVPs and early products) and then build a custom admin interface, attempting to reuse my own view/controller code whenever it is possible.

I was very enamored with Active Admin when I first started working on Rails apps, but every time I attempt to implement it, there will be some non-standard data relationship or form interaction that requires a bunch of custom coding, which often wipes out a considerable portion of the benefit of using Active Admin.

(* I should state that I haven’t used Active Admin in about 18 months, so I’m open to being convinced to give it another try.)

My experience with ActiveScaffold is that for more than trivial things, you’ll spend most of the time fighting it.

As for ActiveAdmin, my experience is that it gets really slow in development, not really sure why. Also, don’t like the whole add a new DSL to your app approach.

Never used RailsAdmin, but even though it might get tedious and repetitive I’ve never had a satisfactory relationship with anything but to build my own. Would love to hear what you guys have to say about it, though.

Administration Gems

For the most part, the group felt that ActiveAdmin and RailsAdmin were good wins for MVP implementations – particularly when the target user of the interface was at least somewhat technical. The speed with which you can get CRUD operations done across all your models is great. Unfortunately, with both of these solutions, customizations can quickly grow pretty painful.

** Rails Admin: **

  • PRO: With a single initializer, you’ve got CRUD on all fields on all models.
  • PRO: Flexible authorization with CanCan
  • CON: Configuration all in one initializer can get ugly and configuration in your models is a bad idea.
  • CON: Design. Most people didn’t like the bootstrap-like (is it bootstrap?) look and feel. The default dashboard showing resource count graphs was gratuitous and a potential performance problem.
  • CON: (maybe)… low Code Climate score.

** Active Admin: **

  • PRO: Configuration split across several files (one for each model).
  • PRO: Decent documentation (and you’ll probably need it)
  • PRO: Powerful filtering functionality
  • PRO: Designed for customization. DSLs for customizing filters, forms, indexes, the controller, etc.
  • CON: Dependencies that don’t line up well with suspenders. Now you have clearance and devise. SimpleForm and Formtastic.
  • CON: Slow to update. Rails 4 work is still “in progress”.
  • CON: Default filtering can be a huge performance problem as it populates dropdowns of associations, etc… Be sure to opt-in to specific filters.
  • CON: Various customization DSLs are far more difficult to remember than the code would be.

** Winner: ** A slight preference for giving Rails Admin the benefit of the doubt. Its dependencies line up a little better with what we typically use. It also seems more up-to-date with Rails.

Overall, we wish these were both designed to be more modular. Don’t make me take a dependency on Kaminari if I have some super new and awesome paging gem I’m using in the rest of my app. Don’t make me take a Devise dependency when I’m using Clearance.

A significant advantage to both of these is that your testing burden is lessened. If you stick to configuration-based overrides, we felt that it likely wasn’t necessary to test each action. Testing access restrictions was likely enough. When you start to override default controller actions you probably want to test. @pat mentioned that Rails Admin allows you to pass a proc to customize the controller action, which means you can assign that Proc to a constant (or use a Class that responds to call) and then unit test that. ActiveAdmin’s reliance on InheritedResources might make this tougher, but it’s a very interesting idea.

Roll Your Own

If administration features are key to your MVP or administrative users are crucial customers of your app, consider rolling your own administration section for a better UX. Additionally, if your admin users are non-technical, the model-driven admin in a completely different UI from the rest of your app is likely to be more challenging to use.When creating your own, we discussed a few options.

** Standard, Admin-namespaced Rails Controllers: **

  • PRO: You know how to write them and how to test them.
  • PRO: The UI looks like the rest of your app.
  • CON: You add your standard controllers and UI and now you’ve got to do a lot of that again for the admin interface. Even sharing as much as possible you’re bound to duplicate some effort.
  • CON: Adding search and filtering is yet more work.

** Inherited Resources / Template Inheritence Based: **

I showed an admin area I had written where all the admin controllers inherited from ResourceController, which included the inherited_resources mixin. There were no show actions – this is an admin section so everyone can Edit. Just take them there. Each model you wanted to add administration for was responsible for bringing it’s own _form.html.erb partial and it’s own index.html.erb template. This template was a single line that called the admin/resources/_index.html.erb partial, supplying an array of fields to render in the table. The controller was customized with inherited resources.

Most of this approach is documented here

  • PRO: UI looks like the rest of the app
  • PRO: Very little code. The hardest part was writing the form for each object.
  • CON: Inherited resources is a pain to work with. You have to keep consulting the documentation
  • CON: When you step away for a bit and then come back, it can be hard to remember how the magic works (both Inherited Resources and the template inheritance).
  • CON: Searhicng and filtering was not addressed.

** Inline Admin: **

By this, we mean exposing administrative actions in the regular UI. If you’re an admin viewing another users profile, you also have and edit link right there.

  • PRO: Very user-friendly for admins. No need to know what model something is or where in the admin UI it is.
  • PRO: No additional controllers or routes to write and test.
  • CON: Lots of conditionals in your view
  • CON: Makes caching more difficult because the cache key now depends on the role of the user. This is true of any reliance on current_user in a template.

** Winner: ** Who knows?

The inline admin has some pretty specific use cases. If your audience is unlikely to be able to follow to a separate admin interface to administer things then this might make sense. You may even be able to mitigate the ‘cache key’ and ‘conditionals in views’ issues with administrative layouts or JavaScript if this is a key aim of your app.

I liked the template inheritance used in the solution I presented, but don’t like inherited resources very much (It’s one of my complaints about ActiveAdmin). @calebthompson and I discussed an approach that would keep the template inheritance but define the standard controller actions in the base controller itself, farming out to template methods that subclasses could override for just about every decision. redirect_after_create, etc… I think I’d like to try this approach on an app.


It will likely continue to make sense to use something like RailsAdmin for our MVPs. That was the slight favorite amongst the two gems in our group. No one was wildly in support of either of them, but if admin isn’t on your critical path it’s a simple thing to punt to one of these gems. As you begin to customize the admin though, particularly if you are adding critical features to it, you should consider if you’d be better served moving to something custom.


@derekprior What happens if an MVP scales and new features are added, etc… Do you throw RailsAdmin out an do it yourself? Or you kinda get stuck with it?

Wrote a blog post on setting up ActiveAdmin with Clearance if anybodies interested - http://www.ralphonrails.com/rails/2014/04/15/activeadmin_clearance.html

Hopefully saves you a bit of time if you’re looking to do this :slight_smile:

Hi there,

We launched Avo a few weeks back.
Avo is a beautiful next-generation framework that empowers you, the developer, to create fantastic admin panels for your Ruby on Rails apps with the flexibility to fit your needs as you grow.

Out of the box, it has an excellent CRUD interface, ordering, filters, and actions. It knows how to handle your Active Record model relations and gives you powerful role-based authorization control options.

It’s super easy to configure. Codewise, there’s one configuration file per model and one configuration line per field.
You can add simple fields like text, textarea, dropdowns, and more complex ones like datetime, badges, loaders, currency, and others. There’s even a cool one-liner single or multi-file Active Storage integration :exploding_head:.
The whole interface is translatable along with resources and fields.

Avo’s mission is to make developers’ jobs more comfortable and help them and companies move faster by giving them a cool easy Rails admin package that they can be proud of.

Try it in your app today and let me know what you think about it.

Thank you!

AvoHQ.io · Twitter · GitHub · Discord