Livebase Overview

Livebase is a low-code development platform that offers powerful modeling, code generation and lifecycle management tools to build management database applications from scratch easily, quickly and securely.

The Engine #

Developing an application with Livebase means making a “special” UML class diagram, which is called a engine. It is a conceptual diagram that describes the business logic of the application on different levels of abstraction, and that is translated by Livebase not only into a database, but also into all the application logic involved in reading and writing the represented data.

In the engine, everything revolves around the data: classes, attributes, and relationships define the structure of the data, while other aspects - such as forms - define the representation of the data, and still others define permissions on the data. Since it would be complicated to represent all this information at the same time, the engine model has several transparent views, called schemas;

each schema allows the modeler to focus on a specific aspect of the application, without ever losing sight of the class diagram.

Schemas #

The most important schemas are of three types: Database Schema , Application Schema and Profile Schema .

By default, only one Application Schema (Application) with all classes enabled, and two Profile schemas are defined in the new models: Member and Guest; since there is no partitioning, users have access to the entire engine model with full read and write rights.

Other schemas that we do not cover in the tutorial are the following:

• Localization Schema : defines the localization strings of all the engine model elements with respect to a supported language. At the moment the supported languages are Italian and English .
• Report Schema : defines a template to generate various types of reports (tabular, cross-field, etc.) on the engine model data.

The Designer #

The Designer is Livebase’s modeling environment; we’ll use it to build classes and relationships and navigate the schema hierarchy.

At all times, the Designer monitors every change the modeler makes and evaluates their repercussions in the schema hierarchy; therefore, it is virtually impossible to draw inconsistent engine models. This is especially important when maintaining existing engine models.

The Designer is a tool included in the Dashboard, which we will see shortly. By the end of the course we will have explored most of its tools and functions.

Generated application and Cloudlet #

Starting from the model, Livebase automatically generates all the application stack necessary for the correct functioning of the system, without requiring any further configuration. In detail, the result of the modeling is:

• a relational database (MariaDB), properly normalized and optimized;
• an application engine (in Java language) equipped with services of reading and writing on the database, authentication, management of users and concurrency, application views, logging, etc.;
• a traditional API REST and a API GraphQL mapped to the engine model elements;
• a library of Java development interfaces mapped to the engine model elements to implement Plugins.

All of this stack - including the database - resides in a self-contained virtual server called a Cloudlet. A Cloudlet is a multi-user system with a URL address, allowing access to its interfaces; most of these resources are protected and require authentication.

APIs and Plugins #

The API generated by the system are two: REST and GraphQL; both are mapped to the resources declared in the engine model, and allow (after authentication) to query the generated application to read and write data, with the same policies modeled in the Profile Schema. In particular, the API GraphQL provides a strongly typed query language to satisfy complex queries in a flexible manner.

Instead, the Plugins are custom extensions of application logic. Developers can use the generated libraries to write Plugins and hook them into the application engine; these extensions are invoked during the execution of some known operations (such as when saving an object), and allow to execute arbitrary code exploiting the application execution context (such as objects in memory, open database connections) or other services offered by the application engine framework.

The Dashboard #

The Dashboard is the administration environment for engine models and Cloudlets. From here we can open the Designer to view, create or edit the engine models; we can also manage the entire Cloudlet lifecycle: creation, start/stop and tear down.

In the Dashboard, the owner of a Cloudlet can:

• manage members, create new ones and assign them user profiles to access the generated application;
• manage the resources to be assigned to his Cloudlets (database or file storage size, bandwidth, etc.) from the resource pool available for his plan;
• manage the current database and engine model.

By default, Livebase automatically deploys new Cloudlets on our cloud hosting; Cloudlets deployed in this way already have a public URL available, in the format <ServerNumber>.fhoster.com/<AccountName>/<CloudletName>, where <AccountName> is the username of the Cloudlet’s owner account.

Livebase Workflow #

To create a Livebase application from scratch, simply:

1. create an engine model in the library;
2. create a Cloudlet;
3. drag the engine model onto the Cloudlet to install it;
4. start the Cloudlet.

Livebase generates the entire application stack described above each time the Cloudlet is started with a new engine model. If no database is present, it too is created from scratch. Once the code is generated on first startup, the Cloudlet can be stopped and restarted more quickly.

Development Cycle #

At any time, a running Cloudlet can be stopped and its engine can be replaced with another engine model or updated by modifying it in the Designer. This operation is called evolutionary maintenance and makes it possible to make changes to an existing Livebase application while minimizing the risk of losing data stored in the pre-existing database.

Livebase application development is therefore a cycle consisting of three phases: modeling, alignment and regeneration:

1. When a engine installed on a Cloudlet is opened and edited in the Designer, Livebase checks the changes made by the user taking into account the current structure of the database and the data stored in it.

2. When the user saves the changes, Livebase develops an action plan to update the database and application by identifying and cataloging any misalignments with the existing data and database structure:

   • if they are low impact changes (low issue), you can restart Cloudlet without any problems;
   • in the presence of misalignments that would result in loss of information (medium issue), Livebase asks the user to review the changes and give explicit confirmation before proceeding;
   • in the case of even more serious issues (high issue) that cannot be resolved automatically and would render pre-existing data inconsistent, Livebase prevents starting the Cloudlet and forces the user to manually resolve errors on the Designer.

3. Once the alignment with the database is complete, you can restart the Cloudlet. At this point, all parts of the application affected by the changes are regenerated.

Throughout the course, we will perform numerous evolutionary maintenance tasks and address all the different scenarios we have listed.

In the next lesson… #

We describe the requirements of the management system that will drive the modeling: Example scenario.