Once upon a time, I swore by WordPress. I had got pretty good at using advanced custom fields and using custom post types to do pretty much anything I wanted. I built lots of complex web apps, writing terrible AJAX functions to try and make the user experience as slick as possible.

I bounced about in Berlin making MVPs and whenever anyone said I should use a different framework, I was all like:

“But WordPress does so much for me!”

I was prepared to forgive WordPress for pretty much anything because it provided me with pre-built features like a great user system, rooting and most importantly an admin dashboard. 

Eventually, I made the switch to Meteor thanks to Kasper and others. I was completely blown away by how simple it was to achieve the results that I’d been striving for with WordPress. Ok, there was a bit of a learning curve, but I knew that I’d found the one. Still, there was one question:

Where’s my admin dashboard at?

Admin dashboards are really important. They

  • Let you quickly (and safely) create/edit/remove data
  • Allow administrators privileged access 

If you’re building for yourself, great. You can probably get away with not using an admin dashboard and instead use something like Robomongo. However, if you’re producing something for a client, they’re almost certainly going to demand an admin dashboard

I found myself creating 2 admin dashboards in 2 weeks for 2 different clients. That was 1 too many.

The three pillars of Meteor Admin


Information should be displayed and accessed in the most simple of ways. It should be intuitive. In my opinion, it should also be beautiful (especially if a future customer service agent will spend hours looking at it).

Meteor Admin’s solution: AdminLTE.

AdminLTE is open source and is fricking awesome. I’m sure that the agency behind it is raking in new clients because of their open source efforts.

CRUD functionality

Not a nice word, but extremely important. CRUD stands for Create, Read, Update and Delete. In Meteor speak this:





Meteor Admin’s solution: Autoform.

Autoform is a truly awesome package of Meteor badass, Eric Dobbertin, and should be used in every frickin’ app that contains a form.

Without Autoform, Meteor Admin would not have been a possibility. By defining and attaching a schema to each collection, it’s possible to automatically generate a form. By defining the form’s operation (insert, update or  remove) we get the CUD of CRUD. Does that sound better or worse..?


You can think of your Admin Dashboard as a member’s only exclusive club which only lets that exclusive *cough* administrator *cough* type of person in.

Meteor Admin’s solution: Roles.

Roles let’s you create roles for your Meteor app and check a user’s _id against those roles.

Putting it all together

This was the first ‘serious’ package I built, but effectively the development process went like this:


  • Figure out what was good and bad about the 2 meteor admin dashboards I’d done before
  • Think about the admin dashboard I’d want for various web apps
  • Look at limitations of Autoform and Roles package and play around with LTE


  • Routes & their parameters
  • Subscriptions & publish functions
  • Templates – how to minimize and reuse as much as possible
  • What kind of API (AdminConfig) to use?


  • Break up LTE Admin dashboard and meteor-ify it using ‘dummy’ routes with no meaningful parameters
  • Implement Autoform’s for the create / update pages
  • Add Roles and prevent non-admin users from viewing 


  • Tentatively post on Meteor talk
  • Implement with existing Meteor apps

Making it developer friendly

I like idiot-proof software for personal reasons.

Replacing allow rules with methods

Originally, you had to set your own allow rules such that an admin user could create, update and remove from the collection.

This is necessary because Autoform (intelligently) does as much on the client side as it can. To get round this, I needed to hijack the submit button for my own nefarious purposes: now it calls a method.

CRUD behaviour running server side skips the allow and deny rules. It was only necessary to check that the method was coming from an admin user.

adminUpdateDoc: (modifier,collection,_id)->
  if Roles.userIsInRole @userId, ['admin']
    #Do update

Allow for customisations

Once you’ve got your dashboard up and running, you need to be able to change it. 

So far the list of the major customisations include:

  • Adding collections
  • Assigning collection a colour and an icon
  • Controlling which columns you see when looking at collection data
  • Customizing widgets on the home page
  • Hide fields from the forms (like createdAt for exmample)
  • Adding links to the sidebar

Next steps…

What I really want to see happen in 2015:

  • Solve the problem of collection dependencies
  • Lots of widgets
  • Add-on packages for showing user stats etc.

Please let me know if you have any feature requests or bugs on Github or in the comments.