How does the Forest Admin hybrid architecture work?

Introduction

Internal tools like admin panels are oft overlooked. Because time spent on building them equates to time not spent on shipping the next shiny feature.

So what happens when non-technical teams need to see or manipulate an app’s data? They are stuck with rushed and frustrating tools.

Forest Admin empowers developers to build and ship admin panels. Ones that are easy for non-developers to use, easy to adapt, and easy to extend. For a fraction of the time it would cost to develop them in-house.

Here we’ll explain the architecture we chose to provide such a service. Without forcing you to choose between the privacy and security of an in-house solution and the convenience of a SaaS. Yes, you can get the best of both worlds and no, there’s no catch.

How does Forest Admin work?

Forest Admin provides you with an admin panel for your internal teams to see and manage your data. But what happens under the hood to build the interface for your teams?

The whole architecture consists of 4 different components as shown below. The database, the admin backend, the Forest Admin API server and the Forest Admin UI server.

1. Your database

The database is the most vital part of any stack. It’s where your application data lives and resides. It reflects real world transactions from your customers.

It’s also the first building block needed to create your admin panel on Forest Admin. Because it will be the main data source for it.

Forest Admin currently supports RDBMS* such as MySQL, Postgres & MsSQL. In the NoSQL databases family, it supports MongoDB.

2. Forest admin backend

When you install Forest Admin, you generate a node.js application on your local machine. It includes a RESTful API that connects to your database. We call this app the admin backend. It feeds all the data to your admin panel interface.

To get more technical:

it translates client requests (from the user browser) into queries to your database.
it also provides the Forest Admin API Server with the information needed to build the User Interface. This information includes table names, column names and types, and relationships.

A JSON file called the forestadmin-schema.json carries this metadata within the admin backend.

3. Forest Admin API server

The Forest Admin API Server stores the information to build the user interface. This includes both the database structure (sent by the admin backend) and the UI customization made by the user.

To get more technical, the information stored includes:

Display & Order — Which tables and columns should be displayed or hidden? In what order should the columns appear in the ‘Table’ view?
Collection Settings (permissions) — Are the records in this table read-only? Can they be deleted? Can they be exported in a .csv file?
Widget preferences — Which UI component should be rendered for each column (e.g a file viewer for a column that contains images urls).
Chart configurations — How are the dashboard charts configured and in which position should they appear?

The Forest Admin API Server also manages the Forest Admin app’s logic like user authentication or billing.

4. Forest Admin UI server

The Forest Admin UI server stores static assets. These include HTML documents, CSS stylesheets and JS script files. It provides the UI components needed to build the interface that displays the data.

Now that you have a good overview of the architecture, you may be wondering how the pieces actually interact to make it work.

How do all the pieces come together?

Let’s figure it out by checking the http calls made between each of the above-mentioned elements when operating a Forest Admin project. Namely calls made:

between the user’s browser and the Forest Admin servers (both UI and API servers),
between the user’s browser and the admin backend,
between the admin backend and the Forest Admin API servers.

Calls made from the user’s browser

The following details the calls made by the browser when a user accesses the admin panel from his browser (at app.forestadmin.com).

To the Forest Admin UI servers

Calls need to go out to the Forest Admin UI server to fetch static assets including:

HTML documents
CSS stylesheets
JS scripts
A map of the assets

To the Forest Admin API servers

Calls need to go out to the Forest Admin API servers to retrieve information regarding:

the user logged in,
the project he’s logged into,
the environment he’s logged into,
the configuration of the rendering to be displayed (i.e. the configuration of the UI),
the widgets configuration,
the billings info of the project,
any updates happening on the UI configuration. This is done through websockets.

To the admin backend

Calls need to go out to the admin backend to retrieve/ modify data from the database including:

GET calls to retrieve a list of records, the count of a list or the details of record,
PUT calls to modify a record,
POST calls to create a new record or trigger a custom action,
DELETE calls to delete records.

Calls made from the admin backend

To the database

When calls are made from the browser to the admin backend, the latter translates the call into a database query.

To the Forest Admin API servers

In order to ensure that the UI reflects the structure of the database, the admin backend needs to send calls containing the information from the forestadmin-schema.json to the Forest Admin API servers. This file is sent upon every restart of the admin backend server.

At the startup of the admin backend and periodically afterwards, calls are also made to the Forest Admin API servers to retrieve permissions. This protects the data from being accessed by unauthorized users through curl requests for example.

Now that we’ve detailed how Forest Admin works, let’s discuss why we went that way.

What are the benefits of such an architecture?

Build internal tools with privacy baked in right from the start

We can’t store any of your data because we never get to see it. You own your admin backend. That means no Forest Admin backend (on our servers) proxying requests to your database.

You can host it in the cloud architecture you want. You can shield your admin backend to comply with any of your security requirements — VPN, VPC, DMZ…you name it.

Your internal tools, your rules

You own the admin backend and can extend it like any node.js app. Using JavaScript and npm packages, you can add any custom logic you want. When you create a record you want to add an automatic email alert on top of inserting a row in your database? You can do so by easily overriding the default create route from your admin backend for example.

This means you can also keep track of any changes using Git, containerize your app using Docker, deploy on your favorite Cloud Hosting Provider…
You remain in control.

You do half the work, we take care of the other half
This architecture lets you benefit from improvements and new features by updating to our newer versions of the API. All it takes is one command
npm install forest-express-[sequelize|mongoose]@latest.

You also benefit from continuous updates brought to the UI by refreshing your browser page. Again, one command Cmd+Shift+R.

So, what next?

Want to try our admin panel framework? Get started with Forest Admin for free! 🌲
Curious what Forest looks like? Take a peek at our live demos 💻
Interested in deep diving into the tech? Peruse our documentation 📚
Care to learn more about our company (how we see our mission, values we look for in candidates we hire, or our latest news, etc.)? Check out our blog! 🗞️