ActiveAdmin VS Forest Admin

Rails is absolutely fantastic for projects below 10,000 lines with 1 or 2 contributors, especially if you want a classic forms-based UI. And you can get a huge amount done under those constraints in Rails.

But as of couple of years ago, Rails came with a number of drawbacks:

1. There was no really viable system of static typing that a significant number of people were enthusiastic about. See https://www.reddit.com/r/ruby/comments/105sdax/whats_the_lat... for a discussion.

2. The lack of static typing meant far less IDE support. Fewer documentation tooltips, less autocompletion, etc.

3. I used to do a lot of Rails consulting. And whenever I had to drop into a codebase with more than 50,000 lines or 5 active developers, it was generally a painful slog. Too many weird Rails plugins that stopped being maintained, too much magic, too many nasty surprises while refactoring.

Basically, smaller Rails projects were an absolute delight. Larger Rails projects, though, tended to feel more like a swamp. Tools like https://activeadmin.info/ could tip the balance where applicable.

I still think that small Rails projects are fantastic, and I don't think anything since has remotely matched Rails' productivity within that niche. There's just too much mature tooling, and much of it works together seamlessly. But not too many projects want classic multi-page apps right now, and small projects often grow up to be big projects.

Can you clarify what's the "tremendous value" you're getting out of the Django admin?

At Heii On-Call https://heiioncall.com/ we are using Active Admin https://activeadmin.info/ for Ruby on Rails, which seems quite similar to the Django admin. In my experience, it's mostly useful as a fairly basic read-only view of what's in the database. In Rails, it's so easy to whip together a custom view that we tend to do that, and the Active Admin is nice to have but I wouldn't say "tremendous value".

Github Link : https://github.com/activeadmin/activeadmin

for those who know [https://activeadmin.info/](https://activeadmin.info/) it uses a file format [https://github.com/activeadmin/arbre](https://github.com/activeadmin/arbre)

Very neat! My first thought was that this was a competitor to https://bullettrain.co/.

Looking into it a bit more, it seems more aimed at building admin panels than whole apps. I guess it competes against tools like https://activeadmin.info/?

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.

I second Rails. It's incredibly polished and has really good gems to speed up dev. ActiveAdmin is a great gem if you need to quickly make an admin dashboard. It was useful when I had a small consultancy.

https://activeadmin.info/

See an example: https://activeadmin.info It provides a fast way to create back office functionality.

[1] https://activeadmin.info/

Forest Admin is an admin panel solution that saves your back-end engineers time and gives your operational teams more autonomy. Our highly customizable admin panel connects to your databases and APIs to ease your operations so that you can focus more on your business and less on backend operations.

Disclaimer: I'm the founder of Forest Admin.

I couldn't agree more with this statement. The issue isn't that internal tool builders lack a feature to do it, I think the problem is deeper and comes from the way they are designed.

Most of them allow you to build the frontend (web or mobile here) without providing any backend code. They provide you with an integration library, whether it's connecting to a third-party SaaS or to your backend code. But that's where it ends.

With [Forest Admin](https://www.forestadmin.com), we have a completely different architecture. All the backend code is automatically generated with the UI, allowing you to be up and running in a few minutes.

This has allowed us to provide a rich development workflow environment both on the backend (the code is yours and runs on your own machine, so you can use your Git without changing your habits) and on the frontend. This gives you the ability to fork a branch from your production environment to a dev environment, make your changes, merge them on a staging before pushing to prod, etc.

This command line is heavily inspired by Git but allows you to have a dev workflow that works for collaborating with large dev teams on your admin panel. (+100 at our largest customer).

https://www.forestadmin.com https://www.gravitee.io/

I didn't have a spare node app sitting around, so I found Forest Admin. This is actually a cool product which provides the simplicity of dashboard tools like ActiveAdmin or Retool, but preserves the privacy of the data by having you self-host the backend. The backend exposes an API that is used by the frontend client, i.e. your browser, so data doesn't need to move through Forest Admin's servers. Here's a nice graphic to visualize how this works:

Disclaimer: I'm the founder of (Forest Admin)[https://www.forestadmin.com].

Wow, I'm impressed by the number of solutions out there. Back at the beginning of Forest Admin, we were alone on the market, which is generally not a good sign. But our perseverance paid off, and it was definitely worth it in the end!

Alright, so why Forest Admin? :)

Because we only focus on the admin panel use case. Not the entire internal tools world. In this way, we are able to provide a fully-featured SaaS Admin panel out of the box. No need to build it, nor with code, nor with low/no code tools.

Even if your app, internal processes and so your admin panel is specific, we have designed our solution accordingly with 2 things that are part of our DNA from the beginning:

1/ We generate all the backend code required to an admin panel. All CRUD routes, filtering & search, dashboarding, permissions, etc. Everything is automatically generated in a few seconds based on datasource introspection. In the end, the generated code is just a standard REST API, so you can extend/override it without any limitations.

2/ We pre-built the admin UI with every admin standard features available out of the box, with a big focus on providing a great UI/UX possible for operational people. We obviously also provide all the low/no code features to customize pretty much anything. We also provide a feature called "Workspace" (which is generally the core of what our competitors do) that allow users build custom views using drag'n'drop of UI components from scratch.

For home-lab/internal UIs, you can go a long way with the auto-generated model-admin pages from Django. If you just need CRUD and actions triggered on a list of models, you can typically avoid any UI work and just define a few Admin classes, and if you need to make custom forms it's quite easy using Django's templating machinery to override individual pages.

https://docs.djangoproject.com/en/4.0/ref/contrib/admin/

A similar modular admin system that's more generic is https://www.forestadmin.com/, I think this one has a layout editor too. But that one requires a REST API and so it may require more plumbing, depending on what you've already built. Or it could fit nicely on top of what you already have, if you already have APIs for everything.

In this blog, we'll see how to build a CRUD app with Forest Admin. We'll assume you're building a CRUD app for a PostgreSQL database.

At Forest Admin, we build admin panels for which we need to compute and cache large JSON documents. These documents are stored in redis and retrieved from this storage in order to be as fast as possible.

At Forest Admin, we recently faced this issue to move data from a Postgresql database to ElasticSearch.