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.
Result
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.
.