cherrybomb VS bonsaidb

Standard library does not provide all solutions for Error Handling.. In fact, different errors may be returned by the same function, making it increasingly difficult to handle them precisely. Personal anecdote, in our company we developed Cherrybomb an API security tool written in Rust, and we need to re-write a good part of it to have a better errors handling.

Cherrybomb is a CLI tool that helps you avoid undefined user behavior by auditing your API specifications, validating them, and running API security tests.

If you're looking for a new way to understand and manage your API, consider using OpenAPI, and if you want to secure it consider using CherryBomb to automate your security test. Managing and Testing it's the key,now your can keep your API safe :)

You can find the code on GitHub: https://github.com/blst-security/cherrybomb

API validation is an important part of developing and releasing a new API. It helps to ensure that the API behaves as expected and that it meets all the requirements of its users. Validating an API can be made easier with automated testing tools and CI/CD integrated validation 💡 tools, but it can also be done by hand.

You can learn more about Cherrybomb and how it can help you over at its repository.

I believe that Cherrybomb will make it simpler for developers to construct application programming interfaces (APIs) that are standardized, well-documented, and straightforward to implement. We have high hopes that Cherrybomb will emerge as the industry standard for application programming interface (API) development.

I do have ideas in the issue tracker on some of the next steps towards an actual migration system.

What about https://github.com/khonsulabs/bonsaidb? Progress seems stall since last summer but very cool project

There is Nebari which is the KV part of BonsaiDB I've used both successfully (and that is currently in production)

In BonsaiDb, I define entire test suites as macros. This crate has a common trait that has multiple implementations in different crates. Each implementation needs to be tested thoroughly. For cargo test to be able to work in each crate independently, I needed to have the #[test]-annotated functions in the crate being built. By using a macro, I can define the functions in one location and invoke the macro in each crate to import the test suite into that crate.

hey, just letting you know that there already is a project called bonsai-db and some people might confuse bonsai-bt as part of that project

I'm finishing up a large refactor of BonsaiDb which will add support for using BonsaiDb in non-async code.

I'm working on a major refactoring of BonsaiDb, aiming to improve the design of several interrelated features. While it started by aiming to enable a non-async interface for BonsaiDb, I realized mid-refactor that another major refactor would be better to do simultaneously rather than separately. Thank goodness that refactoring in Rust is such a wonderful experience!

It depends on what you mean by "support graphs". If you mean support the abillity to build a GraphQL interface in front of it, yes that is already possible in a limited fashion, although there are no first-class relationship types yet.

I'm trying to release the first alpha of BonsaiDb. I'm wrapping up replacing OPAQUE with Argon2, in an effort to make upgrading less likely to cause issues in the future (given that OPAQUE is still a draft protocol). I still love OPAQUE and will bring it back in the future.