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.

The open source blocks always allowed this, but using the new development server, your workflow is simplified dramatically. No need to re-publish modified blocks all the time. Just to try them out in your app instantly.

To get started right away, here are the instructions. Read on for more details.

The development server can create an app from a specified folder containing an app-definition.yml
file. It will check what blocks are needed for the app and will try to load them from the local
workspaces, listed in the package.json file in the root of the project, if they are present. This
way, all default Appsemble blocks shipped with Appsemble are loaded automatically.

Once the development server is started, making a change to a block’s code or styles will reflect in
the browser immediately after refreshing the page, without the need of increasing the block’s
version. Running docker database containers, creating a user account and creating an organization
are not needed.

App resources will be stored locally in the /packages/cli/data.json file. App assets and block
assets will be served from the local file system.

Future roadmap

One of the upcoming features for the development server will be hot reloading. More on what’s planned, see the epic.

Demo videos

Starting the development server:

Changing a block has immediate effect in your app:

Fetching remote blocks:

The post The development server is here first appeared on Appsemble.

The post Side job / student assistant software engineering first appeared on Appsemble.

Apps are defined using YAML. Apps consist of pages that are composed using blocks to provide them with content and interactivity. It’s built using TypeScript, Node.js and React.

As a team member you will work extending the core Appsemble platform and write new blocks as well as developer documentation for other developers building blocks. You’ll work with team members who are building apps on behalf of clients, you’ll help them by adding functionality to the platform to realize the apps envisioned. Our goal is to enhance the platform, so users can build their own apps without our help, and we can focus on improving the platform and user experience for app builders.

You…

• are communicative
• have autonomy
• are helpful (participation in the community)
• have experience with JavaScript / Node.js / TypeScript / React / PostgreSQL

Not sure if you meet these qualifications? Let’s talk on how to get you to that level.

Got some of these skills? Even better

• Preact
• PWA
• OpenAPI
• DevOps
• Kubernetes
• Helm

What do we offer in return?

• Laptop
• 25 vacation days per year
• Holiday allowance
• Flexible working hours
• Work remotely or at the office in Eindhoven, The Netherlands.
• And of course, the ability to work on open source.

Are you interested in this position?
Are you interested or do you want more information?
Do not hesitate to email us at support@appsemble.com or join our Discord server at https://discord.gg/XbSRraC.

The post Vacancy: fullstack webdeveloper first appeared on Appsemble.