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

feat: get config-versions api #248

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

mahatoankitkumar
Copy link
Collaborator

@mahatoankitkumar mahatoankitkumar commented Sep 25, 2024

Problem

get config-versions api

API changes

Endpoint Method Request body Query Params Response Body
/config-versions GET None { count: Option<i64>, page: Option<i64> } {"total_pages": total_pages, "total_items": n_version, "data": config_versions }

@mahatoankitkumar mahatoankitkumar requested a review from a team as a code owner September 25, 2024 03:04
@ayushjain17
Copy link
Collaborator

Can you please add the query param info as well in the description

async fn get(
db_conn: DbConnection,
filters: Query<QueryFilters>,
) -> superposition::Result<HttpResponse> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of HttpResponse , Can you change it to a type as SnapshotResponse or something?

Copy link
Collaborator Author

@mahatoankitkumar mahatoankitkumar Sep 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah can be done but the response now is
"total_pages": total_pages, "total_items": n_version, "data": config_versions
but as pagination is/will be there for so many APIs
Maybe something like this can be done
`enum DataType<A, B, C> {
TypeA(Vec),
TypeB(Vec),
TypeC(Vec),
}

struct PaginatedResponse<A, B, C> {
total_pages: i64,
total_items: i64,
data: DataType<A, B, C>,
}`

Opinions?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah , that looks a better generic solution to me , we can do that.

Copy link
Collaborator

@ayushjain17 ayushjain17 Sep 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mahatoankitkumar @sauraww you don't need an enum for this
the PaginationResponse should be a generic type capable of returning any paginated response for any data type, an enum should be needed for it, as in case of Enum it would lead to unnecessary boilerplate code as well

simply doing this should be enough:

pub struct PaginatedResponse<T> {
      pub total_pages: i64,
      pub total_items: i64,
      data: T,
}

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more addition to this, T should be deserializable, which can be done by struct PaginatedResponse<T: DeserializeOwned>.

async fn get(
db_conn: DbConnection,
filters: Query<QueryFilters>,
) -> superposition::Result<HttpResponse> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah , that looks a better generic solution to me , we can do that.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we sync one single name for this, frontend we are referring it as Snapshot here Config Version?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah @JamesGeorg we have decided to go with config-versions, as this is not a complete representation of what snapshot is.

}

#[derive(Serialize, Debug, Clone, Deserialize)]
pub struct PaginatedResponse<T> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we move this to superposition_types in some new file for such common utility types as it might be useful for experimentation as well for list experiments

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.

5 participants