Skip to content
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

API refactor: Split data types into separate submodules #2077

Open
Tracked by #2008
szokeasaurusrex opened this issue Jun 3, 2024 · 4 comments
Open
Tracked by #2008

API refactor: Split data types into separate submodules #2077

szokeasaurusrex opened this issue Jun 3, 2024 · 4 comments
Assignees

Comments

@szokeasaurusrex
Copy link
Member

szokeasaurusrex commented Jun 3, 2024

Data types are types which exist primarily for serializing/deserializing request/response data. Examples include User and ReleaseStatus.

@szokeasaurusrex szokeasaurusrex changed the title Split data types (which exist primarily for serializing/deserializing request/response data) into separate submodules API refactor: Split data types into separate submodules Jun 3, 2024
@szokeasaurusrex
Copy link
Member Author

Or, perhaps it makes more sense to move this into sentry-rust

@stephanie-anderson
Copy link

Maybe get @Swatinem or @loewenheim's opinion on that

@Swatinem
Copy link
Member

Swatinem commented Jun 7, 2024

Also discussed with @elramen recently that IMO we shouldn’t bloat the SDK with types and definitions that are not directly useful for the SDK itself.

@szokeasaurusrex
Copy link
Member Author

szokeasaurusrex commented Jun 7, 2024

@Swatinem I was considering that we might implement this change as a new feature under sentry-types, so as not to increase binary size when not needed. The benefit would be that we could reuse this code in other Rust packages.

However, you have a fair point – the code would be, at least initially, only used in the CLI, so probably makes more sense to keep the code in the CLI. We can always reevaluate later.

Another idea I had would be perhaps that we could work towards splitting off reusable CLI code into a separate library (or perhaps, multiple libraries), which the CLI would use, and which we could reuse elsewhere. But, this would probably be a more long-term initiative

@szokeasaurusrex szokeasaurusrex self-assigned this Jun 7, 2024
szokeasaurusrex added a commit that referenced this issue Jun 7, 2024
 - Create a new `data_types` submodule under the `api` module.
 - Crate a `chunking` submodule under the `data_types` module.
 - Move all data types related to chunking from `src/api/mod.rs` to the `chunking` submodule, splitting their definitions further into submodules under `chunking`.

Ref #2077
szokeasaurusrex added a commit that referenced this issue Jun 10, 2024
 - Create a new `data_types` submodule under the `api` module.
 - Crate a `chunking` submodule under the `data_types` module.
 - Move all data types related to chunking from `src/api/mod.rs` to the `chunking` submodule, splitting their definitions further into submodules under `chunking`.

Ref #2077
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

No branches or pull requests

3 participants