Release 0.1

today

This is the first experimental release of the Quinimbus Framework. There will be some rough edges and parts to optimize, you will also find missing parts and a lacking documentation, but you can do your first experiments now. So why should you do so? What even is Quinimbus?

What is Quinimbus?

In short, Quinimbus is a modular framework for fast creation of a backend service. For the easiest use case you only have to define a data model in form of Java Records, the framework will do the rest for you. You will automatically get a complete backend application containing Persistence, a Rest API, an administration web application, and even Dockerfiles to create Images for the deployment. But Quinimbus is modular, you can replace every part of it as you like. You want another persistence solution? By default MongoDB is supported for now, but it is no rocket science to create another adapter. You want to write your own API endpoints? You can extend the existing ones or even write your Rest API completely custom. You want to use Spring Boot instead of the default Quarkus? Even this would be possible in the future. Technically it should be even possible to to use Kotlin data classes to define the domain model. And the other way around you can also use just parts of Quinimbus in your own custom application.

How do I start?

The easiest way to get started is using the CLI. That way you can quickstart your project with one command, build it with a second and use a third to run it locally and build docker images for deployment, see Getting Started for detailed instructions.

What is the current state?

The following four modules are the most advanced ones right now, and the most important to start your project.

Persistence

Currently, just MongoDB as storage provider is implemented. There is support for a in memory provider, but this is intended for easy testing only. There is a good amount of field types supported already, each usables also as lists, sets or maps. Limited support for migrations, weak entities and first lifecycle events are implemented, too.

Binary

For saving binary data, just a directory based provider is implemented right now. There is already support for using binaries as fields in entities.

Rest

A complete CRUD API is generated for each entity, any field type should be supported, even binaries. You can also implement mappers for creating special views on your data model, also searching by specific fields is possible.

Admin UI

The admin UI just has a data table for each entity and a dialog for creating and editing at the moment. The supported list of field types is limited still. There is no proper support for weak entities, yet.

What are the next steps?

It is planned to release a new experimental release about every two months with new features and improvements. Bugfixes could happen in between if needed. Some key points to be worked on and hopefully released for 0.2 are:

• Authorization support using OAuth 2.0 in the Rest API and admin UI
• Generation of OpenAPI documentation of the generated API
• Support of more field types in the admin UI
• Thumbnail API for binary fields
• Generation of Unit- and Integrationtests of the generated code
• Auto-update command in the CLI for updating the CLI itself and to update your projects to new releases of Quinimbus
• More documentation on this website and in form of Javadoc
• Upgrade from JDK 21 to 23 for Markdown Javadoc support

There is no plan yet when a 1.0 release will happen or what even will be part of a 1.0 release. Have you an opinion what is strictly needed for a production release? Create a feature request at GitHub in the specific modules repository!