Umbrella: rustic_core - road to v1

[simonsan]

Target group

Persona 11: Aisha - The Integrative Developer

• Age: 28
• Background: Software Developer at a mid-sized tech company
• Tech-savviness: Advanced
• Needs: Robust and reliable library, clear documentation, integration examples, extensive customization.
• Pain Points: poor documentation, integration conflicts, performance issues.
• Goals: Aims to develop scalable and feature-rich applications. Seeks reliable and efficient external libraries to enhance her software's capabilities without reinventing the wheel.

Requirements

1. Documentation Clarity

   • The backup solution library should have clear and comprehensive documentation. This will enable developers like Aisha to integrate the library seamlessly.

2. Error Handling

   • The library should be designed with robust error handling and should provide descriptive error messages. This aids developers in diagnosing integration or functionality issues.

Tracking

A few things that I think we should take care of, before we can stabilize rustic_core:

1. ergonomic error handling and dealing with warnings
   • Remove unnecessary unwrap/expect from codebase and improve error handling #140
2. don't use logging in library part
   • Replace logging with error handling, there shouldn't be error! anywhere in the API of the library, they should be actual errors
   • info!/warn! we should think about handling somehow different and only use, when someone uses rustic_core with the logging feature enabled
3. robust and reliable library: increasing test coverage a bit for exposed items in the API
4. some benchmarks
5. clear and comprehensive API documentation (e.g., documenting fallible functions/methods in API)
   • Refactor rustic_core API & add more documentation to rustic_core rustic#787
   • document errors in fallible functions and methods
   • fully document methods and functions in public API

[Scandiravian]

As I mentioned in #26, I had some ideas for adding integration tests to the project and I would like to hear if that would be something that would help with point 3.

My idea is to implement a set of generic set of test functions that are run against each backend covering the public functions of the library, then run these for each backend to ensure full coverage.

A main goal for me would be that the tests can be run locally, since running against cloud services always cause a tonne of issues (in my experience at least). This would be pretty simple for the local backends, since they don't have any external dependencies.

For backends such as S3, REST, and potentially rclone, this obviously requires spinning up dependencies locally. Personally I really like nix for integration tests, but it requires knowledge of the nix language to maintain, so alternatively something like docker/docker-compose might be a better fit.

If this is a direction you want to go, I can write a more thorough design in a separate issue and probably find time to implement it in November.