Livebase – Your Low-code highway to composable back-ends

Livebase is a low-code tool specialized in the generation of rich back-ends able to enforce complex business logic following a pure model-driven approach.

Indeed, given a UML-like domain model, Livebase generates a complete GraphQL API paired with a relational database to enable the query and manipulation of the application data via GraphQL API calls, always making sure that the data is compliant with all the constraints defined in the model.

In this tool review, we take a closer look at Livebase and what it brings to the data modeling / low-code community.

Modeling the data and all the business rules

Once you download the desktop Livebase modeling editor, you can start defining the three main perspectives of your application:

• The database schema, the core model for your system and the one that will drive the creation of the database (using standard UML-to-relational databases mappings) to store all your data
• The application schema, a view of the database one to filter out parts of the database schema that are not relevant for a given application.
• The permission schema to define what user roles can have access to what elements of the application schema.

No surprise, the database schema is the most important one. The modeling language is similar to UML but with some restrictions, for instance, there is no inheritance. But the most innovative part is the strong support they offer to define all types of derived elements and business rules on top of the data model.

For simple constraints (like unique, required,…) you have a specific option to mark one or more attributes as such, which makes very easy to define these common constraints. There is even a graphical annotation on the model to identify them, see, for instance, the exclamation mark denoting required fields in this Livebase designer screenshot

But you can define many other types of arbitrary constraints that involve a number of predefined math formulas and path navigation to query related objects. Similar to what you can do with OCL and its navigation expressions. On the one hand, it’s less expressive than OCL but on the other it offers a lot of predefined operations and environment variables (such as the current date) which are not part of the OCL standard, and that enable to manipulate date and numeric objects, including aggregation operations (another missing aspect of OCL). See for instance how to add a derived attribute showing the age of an employee based on the date of birth and the current date.

Another aspect I found especially interesting is that you can check the constraints at the data level or at the application level. Constraints at the data level are enforced on all applications manipulating that data. Constraints at the application level are enforced for that application only, giving you the flexibility to check the constraints in the best possible layer. Even if the constraints at the database level are less powerful (in the sense that you can only define simpler types of ocnstraints, such as attribute domain ranges, unique, multiplicty constraints,…), I love having this flexibility. At the application level, you have the full power of the constraint language including predicates allowing/denying CRUD operations, filters preventing objects from being retrieved, filters preventing associations between objects, etc. It’s also worth noting that such predicates can be defined using not just native attributes but also derived ones.

Running the modeled application

Livebase falls more into the code-generation field. But instead of just giving you generated code and saying that deploying that it’s up to you, it tries to combine the best of both worlds (model interpretation and code-generation) via the concept of Cloudlet.

A Cloudlet is a self-contained virtual server that embeds the full stack to run the application backend (the database, the APIs, the Java engine to run the logic,…). Cloudlets can be automatically deployed for you in an AWS infrastructure and accessible via a URL in a transparent way as we see in more classical model interpretation approaches.

As part of the generation you also get a CRUD-like scaffolding interface (similar to what many programming frameworks, e.g. Django) offer

Who is this tool for?

Livebase is a very interesting alternative for enterprises looking to build powerful backends with the guarantee that the data managed via those backends will be correct. Then, a number of different front-ends could be built attacking that same backend without having to keep in mind all the business constraints.

The pricing is also competitive, especially considering that it’s based on the complexity of the application but not on the number of users, as other vendors do and that has the potential to increase a lot the costs for application that become successful. There is no free plan but you can of course try the tool for free.

Another factor to keep in mind is its GraphQL orientation. While this decision is well-explained, it could be a problem for companies globally following a REST-like strategy. Maybe offering a REST API access could be something Livebase could explore in the future. Maybe even an AsyncAPI one.

Note that while Livebase focuses on the backend and therefore, in principle, you need to code yourself the front-end (making Livebase a low-code tool but not a no-code one), you also get a basic scaffolding front-end (see above). I think it would be interesting for Livebase to explore more this path and consider offering a richer default GUI. Given how powerful is its backend, I think an easy-to-use GUI would be enough for many scenarios, broadening the user base of the tool.

So, if you, like me, consider data/business models as key asset of your organization, on top of which build the rest of your software infrastructure, give livebase a try!