In order to not have to reproduce the same logic in a Python-based backend for clients, which is currently done in OTELib, it would be nice to separate out the logic that's happening in the endpoint functions to an importable library/package.
I suggest the following steps to achieve this:
- Separate out the logic from the endpoint functions into a separate top-module's/package's functions in this repository.
- Move the top-module to OTEAPI Core as a new main sub-module.
The latter should also make it possible to more easily generate testing fixtures and hooks for OTEAPI plugins directly importable from the OTEAPI Core package - a package all the plugins already depend on.
Note, this should not change the perceived functionality of the REST API.
Finally, the Python-backend in OTELib can be updated eventually, also providing no noticeable user differences in functionality here, but for both this repository as well as OTELib, the developer experience should greatly improve.
In order to not have to reproduce the same logic in a Python-based backend for clients, which is currently done in OTELib, it would be nice to separate out the logic that's happening in the endpoint functions to an importable library/package.
I suggest the following steps to achieve this:
The latter should also make it possible to more easily generate testing fixtures and hooks for OTEAPI plugins directly importable from the OTEAPI Core package - a package all the plugins already depend on.
Note, this should not change the perceived functionality of the REST API.
Finally, the Python-backend in OTELib can be updated eventually, also providing no noticeable user differences in functionality here, but for both this repository as well as OTELib, the developer experience should greatly improve.