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

Core Messaging Design #545

Open
pozylon opened this issue Jan 16, 2023 · 0 comments
Open

Core Messaging Design #545

pozylon opened this issue Jan 16, 2023 · 0 comments
Labels
help wanted Extra attention is needed question Further information is requested
Milestone

Comments

@pozylon
Copy link
Member

pozylon commented Jan 16, 2023

core-messaging is currently responsible for:

  • Providing a central director/registry for registration of templates
  • Providing module functions to help render text with mjml or mustache

The "message" plugin (which is in plugins) is currently responsible for calling the director to get the correct template, then applies the template to it's input which adds 0 or more work queue items depending on the messaging template

Every core-module currently calls the worker independently and adds message items, example:

sendOrderRejectionToCustomer: async (order, params, { modules }) => {
      const user = await modules.users.findUserById(order.userId);
      const locale = modules.users.userLocale(user);

      await modules.worker.addWork({
        type: 'MESSAGE',
        retries: 0,
        input: {
          ...params,
          locale,
          template: 'ORDER_REJECTION',
          orderId: order._id,
        },
      });

      return order;
    },

Problems with the current design:

  • When there is no template registered for a specific message template, there will always be at least 1 MESSAGE queue item for every such event with ERROR state that pollutes the work queue.
  • When there is no notifications to be sent in any way, there will always be at least 1 MESSAGE queue item for every message event which pollutes the work queue.
  • The core-messaging's core functions are more utils than anything else
  • There is no safe way for a module to add a message
  • Messaging is spread all over and the call of the context's worker is violating our idea of strict seggregation of modules and services concept
  • We cannot track a "read/unread" status of a message even if the messaging plugin would support that

Ideas:

  • Provide an event type of the event system when registering a template, getting rid of the explicit calls to addWork(type MESSAGE):
MessagingDirector.registerTemplate(MessageTypes.ORDER_CONFIRMATION, resolveOrderConfirmationTemplate, "ORDER_CONFIRMED");
  • Remove the "MESSAGE" plugin and instead extend the core-messaging plugin with a "messages" collection that tracks all messages and their delivered/pending/error & read/unread stati.
  • Remove the render utils for mjml and mustache. remove default html email variants. mjml as a dependency currently weighs in at 224 deps, 18.72mb, 5622 files.
@pozylon pozylon added help wanted Extra attention is needed question Further information is requested labels Jan 16, 2023
@pozylon pozylon added this to the v3.0 milestone Jan 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed question Further information is requested
Projects
Status: v3.0 (Q3 / 2024)
Development

No branches or pull requests

1 participant