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(api-service): get subscriber preferences v2 endpoint #7613

Merged
merged 10 commits into from
Jan 31, 2025

Conversation

ChmaraX
Copy link
Contributor

@ChmaraX ChmaraX commented Jan 29, 2025

What changed? Why was the change needed?

TODO:

  • Speakeasy annotations - replace with legacy endpoints

Copy link

linear bot commented Jan 29, 2025

Copy link

netlify bot commented Jan 29, 2025

Deploy Preview for dev-web-novu ready!

Name Link
🔨 Latest commit ad4666b
🔍 Latest deploy log https://app.netlify.com/sites/dev-web-novu/deploys/679cd7639faed100089f6451
😎 Deploy Preview https://deploy-preview-7613.dashboard.novu-staging.co
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link

netlify bot commented Jan 29, 2025

Deploy Preview for dashboard-v2-novu-staging ready!

Name Link
🔨 Latest commit ad4666b
🔍 Latest deploy log https://app.netlify.com/sites/dashboard-v2-novu-staging/deploys/679cd763d9594e0008411e9c
😎 Deploy Preview https://deploy-preview-7613.dashboard-v2.novu-staging.co
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Copy link

pkg-pr-new bot commented Jan 30, 2025

Open in Stackblitz

@novu/client

npm i https://pkg.pr.new/novuhq/novu/@novu/client@7613

@novu/headless

npm i https://pkg.pr.new/novuhq/novu/@novu/headless@7613

@novu/node

npm i https://pkg.pr.new/novuhq/novu/@novu/node@7613

@novu/notification-center

npm i https://pkg.pr.new/novuhq/novu/@novu/notification-center@7613

novu

npm i https://pkg.pr.new/novuhq/novu@7613

@novu/providers

npm i https://pkg.pr.new/novuhq/novu/@novu/providers@7613

@novu/shared

npm i https://pkg.pr.new/novuhq/novu/@novu/shared@7613

commit: ad4666b


export interface IGetSubscriberPreferencesResponseDto {
global: {
enabled: boolean;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fun fact:
we allow enabled in update DTO, to disable all global preferences as I understand, but we never use it anywhere:

export type UpdateSubscriberGlobalPreferencesRequestDto = {
  /**
   * Enable or disable the subscriber global preferences.
   */
  enabled?: boolean | undefined;
  /**
   * The subscriber global preferences for every ChannelTypeEnum.
   */
  preferences?: Array<ChannelPreference> | undefined;
};

we always return enabled: true so you can't in fact disable all preferences globally.

@ChmaraX ChmaraX changed the title feat(api-service): subscriber preferences WIP feat(api-service): subscriber preferences Jan 30, 2025
@ChmaraX ChmaraX marked this pull request as ready for review January 30, 2025 14:05
Comment on lines -18 to -34
export interface ISubscriberWorkflowPreferenceResponse extends IPreferenceResponse {
workflow: ITemplateConfiguration;
level: PreferenceLevelEnum.TEMPLATE;
}

export interface IWorkflow extends Omit<ITemplateConfiguration, '_id'> {
id: string;
}
export interface ISubscriberPreferences {
level: PreferenceLevelEnum;
workflow?: IWorkflow;
enabled: boolean;
channels: IPreferenceChannels;
overrides?: IPreferenceOverride[];
}

export interface IPreferenceResponse {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not used so I removed it.

Comment on lines +28 to +31
return plainToInstance(GetSubscriberPreferencesDto, {
global: globalPreference,
workflows: workflowPreferences,
});
Copy link
Contributor Author

@ChmaraX ChmaraX Jan 30, 2025

Choose a reason for hiding this comment

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

I think we should serialize response to DTO like this in all new endpoints, maybe better in controller instead of usecase - it ensures response is validated and transformed to what is specified in DTO class.

It can be also setup globally on all controlles so this line is not needed.
https://docs.nestjs.com/techniques/serialization#overview

Between usecases, I would left just regular types.

I think this would lead to generally cleaner experience.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure if that is needed because everything that comes from the DAL layer should already be valid. Otherwise, it means that we have a corrupted state in DB.
But I would like to hear some other opinions.

BTW plainToInstance can be done on the base class that we can extend from, so we don't need to do it every time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What I mean is the DTO that comes as a response from API, DAL layer is business logic, this is to better illustrate - we dont serialize and we think we do, in order for ClassSerializer decorator to work, you need to return instance from a controller (or it can be also automatized by other decorator) - but we dont do it correctly.

image

@ChmaraX ChmaraX changed the title feat(api-service): subscriber preferences feat(api-service): get subscriber preferences v2 endpoint Jan 30, 2025
summary: 'Get subscriber preferences',
description: 'Get subscriber preferences',
})
async getSubscriberPreferences(
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we want also to define a custom sdk method name? I'm wondering how it will name it by default.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've named it retrieve, I think thats the convention

Comment on lines +28 to +31
return plainToInstance(GetSubscriberPreferencesDto, {
global: globalPreference,
workflows: workflowPreferences,
});
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure if that is needed because everything that comes from the DAL layer should already be valid. Otherwise, it means that we have a corrupted state in DB.
But I would like to hear some other opinions.

BTW plainToInstance can be done on the base class that we can extend from, so we don't need to do it every time.

}

private mapToWorkflowPreference(subscriberWorkflowPreference: ISubscriberPreferenceResponse): WorkflowPreferenceDto {
const { preference, template } = subscriberWorkflowPreference;
Copy link
Contributor

Choose a reason for hiding this comment

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

we should have workflow instead of template

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a return type from already existing getSubscriberPreference usecase which is reused in other places across the app.

Comment on lines +113 to +115
throw new NotFoundException(
`Subscriber ${command.subscriberId} not found`,
);
Copy link
Contributor

Choose a reason for hiding this comment

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

did you verify that this usecase is not used in worker?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes - from what I see, worker is using just GetSubscriberPreference usecase, but even for that usecase I can't find any use inside worker - I will check if we can remove it possibly in next PR.

@ChmaraX ChmaraX merged commit 5d756e5 into next Jan 31, 2025
40 checks passed
@ChmaraX ChmaraX deleted the nv-5278-api-get-preferences-endpoint branch January 31, 2025 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants