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): add full step data to workflow dto; refactor #7235

Merged
merged 4 commits into from
Dec 10, 2024

Conversation

ChmaraX
Copy link
Contributor

@ChmaraX ChmaraX commented Dec 7, 2024

What changed? Why was the change needed?

TL;DR:

  • The external workflow DTO now includes full step data (with control values etc). This supports multiple upcoming features and simplifies both the frontend and backend significantly.
  • A unified external step DTO replaces previously inconsistent step DTOs returned by GET step and GET workflow endpoints

💡 These changes do not affect FE-BE compatibility in any way - only new fields were added to workflow.steps, no external DTO property was removed or renamed.

Key DTO changes:

File renames and moves:

  • step-data.dtostep.dto.ts (better reflects contents and avoids circular imports).
  • All step-related DTOs consolidated in step.dto.ts.
  • workflow.dto.tsworkflow.deprecated.dto (contains only deprecated DTOs).
  • workflow-response.dtoworkflow.dto.ts.
  • All workflow-related DTOs consolidated in workflow.dto.ts.

Simplified Step DTO:

  • Replaced StepResponseDto with StepDataDto (already used by GET step).
  • This unification reduces redundancy and simplifies the codebase.

Refactoring:

  • sync-to-environment.usecase - improved naming, less code, clearer intent
  • Removed redundant workflow e2e code (full step data is now available without extra fetches).

Next steps:

  1. Update the frontend to use step data from the GET workflow endpoint.
    1.1 this will enable us to get rid of react-query cache invalidation code, step hooks etc
  2. Remove unused API GET step endpoint, (I think we should also remove PATCH step + usecases) since we are currently not using them - if we decide to use them again in future we can find them in git history
  3. Simplify API e2e tests

Copy link

linear bot commented Dec 7, 2024

Copy link

netlify bot commented Dec 7, 2024

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

Name Link
🔨 Latest commit 01e4a62
🔍 Latest deploy log https://app.netlify.com/sites/dashboard-v2-novu-staging/deploys/67570f5351e84500088817b3
😎 Deploy Preview https://deploy-preview-7235.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

netlify bot commented Dec 7, 2024

Deploy Preview for dev-web-novu ready!

Name Link
🔨 Latest commit 01e4a62
🔍 Latest deploy log https://app.netlify.com/sites/dev-web-novu/deploys/67570f53ae2355000835e25c
😎 Deploy Preview https://deploy-preview-7235.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

pkg-pr-new bot commented Dec 7, 2024

Open in Stackblitz

@novu/client

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

@novu/headless

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

@novu/framework

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

@novu/node

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

@novu/notification-center

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

novu

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

@novu/providers

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

@novu/shared

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

commit: 01e4a62

@ChmaraX ChmaraX marked this pull request as ready for review December 7, 2024 20:09
Copy link
Contributor

@djabarovgeorge djabarovgeorge left a comment

Choose a reason for hiding this comment

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

looks good! :)
left a couple of comments for your review.

@@ -30,7 +33,7 @@ export function toResponseWorkflowDto(workflow: WorkflowInternalResponseDto): Wo
tags: workflow.tags,
active: workflow.active,
preferences: preferencesDto,
steps: getSteps(workflow),
steps: fullSteps,
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe we should keep the mapping here for two key reasons:

  1. We’re adding extra parameters, such as slug, which are only exposed to the API client.
  2. We’re mapping the types—for instance, if the entity allows undefined, we convert those to stricter types in the DTO response.

Copy link
Contributor

Choose a reason for hiding this comment

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

the first point is not relevant, i see that you added the slug to the BuildStepDataUsecase.

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 see your point but the stricter types in this case are already coming from the BuildStepDataUsecase.

The return type from the BuildStepDataUsecase doesn't allow undefined and does explicit checks for missing values, therefore having additional response type for step and mapping, e.g. like this:

name: step.name || 'Missing step name' 

would be redundant . I think we should keep it simple and when the usecase emerges then we can have some mapping.

@@ -15,7 +15,10 @@ import { NotificationStepEntity, NotificationTemplateEntity } from '@novu/dal';
import { WorkflowInternalResponseDto } from '@novu/application-generic';
import { buildSlug } from '../../shared/helpers/build-slug';

export function toResponseWorkflowDto(workflow: WorkflowInternalResponseDto): WorkflowResponseDto {
export function toResponseWorkflowDto(
Copy link
Contributor

Choose a reason for hiding this comment

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

the point was letting this map to dto, if you send the DTO pre cooked I think it's taking the string out of the funciton no? I would expect to get the entity list and maps of the additinoal data you want to bake in

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It still maps the workflow to DTO as name of the method suggests, only the steps are coming in already in "DTO form".

We simply don't need to do any mapping for the steps for now, its already in viable form, which is good. Each layer of mapping just adds an overhead

Copy link
Contributor

@tatarco tatarco left a comment

Choose a reason for hiding this comment

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

It's looking OK, I'm missing some tests and added some comments, lets please resolve / reply to them before merging

Comment on lines -74 to -85
function toStepResponseDto(persistedStep: NotificationStepEntity): StepResponseDto {
const stepName = persistedStep.name || 'Missing Name';

return {
_id: persistedStep._templateId,
slug: buildSlug(stepName, ShortIsPrefixEnum.STEP, persistedStep._templateId),
name: stepName,
stepId: persistedStep.stepId || 'Missing Step Id',
type: persistedStep.template?.type || StepTypeEnum.EMAIL,
issues: persistedStep.issues,
} satisfies StepResponseDto;
}
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 moved this directly to the build-step-data use-case, because its always used together with the use-case.

If the usecase for unsanitized step data emerges, then we can split it again or create GetStepDataInternal usecase.

Now I don't think its even possible to create step without name or stepId or without type, it seems to be here only because of tests. These things should be validated upon creation and not rely on fallbacks anyway.

@ChmaraX ChmaraX merged commit d87ec5f into next Dec 10, 2024
43 checks passed
@ChmaraX ChmaraX deleted the nv-4974-add-step-data-to-get-workflow-endpoint branch December 10, 2024 09:03
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