Open CFIALeronB opened 9 months ago
related subject? being able to have multiple versions running:
@k-allagbe should comment on the design choices here
@k-allagbe should comment on the design choices here
I haven't explored the API versioning topic very well yet. My first reaction would be to use blueprints
to implement versions. But maintaining features across the blueprints could become cumbersome.
I'm not too sure about flask_version
. The last commit on it dates 2020 and it doesn't seem to be maintained by a lot of people.
I like the flask-rebar
extension not only for the versioning, but also because it integrates swagger already.
Pros:
Cons:
Pros:
Cons:
I'm not sure if flask-rebar
works with quart
. But if this backend will grow a lot, we should probably consider flask-rebar
. Otherwise, blueprints
can satisfy our needs for versioning for now.
@k-allagbe good review, thanks.
For now I'd lean towards the simpler solution, which is just using blueprints to give us time to carefully consider major changes such as switching .
This example demonstrates what we want I think:
https://gist.github.com/berend/fb8fd98be235aec7c6d12782805d7bff
My concern was mainly making sure that if version 1.1.0 is basically the same as version 1.2 except for a few, non-API breaking additions to the API that we are able to reuse these changes.
in the case of breaking changes (a major version bump, such as going from 1.2 to 2.0.0) we can clearly have label for the function that changes.
It is perhaps "cumbersome" but it may also be the cost of change management.
Description
To ensure consistency and compatibility between our frontend and backend services, we need to implement a 'version' endpoint in the Nachet Backend. This endpoint will provide version information, including the application version, name, Git commit hash, and long Git version, similar to what is currently available in the Nachet frontend.
Requirements
/api/version
).applicationVersion
: The current version of the application (frompackage.json
).applicationName
: The name of the application (frompackage.json
).gitCommitHash
: The short Git commit hash of the current deployment.longGitVersion
: A combined string of the application version and commit hash (e.g.,0.1.0-f0db6e8
).Purpose
This endpoint will allow the frontend to display the backend version information, ensuring that both frontend and backend are running compatible versions. It will be particularly useful for troubleshooting and verifying deployments.
Implementation Notes
Acceptance Criteria
/api/version
is implemented in the Nachet Backend.