-
Notifications
You must be signed in to change notification settings - Fork 21
[PM-23252] SDK crate restructure #699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
|
Great job! No new security vulnerabilities introduced in this pull request |
This comment was marked as outdated.
This comment was marked as outdated.
Deploying contributing-docs with
|
| Latest commit: |
f895956
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://52edc1e2.contributing-docs.pages.dev |
| Branch Preview URL: | https://platform-pm-23252-sdk-crate.contributing-docs.pages.dev |
This comment was marked as outdated.
This comment was marked as outdated.
|
Claude finished @dereknance's task —— View job PR Review: SDK Crate Restructure DocumentationTodo List:
Review SummaryThis PR successfully updates the SDK architecture documentation to reflect the new crate structure. The changes provide clear explanations of the architectural improvements and maintain excellent documentation quality. ✅ Strengths
📝 Minor Issues Identifieddocs/architecture/sdk/index.md:182-184Code example inconsistency: impl GeneratorClientExt for Client {
fn generator(&self) -> GeneratorClient {
GeneratorClient::new(self.clone()) // Issue: unnecessary clone
}
}
🎨 Enhancement Suggestions
🔍 Technical Validation
📋 Compliance with Repository Guidelines
📊 Overall AssessmentThis documentation update significantly improves understanding of the SDK's new crate structure. The visual diagrams are particularly effective at communicating the architectural improvements from the previous complex dependency structure to the cleaner hierarchical approach. The addition of the decision tree for adding functionality provides valuable practical guidance for developers. The content successfully serves both internal developers and external contributors by clearly explaining the rationale behind the restructure and providing concrete guidance on when and how to add functionality to the SDK. The minor Rust syntax issue in the code example should be addressed for accuracy, but it doesn't detract from the overall excellent quality of the documentation. Recommendation: ✅ Approve with minor fix The documentation changes are well-structured, technically sound, and provide valuable clarity on the SDK's architecture evolution. Once the code example issue is corrected, this will be an excellent addition to the documentation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't made it through the whole document yet but I'll post what I have so and do the rest tomorrow
|
|
||
| ## Architecture | ||
|
|
||
| The Bitwarden SDK is structured as a single |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: You didn't make any changes to this row but I still think we should change it since it's a bit confusing. The introduction to this page says that we provide two different SDK: "an SDK for Secrets Manager" and "an internal SDK for the Bitwarden Password Manager", but this row talks about "The Bitwarden SDK" which I think is too ambiguous.
I also think we should consider making an even more obvious split, maybe putting all of your changes in a separate sub-section, possibly Password Manager and maybe renaming Password Manager to Internal SDK, not sure. What do you think?
| Crates in the project fall into one of these categories. | ||
|
|
||
| - Application Interfaces | ||
| - Client Aggregators | ||
| - Features | ||
| - Core and Utility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question/suggestion: Shouldn't "bindings" also be a category?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh hang on, Bindings = Application interfaces!
suggestion: Clarify or maybe use the same terminology? I like application interfaces though, since the language binding isn't the point, it's the fact that we expose the same underlying things but in different ways, targeting different applications
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm actually, I'm reading the description for Client Aggregators now and it feels like that's what "Application Interfaces" should be?
| core --> auth | ||
| core --> vault | ||
| core --> export | ||
| core --> generators | ||
| core --> send | ||
| core --> crypto |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question/issue: why are the dependencies inverted here? I don't think 468 changed the direction?
| ``` | ||
|
|
||
| <details> | ||
| <summary>Prior to [bitwarden/sdk-internal#468][sdk-internal-468], the dependency graph of the project was fairly redundant.</summary> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I'm not sure I follow, why it was redundant, in what way?
| ### Features and Domains | ||
|
|
||
| Feature and domain crates constitute the application business logic. <Bitwarden>These crates are | ||
| usually owned and maintained by individual teams.</Bitwarden> | ||
|
|
||
| ### Core and Utility | ||
|
|
||
| The `bitwarden-core` crate contains the underlying functionality of the SDK. This includes a | ||
| `Client` struct. Other crates in the SDK depend on `bitwarden-core` and provide extensions to the | ||
| `Client` struct to implement specific domains. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: change the order of "Features and Domains" and "Core and Utility". That way you can introduce Core first, and then move
Other crates in the SDK depend on
bitwarden-coreand provide extensions to the
Clientstruct to implement specific domains.
Into "features and domains"
Feature crates depend on
bitwarden-coreand provide extensions to theClientstruct to implement specific domains
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here's the rest of my review, just a few additional comments
| #[cfg_attr(feature = "wasm", wasm_bindgen)] | ||
| impl GeneratorClient { | ||
| fn new(client: &'a Client) -> Self { | ||
| fn new(client: &Client) -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: the new function does not borrow the client struct, it takes ownership of it
| fn new(client: &Client) -> Self { | |
| fn new(client: Client) -> Self { |
| - Does the functionality require obtaining an observable or reactive value from the SDK? | ||
| - Unfortunately, that's not currently supported, but this can be worked around by using | ||
| client-managed state. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion: I think we might need to clarify this a bit
- What do we mean by obtaining an observable or reactive value from the SDK?
- Are we outputting or consuming reactive data?
Unfortunately, that's not currently supported, but this can be worked around by using client-managed state.
I don't feel like this really helps you reach a conclusion, it starts out by saying it isn't supported, then says that it might be supported 🤷
We should probably clarify that the SDK does not support reactivity at this time period. However, we still encourage adding the business logic to the SDK. The reactivity can be built on top of it in TypeScript

🎟️ Tracking
PM-23252
📔 Objective
Update SDK docs to describe the new crate structure.
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes