Skip to content

Conversation

@dereknance
Copy link

@dereknance dereknance commented Oct 20, 2025

🎟️ Tracking

PM-23252

📔 Objective

Update SDK docs to describe the new crate structure.

⏰ Reminders before review

  • Contributor guidelines followed
  • All formatters and local linters executed and passed
  • Written new unit and / or integration tests where applicable
  • Protected functional changes with optionality (feature flags)
  • Used internationalization (i18n) for all UI strings
  • CI builds passed
  • Communicated to DevOps any deployment requirements
  • Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
    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 confirmed
    issue 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

@claude

This comment was marked as outdated.

@github-actions
Copy link

github-actions bot commented Oct 20, 2025

Logo
Checkmarx One – Scan Summary & Detailsca8adc12-88a2-4501-b6bb-8bc2fadc4e78

Great job! No new security vulnerabilities introduced in this pull request

@dereknance dereknance changed the title [PM-23252] SDK rate restructure [PM-23252] SDK crate restructure Oct 20, 2025
@claude

This comment was marked as outdated.

@cloudflare-workers-and-pages
Copy link

cloudflare-workers-and-pages bot commented Oct 20, 2025

Deploying contributing-docs with  Cloudflare Pages  Cloudflare Pages

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

View logs

@claude

This comment was marked as outdated.

@claude
Copy link

claude bot commented Oct 20, 2025

Claude finished @dereknance's task —— View job


PR Review: SDK Crate Restructure Documentation

Todo List:

  • Read repository guidelines (CLAUDE.md)
  • Examine changed files and understand modifications
  • Review technical accuracy and content structure
  • Check formatting, grammar, and spelling
  • Verify code examples and diagrams
  • Assess documentation clarity for target audience
  • Provide comprehensive review feedback

Review Summary

This 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

  1. Excellent structural documentation: The new crate categorization (Application Interfaces, Client Aggregators, Features, Core and Utility) provides clear organizational clarity
  2. Effective visual documentation: The PlantUML diagrams effectively illustrate the cleaner dependency structure with good color coding and logical grouping
  3. Valuable historical context: The collapsible details section with the "before" diagram helps readers understand the architectural evolution from the previous "spaghetti" structure
  4. Consistent formatting: Follows repository guidelines for headings, code blocks, and structure
  5. Technical accuracy: The dependency graphs correctly represent the new aggregator pattern
  6. Clear business logic: The decision tree for adding functionality provides practical guidance for developers

📝 Minor Issues Identified

docs/architecture/sdk/index.md:182-184

Code example inconsistency:

impl GeneratorClientExt for Client {
    fn generator(&self) -> GeneratorClient {
        GeneratorClient::new(self.clone())  // Issue: unnecessary clone
    }
}
  • Problem: Line 166 shows GeneratorClient::new(client: &Client) expecting a reference, but line 183 passes self.clone(), creating an unnecessary allocation and type mismatch
  • Suggestion: Change line 183 to GeneratorClient::new(self) to match the function signature and avoid cloning, or adjust the new function to accept the cloned value

🎨 Enhancement Suggestions

  1. Client Aggregators explanation: Consider adding a brief example of what constitutes a "client aggregator" beyond the definition. For instance, mentioning that bitwarden-pm and bitwarden-sm are examples would help concrete understanding.

  2. Feature crate examples: The "Features and Domains" section could benefit from listing specific examples like bitwarden-vault, bitwarden-auth, etc., to make the concept more tangible for developers.

  3. Dependencies documentation: The change in dependencies.md (line 3) from "crates" to "standalone crates" improves clarity and better reflects the new structure.

🔍 Technical Validation

  • ✅ PlantUML syntax is correct and will render properly
  • ✅ All links and references are properly formatted
  • ✅ Markdown structure follows repository conventions
  • ✅ The architectural diagrams accurately reflect the described structure
  • ✅ Documentation follows the established style guide (proper heading caps, code blocks)
  • ✅ Conditional content properly tagged with <Bitwarden> tags
  • ✅ Maintains concise, technical tone appropriate for the audience
  • ✅ The new "Adding New Functionality" section provides valuable practical guidance

📋 Compliance with Repository Guidelines

  • ✅ Follows repository style guide requirements (CLAUDE.md)
  • ✅ Uses code blocks appropriately (not inline code)
  • ✅ Includes proper frontmatter
  • ✅ Uses <details> blocks for large diagrams appropriately
  • ✅ PlantUML diagrams follow the preferred format over Mermaid for this use case
  • ✅ No unnecessary new files created
  • ✅ Proper heading capitalization maintained

📊 Overall Assessment

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


@dereknance dereknance marked this pull request as ready for review October 20, 2025 21:38
@dereknance dereknance requested a review from a team as a code owner October 20, 2025 21:38
Copy link
Contributor

@coroiu coroiu left a 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
Copy link
Contributor

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?

Comment on lines +25 to +30
Crates in the project fall into one of these categories.

- Application Interfaces
- Client Aggregators
- Features
- Core and Utility
Copy link
Contributor

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?

Copy link
Contributor

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

Copy link
Contributor

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?

Comment on lines +109 to +114
core --> auth
core --> vault
core --> export
core --> generators
core --> send
core --> crypto
Copy link
Contributor

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>
Copy link
Contributor

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?

Comment on lines +132 to 141
### 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.
Copy link
Contributor

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-core and provide extensions to the
Client struct to implement specific domains.

Into "features and domains"

Feature crates depend on bitwarden-core and provide extensions to the Client struct to implement specific domains

Copy link
Contributor

@coroiu coroiu left a 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 {
Copy link
Contributor

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

Suggested change
fn new(client: &Client) -> Self {
fn new(client: Client) -> Self {

Comment on lines +238 to +240
- 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.
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants