High-level architecture of a hybrid SaaS solution


Forest Admin is a device that routinely generates admin panels on prime of your database, that may then be customised. Due to the privateness and safety necessities most builders and organisations rightfully have over their information, we needed to construct our answer in a means that ensured these necessities have been revered in an effort to present a viable provide. That is why we determined to go along with a hybrid SaaS structure.

We outline a hybrid SaaS answer as a software program relying concurrently on a SaaS half and an on-premise half. The SaaS half is hosted and managed by the seller, and contains the consumer interface the customers will hook up with and work together with through their browser. The on-premise (or self-hosted) half is managed and hosted by the consumer, and contains the customers’ information and the seller offered parts to ship and obtain the related information to and from the consumer interface.

As mentioned within the first paragraph, the principle benefit of such an structure is that the consumer’s information won’t ever be seen by the seller, and stays throughout the consumer’s managed setting. As well as, the consumer will routinely advantages from updates launched by the seller similar to with any SaaS answer.

Let’s element this hybrid SaaS structure, utilizing Forest Admin for example.

Excessive stage hybrid SaaS structure

In Forest Admin’s case, the entire structure consists of 4 completely different parts as proven under. The consumer’s database, the admin backend, the Forest Admin API server and the Forest Admin UI server.

1. The consumer’s database

The consumer’s database would be the essential information supply for Forest Admin to generate admin panels, and feed them.

2. Forest admin backend

When a consumer installs Forest Admin, they generate a node.js software on their native machine. It features a RESTful API that connects to their database. We name this app the admin backend. It feeds all the information to your admin panel interface.

What it does:

  • it interprets shopper requests (from the top consumer browser) into queries to the consumer’s database.
  • it additionally offers the Forest Admin API Server with the knowledge wanted to construct the Consumer Interface. This data contains desk names, column names and kinds, and relationships.

A JSON file known as the forestadmin-schema.json carries this metadata throughout the admin backend.

3. Forest Admin API server

The Forest Admin API Server shops the knowledge to construct the consumer interface. This contains each the database construction (despatched by the admin backend) and the UI customization made by the consumer.

To get extra technical, the knowledge saved contains:

  • Show & Order — Which tables and columns ought to be displayed or hidden? In what order ought to the columns seem within the ‘Desk’ view?
  • Assortment Settings (permissions) — Are the information on this desk read-only? Can they be deleted? Can they be exported in a .csv file?
  • Widget preferences — Which UI element ought to be rendered for every column (e.g a file viewer for a column that incorporates pictures urls).
  • Chart configurations — How are the dashboard charts configured and by which place ought to they seem?

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

4. Forest Admin UI server

The Forest Admin UI server shops static property. These embrace HTML paperwork, CSS stylesheets and JS script recordsdata. It offers the UI parts wanted to construct the interface that shows the information.

Now that you’ve a excessive stage overview of the structure, let’s examine how the completely different parts work together collectively.

Interactions between the completely different parts

Let’s undergo the http calls made between every of the above-mentioned parts when working a Forest Admin mission. Specifically calls made:

  • between the top consumer’s browser and the Forest Admin servers (each UI and API servers),
  • between the top consumer’s browser and the admin backend,
  • between the admin backend and the Forest Admin API servers.

Calls produced from the consumer’s browser

The next lists the calls made by the browser when an finish consumer accesses the admin panel from their browser (at app.forestadmin.com).

To the Forest Admin UI servers

Calls from the user's browser to the Forest Admin UI servers

Calls have to exit to the Forest Admin UI server to fetch static property together with:

  • HTML paperwork
  • CSS stylesheets
  • JS scripts
  • A map of the property

To the Forest Admin API servers

Calls from the user's browser to the Forest Admin API servers

Calls have to exit to the Forest Admin API servers to retrieve data relating to:

  • the top consumer logged in,
  • the mission they’re logged into,
  • the setting they’re logged into,
  • the configuration of the rendering to be displayed (i.e. the configuration of the UI),
  • the widgets configuration,
  • the billings information of the mission,
  • any updates taking place on the UI configuration. That is executed by websockets.

To the admin backend

Calls from the user's browser to the admin backend

Calls have to exit to the admin backend to retrieve/ modify information from the database together with:

  • GET calls to retrieve an inventory of information, the rely of an inventory or the main points of file,
  • PUT calls to switch a file,
  • POST calls to create a brand new file or set off a customized motion,
  • DELETE calls to delete information.

Calls produced from the admin backend

To the database

Calls made from the admin backend to the database

When calls are produced from the browser to the admin backend, the latter interprets the decision right into a database question.

To the Forest Admin API servers

Calls made from the admin backend to the forest admin api servers

With the intention to be sure that the UI displays the construction of the database, the admin backend must ship calls containing the knowledge from the forestadmin-schema.json to the Forest Admin API servers. This file is distributed upon each restart of the admin backend server.

On the startup of the admin backend and periodically afterwards, calls are additionally made to the Forest Admin API servers to retrieve permissions. This protects the information from being accessed by unauthorized customers by curl requests for instance.

Extra issues

Flexibility and extensibility

As a result of a part of the answer’s logic resides within the consumer’s techniques — the admin backend in Forest Admin’s instance, the seller can enable customers to customize and lengthen its answer like they might with some other app, by open sourcing and documenting its on-premise element.

Improvement workflow, CI/CD and internet hosting

If the seller open sources its on-premise element, it additionally permits the consumer to handle the code of this element in Git, the containerize the back-end app utilizing Docker or Kubernetes, and to deploy it wherever the consumer sees match.


With this hybrid SaaS structure, customers will profit from steady updates to the SaaS half — in Forest Admin’s case the UI — by merely refreshing they browser tab.

For the on-premise half, the draw back is that updates do require the consumer to put in updates on their facet, and probably setup checks to ensure updates don’t introduce regressions on their particular configuration.


From introducing giant updates to managing customers’ authentication to optimising for efficiency when you do not host a part of your answer, constructing Forest Admin with this hybrid SaaS structure launched numerous technical challenges of their very own, that we plan to cowl in additional detailed posts sooner or later. Ping us @ForestAdmin to tell us what you need us to cowl first.

Curiosity in Forest Admin? Be taught extra on our website or our doc, or sign up here.

Add a Comment

Your email address will not be published. Required fields are marked *