Live data from Hacker News

Show HN: Upmin – An Admin Framework for Ruby on Rails

upmin.com

41–50 of 55 posts

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#41
post #5

How does this compare to activeadmin?

I am biased, but I didn't like a few things about active admin: 1. Customizing views requires that you use Arbre. Learning an entirely new tool for generating webpages when every developer is already familiar with partials, html, erb, etc seemed backwards to me. 2. I tried to design upmin-admin so it was easier to setup. Active admin requires a little bit more work (but truthfully not a ton more). 3. Adding things li…

The view handling in Active Admin has always been a huge problem for me personally. I find myself at home with most any other Rails gem, but when it comes to Active Admin I always shudder and think "now I have to remember how to do things the way Active Admin likes them." Often I'll end up burning half an hour trying to figure out how to implement functionality that would normally take 5 minutes just because I have to figure out the Active Admin way. Anything that gets back to standard Rails action/template generation (like Devise) would be a godsend in the admin area.

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#42
Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an admin panel in this case - I'm reluctant to add asset pipeline etc to the rails app just for the admin panel, and I've also found the admin panels tend to use large amounts of RAM etc.

The other solutions all have downsides - you can build admin APIs into the API and have a separate app call them, but it's more work. You could make a separate rails app which calls the same DB, but then you have to keep the model code in sync.

Anybody found a good solution to this?

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#43

How does this compare to https://github.com/sferik/rails_admin ?

Truthfully, I haven't used rails_admin a lot. I can say that it is definitely more polished since it has been around much longer, but I have never tried to customize it or add in custom code so I don't know how it does there. Maybe someone else with more experience with rails_admin could comment?

I've used rails_admin extensively in my last two jobs, but haven't used any of the other comparable admin frameworks.

If what you want in some basic inspection of all objects with very little work, rails_admin is great. It pretty much does that, the end.

Adding a little bit of role-based access levels via CanCan is also super-simple with rails_admin. Paper trail works great for a simple audit log. Customization to the level of "using friendlier names for some attributes, organizing your data logically, and showing cleaned up pretty values" is pretty painless as well.

Where rails_admin gets a bit annoying in my mind is when you want to start adding custom actions (LOTS of cruft and boilerplate and magic for relatively simple results), or if you want to break out of the CRUD for models viewpoint at all. We're trying to use it to offer some non-technical people things like access into user history, and you end up fighting against the fundamental assumptions of the framework a lot.

(That sounds critical. I think that overall, rails_admin is great at doing what it does. We're trying to push way past the bounds of what it does, and we're running into some troubles there, but that's to be expected).

The major failing of rails_admin that I've noticed when you aren't talking about DEEP customization is that it does not handle 1:many or many:many relationships well when the number of associated documents is large. Like, we may have a model that has 500 or 5,000 child documents, and there's no easy way to paginate the list of child documents. Also, if you have a polymorphic relationship, your list of candidate child documents is just a simple HTML select, which is obviously unwieldy when the candidate list has thousands of entries.

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#44

Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an admin panel in this case - I'm reluctant to add asset pipeline etc to the rails app just for the admin panel, and I've also found the admin panels tend to use large amounts of RAM etc. The other solutions all have downsides - you can build admin APIs into the API…

You could use a rails engine to share the same models between two rails applications. Depending on the size of the project though, you may find that the economy of sharing models is a false one - applications of sufficient size may benefit from having separate models for user and admin interactions (see also: Domain Driven Design).

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#45

Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an admin panel in this case - I'm reluctant to add asset pipeline etc to the rails app just for the admin panel, and I've also found the admin panels tend to use large amounts of RAM etc. The other solutions all have downsides - you can build admin APIs into the API…

fwiw, we use active-admin for our Ember front-end/Rails backend app. We don't have a lot of actions that our admins can take but it's been really nice to expose some of the account details for support tickets, etc...

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#46
post #23

Certainly ActiveAdmin has given me a share of headaches as I built my website. That being said - it works, and I'm familiar with it(and Arbre) now. How do you plan to get established sites like mine to switch to Upmin with such a high upfront cost(namely, reconfiguring Upmin to have all the same functionality I bled for for ActiveAdmin?) Any kind of migration plan?

> I bled for for ActiveAdmin

I know exactly how you feel. Arbre is neat and all but I think it's a bad idea to use yet another language for your admin stuff. I always use partials so I can work in slim. I probably wouldn't switch now but I'll definitely think about it for my next project.

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#47

Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an admin panel in this case - I'm reluctant to add asset pipeline etc to the rails app just for the admin panel, and I've also found the admin panels tend to use large amounts of RAM etc. The other solutions all have downsides - you can build admin APIs into the API…

The asset pipeline shouldn't really be an issue with precompilation, or am I wrong?

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#48

Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an admin panel in this case - I'm reluctant to add asset pipeline etc to the rails app just for the admin panel, and I've also found the admin panels tend to use large amounts of RAM etc. The other solutions all have downsides - you can build admin APIs into the API…

There's no reason you need to host the admin panel on the same server as your API. You can even add your admin tool to your existing repository and deploy that single repo to two different servers, one of which you mount the admin engine in and the other you don't.

Re: Show HN: Upmin – An Admin Framework for Ruby on Rails

#49

Interesting, but the big gap here is for projects where your rails app is an API (using rails-api) only. We've been struggling with the best way to build an admin panel in this case - I'm reluctant to add asset pipeline etc to the rails app just for the admin panel, and I've also found the admin panels tend to use large amounts of RAM etc. The other solutions all have downsides - you can build admin APIs into the API…

> I'm reluctant to add asset pipeline

Consider using different/manifests layouts if you're concern is client-side. If it's compiling assets I think your concern is misplaced.

> admin panels tend to use large amounts of RAM etc

I don't think this is the case, or a huge concern depending on you're environment. Further, you could separate the apps into engines, they're great for this. TaskRabbit did a write up on this: http://tech.taskrabbit.com/blog/2014/02/11/rails-4-engines/

Personally however, I've normally roll out the app as one piece with active-admin, generically speaking most apps have little admin-specific logic to them, for example, it's normally something like: "Do for user(s)", "Approve content", the type of operations you do can easily fit under the simplistic nature of what active-admin offers. This isn't a catch all however, some applications require more of an integrative approach, in which case it's development as normal, bits of functionality injected here and there so-to-speak.

Post reply on HN