novuhq / novu

Open-Source Notification Platform. Embeddable Notification Center, E-mail, Push and Slack Integrations.
https://novu.co
Other
35.41k stars 3.92k forks source link

[NV-2615] New providers, based on AMQP #3812

Open yiiman-dev opened 1 year ago

yiiman-dev commented 1 year ago

🔖 Feature description

Because adding new provider is hard and needs long time for programming and reviews, i want create an AMQP based provider, that can produce payload messages to external RabbitMQ queue. By this concept, new users can config multiple dynamic producers around different workflows, and consume messages from novu. Then, they can programming consumers for their AMQP providers by own language and frameworks.

🎤 Why is this feature needed ?

Because Novu has not very providers. Develop a new native provider, need long time, from conversation to develop and release. Novu is NodeJS based, so when i want use my provider as another stacks, i cant, because every provider should program under nodejs syntax.

✌️ How do you aim to achieve this?

I can develop this providers.

🔄️ Additional Information

No response

👀 Have you spent some time to check if this feature request has been raised before?

🏢 Have you read the Code of Conduct?

Are you willing to submit PR?

Yes I am willing to submit a PR!

NV-2615

michaldziuba03 commented 1 year ago

hello @yiiman-dev

there was similar idea but with MQTT protocol: https://github.com/novuhq/novu/discussions/3709

Can you explain more details?

Does "AMQP provider" could push new message to the queue on trigger and then client's role is to consume that message on their backend?

What channel you could assign to AMQP Provider? Novu has in-app, email, push, chat, sms? Each has it's own specifics. Maybe should be created new channel for this provider?

For me personally this type of provider is too generic. I feel it's bit out of scope what Novu tries to be, I mean - things like brokers, queues and databases are more part of infrastructure and I don't see them as providers.

I think there can be better solution instead creating new provider for each protocol - I think Novu may implement webhook dispatcher and then people could do whatever they want with the notification in their webhook handlers - send them to queues/brokers, save in databases. But it's my personal idea, something like this is also very generic.

yiiman-dev commented 1 year ago

Hello @michaldziuba03 I want to create one provider for all of types that can config type by user. User can select from type dropdown one type of sms,in_app,email and etc

Yes, novu will consume a payload message (templated as selected type:sms,email ...) and user can consume and process this payload on another backend. On EDD and Microservice systems, this method can be helpful for scaling abilities.

scopsy commented 1 year ago

@yiiman-dev just to verify your suggestion, you only want Novu to send a message to the queue when it's sending an email for example, not for your queue to trigger the templates themselves. right?

yiiman-dev commented 1 year ago

@scopsy yes I want to develop this feature, because developing a new provider is very hard and long time to approve or review by contributers. New users, can use novu widgets and management engine and workflow power. But they can use AMQP provider Instead of create new. This does not contradict the production of sustainable providers. But it frees developers from the long process of creating a new provider, especially when they want to get to the product as quickly as possible in a short timeframe. I've been waiting a long time for the code verification of the provider I developed and practically can't take advantage of this system until a contributor approves my code.

ngtive commented 1 year ago

@yiiman-dev https://github.com/ngtive/novu I added a simple provider to use amqp protocol if that's what you want please let us know

yiiman-dev commented 1 year ago

@yiiman-dev https://github.com/ngtive/novu I added a simple provider to use amqp protocol if that's what you want please let us know Very thanks this is very useful for test novu when, novu has not supported an specified provider