skip to main content

Livebase Overview

In this overview we look at the key concepts around the model, Livebase Cloudlets, and the model-generate-maintain cycle.

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 Model #

Developing an application with Livebase means making a “special” UML class diagram, which is called a model. 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.

Example diagram

A Livebase model.

In the model, 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 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 .

![Schemas gif](/assets/img/tutorial/1_livebase-overview/schemas_example.gif ‘The ‘transparent layers’ representation, enhances the readability of the model, promotes separation of interests, and allows the developer to navigate the hierarchy of information with the feeling of basically looking at the same diagram all the time.’)

Partitioning: Database Schema

The Database Schema is the heart of the model. It instructs Livebase on how to generate the relational database, describing its conceptual structure in terms of classes, attributes, relationships, integrity constraints and data domain restrictions. The Database Schema is unique and all other levels of the hierarchy depend on it.

Partitioning: Application Schema

The Application Schemas allow you to perform the partitioning of the database. Each of them manages a subdomain of the model, i.e. a selection of classes, attributes and relations; in the resulting application view, the rest of the model is completely obscured and inaccessible, as if it did not exist. You can also define filters to exclude certain objects from the view and further restrict the portion of the database you manage. Application schemas also describe the look and feel of the user interface and data representation.

Partitioning: Profile Schema

The Profile Schema describe the grant (rights) that users with that profile have in the system. A profile may or may not be enabled to access a set of application views, and for each view/Application schema it is possible to specify read and edit rights on objects made accessible by the view. The schema that allows these rights to be configured for the profile-application view pair is called the Permission Schema . A profile can also be enabled for general aspects, such as system configuration or user management.

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 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 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 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.

Livebase Designer

The Livebase Designer

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 models. This is especially important when maintaining existing 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 web client (based on GWT framework) pre-configured with the interface customizations defined in the model;
  • a traditional API REST and a API GraphQL mapped to the model elements;
  • a library of Java development interfaces mapped to the 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 the client and interfaces; most of these resources are protected and require authentication.

The Client #

The web client that comes with Livebase applications is meant to be a corporate back-office; it can be used by administrators and internal staff to manage their data and/or get useful information about it, thanks to powerful exploration tools like the Livetable. In the course we’ll delve into the client and these tools, and use them to test how well the modeled requirements actually work.

APIs and Plugins #

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

Cloudlet Stack

The Cloudlet API allows access to the application without going through the graph client. This allows the Cloudlet to interface with other systems outside the organization, and makes it possible to build custom web clients to be included among the Livebase application resources.

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 templates and Cloudlets. From here we can open the Designer to view, create or edit models; we can also manage the entire Cloudlet lifecycle: creation, start/stop and tear down.

Dashboard Livebase

The Livebase Dashboard.

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 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 a template in the library;
  2. create a Cloudlet;
  3. drag the template onto the Cloudlet to install it;
  4. start the Cloudlet.

Cloudlet creation

Creating a Livebase application

Livebase generates the entire application stack described above each time the Cloudlet is started with a new 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 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:

Cloudlet-management

Livebase application development cycle

  1. When a template/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.