Issue: Create 'Version' Endpoint in Nachet Backend

[CFIALeronB]

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

• The endpoint should be accessible via a simple GET request (e.g., /api/version).
• It should return a JSON object containing:
  • applicationVersion: The current version of the application (from package.json).
  • applicationName: The name of the application (from package.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

• The backend should dynamically retrieve version and Git information during runtime, rather than hardcoding these values.
• Consider using build scripts or CI/CD pipelines to inject the Git commit hash and other relevant information into the backend environment.

Acceptance Criteria

• A new endpoint /api/version is implemented in the Nachet Backend.
• The endpoint returns accurate and up-to-date version information.
• The frontend can successfully retrieve and display this information to verify compatibility with the backend.

[rngadam]

related subject? being able to have multiple versions running:

https://github.com/itay-bardugo/flask_version

[rngadam]

also:

https://flask-rebar.readthedocs.io/en/latest/quickstart/api_versioning.html

[rngadam]

@k-allagbe should comment on the design choices here

[k-allagbe]

@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.

Quick comparison: blueprints vs. flask-rebar

Blueprints

Pros:

1. Flexibility: Blueprints are highly flexible and seamlessly integrate with Flask.
2. Simplicity: Easy to set up for versioning, using version prefixes in URLs.
3. Organizational Clarity: Ideal for structuring large applications into distinct sections.

Cons:

1. Manual Management: Requires handling request validation, serialization, and documentation manually.
2. Less Feature-Rich for APIs: Blueprints alone don’t offer specific RESTful API development features like automatic schema validation or documentation.

Flask-Rebar

Pros:

1. Built for APIs: Specifically designed for RESTful API development, offering features like API versioning, marshalling, validation, and auto documentation (Swagger).
2. Schema Validation: Integrated request and response schema validation using Marshmallow.

Cons:

1. Additional Dependency: Introduces an external dependency to the project.
2. Less Flexibility in Routing: Might offer less flexibility than Blueprints for certain routing requirements.

My Opinion:

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.

[rngadam]

@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.