Budibase architecture
Covering the architecture that makes the Budibase platform work
Last updated
Covering the architecture that makes the Budibase platform work
Last updated
The Budibase architecture is quite simple, comprising of a few key Budibase services and a collection of open source technologies that Budibase is built on top of. Below you can see a general overview of the services that make Budibase work and how they interact.
In this section we will cover the core services that make up the Budibase self hosted platform and how this architecture fits together.
App service - this is the core of the Budibase infrastructure, the apps service hosts your web apps when they have been deployed as well as providing the REST API that your web apps will use to access/store their data.
Worker service - a small custom Budibase service which currently handles platform security, making sure users attempting to deploy have permission to do so. This service will see expansion in the future, to cover other background processes.
Database (CouchDB) - this is the primary database of Budibase, it is a NoSQL highly scalable and reliable platform which supports simple data replication and partitioning. We utilise data replication when deploying apps as well as it being particularly useful for synchronising a cluster for large scale deployments. We partition the CouchDB service into databases specific to each app, meaning we can keep data separated easily and securely.
MinIO (Object store) - it is possible to store large files in Budibase apps, as well as the apps being built on top of a specific version of the Budibase Client (the Svelte app at the core of every Budibase web app). To store these files we make use of MinIO, which works similarly to AWS S3.
Proxy (NGINX) - To simplify the deployment and usage of the Budibase platform we route all requests through a proxy engine which sits at the front of the Budibase architecture. No service is communicated with directly, this also allows us to load balance the services as the system grows if necessary.
This architecture will look the same no matter the method of self hosting, all of the above services are required for Budibase to function.
Another core element of Budibase which hasn't been discussed yet is the builder, in the Budibase architecture the builder, downloaded here, is where you will make your web apps. This is an Electron based desktop app which will communicate with the Budibase platform (Cloud or self hosted) to deploy your app once it is finished. Its comprised of two main components:
Builder svelte app - this is the interface component of the builder, when using the electron app this is the component you are interacting with.
Apps service - we run a version of the apps service in the builder, this is how you are able to preview apps and experience them as if they were deployed. The server also handles storing all of the metadata that will make up your app, we use a local offline database called PouchDB for this.
Client library - at the core of every web app you make is the Budibase client, this is a svelte app which is moulded into your app at runtime, using the information you provide in the builder.
Lastly the most important component of Budibase, the apps you make! Each Budibase app is made up of a few core libraries:
Svelte - Budibase loves Svelte and all our web apps at their core are built with Svelte.
Client library - as with the builder each Budibase app has a version of the client library that it was built with, this provides the interactivity and data connections you need for your app to function.
Component library - we want to make it easy to build consistent web apps quickly, for this reason we provide a core set of components that apps can be built out of - this is included in your app.
Hopefully this overview has explained a bit about how the Budibase platform works, from the builder to your deployed web apps.
