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.
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 in 4 different components as shown below. The database, the admin backend, the Forest Admin API server and the Forest Admin UI server.
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.
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.
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.
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.
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.
The following details the calls made by the browser when a user accesses the admin panel from his browser (at app.forestadmin.com).
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
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 notify the user a new version of his tool is available.
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.
When calls are made from the browser to the admin backend, the latter translates the call into a database query.
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.
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.
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.
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.