Draper VS RailsAdmin

So what about the world outside Rails defaults? There are quite a few independent projects trying to help build components in the Rails view layer, among the more famous being Draper (utilizing the decorators pattern) or Cells (full-featured components in views). In the end, we decided to take a deeper look into a relatively new one – the ViewComponent framework.

If you are not a big fan of writing Rails custom helpers, you can always opt-in for a View Model pattern with the Draper gem. Or you can roll your own View Model pattern here, it shouldn't be that complicated. If you are just starting out with your web app, I suggest starting slowly by writing custom helpers and if that brings pain, turn to other solutions.

The Draper gem is the one I'm familiar with which does this well, I'm sure there are others.

Don't introduce decorators and view models. Use helpers instead. Don't extract domain models. Put the code in the ActiveRecord models and the controllers. Don't reach for interactors to model your domain logic. Don't try to avoid duplication too early.

7. DRAPER

Like most things, it's probably a combination of things.

The Django Admin existed before Django publicly existed. That meant that once anyone started using Django they knew that they should constrain their use of Django in certain ways so that the Django Admin would work with their usage. Features that would be added to Django would be built with the Django Admin in mind.

Many tools like Flask or FastAPI don't have an opinionated model layer like Django. Without that, you can't really create an admin interface programatically. People could be storing their data in any sort of fashion anywhere. How would one build an admin system for something like Flask or FastAPI where there's no convention around how people set up data access? A lot of frameworks out there don't tell you "access your data in this way" or "this is how users will be authenticated." Without those two things, it's hard to really create an admin system.

There are similar systems available for some frameworks, but since they aren't part of the core framework, they don't get the same attention. Someone creates it, but it doesn't have the kind of community buy-in that sustains it. One of the odd things about Django is that the admin system is under `django.contrib` which indicated that they didn't intend for it to be in the core of Django forever, but that's not really how `django.contrib` ended up. It continued to be a core part of Django maintained as part of the framework.

Like I said, there are admin dashboards available in other frameworks like RailsAdmin (https://github.com/railsadminteam/rails_admin) or Core Admin for .NET (https://github.com/edandersen/core-admin) and I'm sure there's more. However, both Rails and .NET provide most of what Django provides (and a lot more than most frameworks). Rails and .NET both have a default data access ORM that a majority of people using those frameworks tend to use. .NET has built-in authentication/authorization so the admin can work off that. Rails doesn't have auth, but RailsAdmin uses some plugins.

We briefly considered migrating to a full-grown Rails admin interface, such as ActiveAdmin, RailsAdmin, Administrate or Avo. We especially liked Avo which is built on a very modern stack similar to ours (Tailwind + Hotwire + ViewComponents). In the end, we didn’t go this route as we found some of the options a bit too restrictive (even though Avo is very flexible) and we did not feel like trying to amend it to our needs. For example, Avo renders forms in a 1-field-per-row layout while we wanted something more similar to the Tailwind UI Stacked form layout. Nevertheless, we found a great deal of inspiration in the Avo code and its design principles.

- [rails_admin](https://github.com/railsadminteam/rails_admin)

rails_admin

https://github.com/railsadminteam/rails_admin is very popular and i find it very easy to use.

It's really helpful to have a way to track what's going on with your application in production, things like: number of user sign ups, status of user accounts, number of X new database entries etc. Out of the box dashboards like Rails Admin are great but only go so far, eventually you will want significant customizations.

I'm working on a rails project with rails_admin and multiple models. There are several people working on the backend and I want to remove the ability to edit some of the records which have a imported boolean set to true. This records should just be readable in rails_admin.

Having an admin panel in your Rails application is honestly, to me, the best thing to do when it comes to keeping track of your users and giving them permissions. Finding out how to have an admin panel though, that was tough, mainly because I wasn’t searching for the right thing. The rails_admin gem, so simple but can control so much! The installation and usage is very simple depending on what you are trying to use it on. I should probably tell you, I am using devise with the user having a boolean attribute called admin.

Check out Retool: https://www.ycombinator.com/companies/1564

A wswig for internal UI/dashboards has a lot of value for companies that don't have a dedicated internal tools team.

My company had an internal tools teams at one point but it got killed because of other business priorities.

We use https://github.com/sferik/rails_admin, that still requires development time and frontend knowledge, but the framework is terrible.

https://marmelab.com/react-admin/ is much better but also required development time and frontend knowledge.