Lumber vs Forest-rails

I wanted some input into how to proceed with our Forest Admin integration.

From what I can tell the forest-rails gem is not really recommended for use, this is seen both by reading the documentation in general, and especially considering this pull request:

Now, we’re running a Rails application with a lot of callbacks. For instance when creating a topic-object, a number of callbacks for creating pg_search entries are triggered. When creating a user, emails are sent etc.

Given this app setup, and the recommendation not to use the Rails gem, does that mean we’re encouraged to create loads of smart actions, so our business logic can be triggered, and disable the default CRUD-actions in Forest Admin as much as possible?

Also regarding this, why is the use of the Rails gem discouraged?
We are currently testing out a Lumber-generated backend but we see a need to expand the functionality and creating a separate API for it seems like quite a lot of work if the forest-rails gem does the same without the added complexity.

Any input regarding the situation would be helpful!

Hi @svensson-david, welcome to our community!

The use of gem rails is strongly discouraged and is no longer possible in our installation process.

Forest Admin is installed directly on your database and generates a dedicated Admin API which is different from your APIs to make sure Forest Admin works correctly. This architecture allows for more flexibility and scalability.

As you mentioned, it is very common to implement your business logic when it comes to manipulating your data in your database using Forest Admin. Several options are therefore possible:

  1. Extend/Override CRUD routes to call business logic from another backend application.

  2. Use smart actions to perform more specific actions related to your business (refund a customer, cancel an order, etc.)

It is also quite common to use Forest Admin in read-only mode to interact with your data using smart actions.