The release of Qobrix v31.7.0 packs a number of new features: Content Management System (CMS), API versioning, and an improved Robo setup via QoboRobo. Let’s look at each one of these in a bit more detail.
Content Management System (CMS)
Content Management System (CMS) is an important part of many web applications. The functionality and ease of use varies greatly between them, depending on how simple or complex the requirements are. There are many web applications which provide nothing more but a CMS on its own (think WordPress). There are many that embed CMS functionality and wrap with additional features. With Qobrix, we have provided the CMS functionality as our Intranet product for quite some time.
But after listening to a lot of feedback, and being involved in a few more projects, we realized that CMS functionality is useful in a more generic way. So, today, we are merging most of our Intranet functionality, specifically all the features around the content management – Sites, Categories, Articles, CMS, and advanced Dashboard widgets – into the base of the Qobrix platform. Simply speaking, this means that all Qobrix products, projects, and offerings, will include the Intranet and CMS functionality in them!
The CMS features are quite mature and have been used in a number of scenarios already. But now that these are available in more generic setups, we’ll be releasing a few enhancements and improvements to the CMS and Intranet functionality in the next few versions. For now though, get your upgrades and start playing around with it. You can already setup Sites in your Qobrix application and start publishing content. Let us know what you think!
Qobrix provided REST/JSON API from day one (day zero, to be precise), in order to help Qobrix application developers and system integrators to connect Qobrix to a variety of other systems and services. Qobrix API has been evolving ever since. But sometimes, evolution is not enough, and a revolution is needed. Making drastic changes to the API, however, is difficult due to third-party users and backward compatibility.
Today, we are releasing something that has been on our road map for quite some time – API versioning. When working with Qobrix API now, a developer or an integrator can specify which specific version of the API he wants to use. Instead of the generic “/api/” prefix in API-related requests, it is possible now to use “/api/v1.0/“, which locks the integration to API v1.0.
As you might have noticed, the versioning schema is not following the Semantic Versioning. This is for a reason. After much researching and consideration, we decided that Semantic Versioning will be too much of an overhead for the API. After all, API is not supposed to change all that often. Our API version numbers consist of two parts. The first number indicates the major release. These work similar to Semantic Versioning – any time backward compatibility breaks, we will increase the major version number. Whether it’s caused by parameters or by a completely different implementation (GraphQL anyone?). The second number indicates a minor change. For this, we will deviate slightly from the Semantic Versioning concept. We reserved the minor number for the customer and project specific changes. So, the API v1.5 of one project and v1.5 of another project, might have some differences, but the overall underlying versioning will be the same for both – both are spanning of the major version v1.0.
The introduction of the API versioning presents its own backward compatibility challenges. After all, how should the system treat older requests, which do not specify the version? Backward compatibility is important for Qobrix, so our solution to the problem is to fallback to v1.0 for this migration and then to use explicit versions in the API requests. This means that all existing applications that work with Qobrix API will continue to work as they are. But we strongly encourage Qobrix application developers and system integrators to switch to the new URLs, which define which version of the API they want to use. This makes things future proof, and provides an additional context which is helpful during the logging and debugging.
Last, but not least, of the improvements that Qobrix v31.7.0 brings, is the change to our Robo-based setup for build and deployment. Instead of having the build and deployment within the application itself, we have extracted it into a separate, standalone project. World, meat QoboRobo, and its assistant QoboRobo CakePHP. These are the early days for both projects, of course. But we are confident that our build and deployment magic can help other people in the Open Source Software community, and that in return, we will benefit from the community contributions, such as new features, bug reports and fixes, and documentation improvements.
Separating the build and deployment into standalone projects also means that these parts of the infrastructure can evolve on their own, and maybe even at a faster rate, bring more and better tools back to Qobrix without all the merging complexity and maintenance overheads.