idlab-discover / obelisk

Obelisk is a service platform for building scalable data-driven applications and services, connecting data producers and consumers with powerful APIs for ingesting, querying and streaming large amounts of data in an organized and secure way.
https://obelisk.ilabt.imec.be/docs/
Apache License 2.0
6 stars 0 forks source link
catalog iot iot-platform time-series

Obelisk Main Project

Monorepo for all things related to Obelisk Definitive Edition.

Repository structure

Versioning strategy

calver-YY

We are applying the Calendar Versioning or CalVer scheme, with a single version number for all core Obelisk artifacts built during the same release cycle: Maven artifacts, Typescript modules, Docker images, Helm Charts, etc... The public API for Obelisk follows a different versioning scheme (see Backwards compatibility).

Rationale?

Backwards compatibility

As opposed to when using a SemVer strategy, the version number no longer conveys information on when backwards compatibility was broken. That is why we will be introducing an additional api-level version (e.g. v3 currently) that only applies when calling the Obelisk HTTP API (the only place it matters, as this is our only external facing API). By specifying this api-level using an HTTP Header, users can select which of the available APIs to target.

We can have aliases for api-levels such as stable (last stable api-level) or latest (newest api-level) as a usability feature. When the client does not specify an api-level, we could default to stable.\ \ Recommendation: Long running applications should always specify a specific api-level (e.g. v3 ) to ensure that the same API can be used, even when Obelisk promotes a new stable API, for as long as the specified api-level is supported!

Collaboration conventions

Maven multi-module project

All Java and Kotlin code should be part of the Maven multi-module project obelisk-parent (see pom.xml at root level).

Please respect the following naming conventions for the modules belonging to this parent:

Module Name Prefix Description Module Root Package Module Java module Name
lib- For library modules that are used as dependencies in other modules. Library modules are never executed directly. idlab.obelisk.[name] lib.[name]
int- For modules that implement a Microservice that has no public interface (e.g. internal data processing pipeline). idlab.obelisk.services.internal.[name] internal.[name]
pub- For modules that implement a Microservice with a public interface (e.g. HTTP API services). idlab.obelisk.services.pub.[name] pub.[name]
plugin- For modules that implement one of the factory interfaces of the Obelisk API (see lib-definitions). Plugin modules are used as dependencies in Microservice modules, similar to lib- modules, but are meant to be swappable. idlab.obelisk.plugins.[pluginType].[name] plugin.[pluginType].[name]

Additional fixed prefixes could be used for non-Maven projects (e.g. web- for web applications).

External dependencies that are used in multiple modules (e.g. Vertx) should be declared in the pom.xml at root level, so that they can be used in the child modules without the need for specifying a version (with the goal of using consistent versions across modules).

Docker-compose info

Useful info