Appsemble in its current form is what you would call a monolith. We have one big server, which connects to a single database and exposes an Application Programming Interface (API). This self-contained unit can be deployed as one whole.

We have the Appsemble Studio, which serves as a central point for app development and management. Apps are served on their own domain, but they are still served from the Appsemble Server and use it to get their data.

Once an Appsemble App is published, its structure is stored in the database as an app definition, which is parsed on the client to fetch the needed Appsemble Blocks from the Appsemble Server and display them on the screen when a user visits an app.

App Data

App data comes in two forms – Resources (structured app data) and Assets (files).

Assets are stored as binary data directly in the database, using PostgreSQL’s BLOB column type. When an asset is fetched from within an app, it is being loaded in memory on the Appsemble Server and then returned to the client at once, not utilizing any streaming techniques. This puts heavy load on the main Appsemble Server.

Resources are currently stored as JSON objects in the database, using PostgreSQL’s JSONB column type. The structure of resources and the connections between them is defined in the app definition. We are not utilizing the relational capabilities of our database to enforce field type constraints and foreign key constraints – that is all done programmatically on the Appsemble Server. This also makes it difficult and inefficient to query paginated resource data and search it at the same time.

Data for all published Appsemble Apps is stored in the same main database, meaning that there is no isolation of data per app.

How we plan to improve things

While the current setup works and has been sufficient for a while, there are a lot of potential improvements that can be made. In 2025 we are planning to improve the architecture of the Appsemble platform as a whole, aiming at isolation of data and performance improvements. This is a big topic that should be tackled incrementally. The steps towards that, as a general plan, are as follows:

Better Asset Storage

We are planning to introduce support for S3 file storage so we can utilize streaming capabilities and image and video compression/decompression, reducing the load on the main Appsemble Server in the process https://gitlab.com/appsemble/appsemble/-/issues/1722 [upd Feb 2025: done]

Utilize Relational Databases for App Resources

Each resource type in an app should have its own table. Tables can be created dynamically, based on the resource definitions in the app definition. This will allow us to efficiently apply field and relational constraints on resources and perform more optimized queries. https://gitlab.com/appsemble/appsemble/-/issues/1731, https://gitlab.com/appsemble/appsemble/-/issues/1496

Dedicated App Databases

We want to isolate data for different apps from one another. https://gitlab.com/appsemble/appsemble/-/issues/1629 [upd June 2025: done]. We are also considering shared databases for groups of related apps, that need to share data between each other. Each app would be configurable to connect to an Appsemble hosted database or an external database via a database connection string.

Dedicated App Server and API

The idea is for each app to have its own App Server, which would be separate from the main Appsemble Server and will connect to its own database.

Standalone App Deployments

The idea is, when an app is being published, to bundle all app related code (Appsemble Blocks, generic UI code) in a self-contained static bundle, that can be served on its own, for example in a Kubernetes pod. This should reduce the load on the main Appsemble Server and will enable each app to be independently scalable based on the load on it. https://gitlab.com/appsemble/appsemble/-/issues/1628

You can track the progress in the linked GitLab issues.

The post Appsemble Architecture Changes In 2025 first appeared on Appsemble.