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

Notifications #1539

Closed
Martin005 opened this issue Feb 9, 2023 · 2 comments
Closed

Notifications #1539

Martin005 opened this issue Feb 9, 2023 · 2 comments
Assignees

Comments

@Martin005
Copy link
Contributor

When something changes in a project, users will be notified, if enabled.

@Martin005 Martin005 added the roadmap item Items that are automatically added to the Roadmap label Feb 9, 2023
@Martin005 Martin005 moved this to Todo in Tolgee Roadmap Feb 16, 2023
@JanCizmar JanCizmar mentioned this issue Mar 11, 2023
36 tasks
@horstmannmat
Copy link

horstmannmat commented Nov 19, 2023

Hi @Martin005 and @JanCizmar, Could this issue also be related to #1544?

At least I see #1539, #1384, and #1975, even #1542 and the Email notification. as just a specialisation of a webhook, performing the exact same actions that a webhook would but for a specific endpoint

TLDR;

The idea of abstracting integrations as a webhook and outsourcing it to a specific service:

Pros:

  • Easy to add new integration since it would just send the webhook content
  • Reduce code entropy every time that an integration is requested.
  • Third-party integrations allow the community to share and create their own integration (marketplace of integrations)

Cons:

  • Additional Cloud resources are needed.
  • More projects to maintain (when hosted by Tolgee).

RFC:

So, instead of coupling more code to the project every time an integration is requested. Which will then create more entropy.

You could abstract as a webhook and run each integration as a specific service (Yeah we are talking about microservices )

Those services would not have access to Tolgee`s database, only being a relay/"translator"(no pun intended) to the software you want.

Examples:

Slack/Discord/Telegram : 
The webhook POST to an endpoint of a slack/discord/telegram bot application, which will then process the content and send the message to where it was designed.
Git: 
The service can have two endpoints:
1) When the repo is updated on git: Github/GitLab would trigger the endpoint. The service would pull and upload to Tolgee
2) When the project is updated/exported on Tolgee: The service would then export the data using Tolgee API and create an MR/PR on the repo

Common integrations:

The most used integrations (Slack, Telegram, Discord, Teams, Email etc.) could have "Tolgee official service" and "pre-made webhook config" in Tolgee UI, making it easy for the user to set up

Self Hosting

When self-hosting Tolgee the user can set their service, instead of using "Tolgee official App on Slack", by cloning the service and voilá.

Community contribution

Creating at least one of these services, or a scaffold project, would allow the community to be more participative (using it as a reference) to build additional integrations that could be incorporated into the "pre-made webhook configs".

@cyyynthia
Copy link
Collaborator

Hey there, I'm currently the person working on the core notifications system, so I'll leave my thoughts about that (which are not final and totally up for discussion/reconsideration).

A problem of microservice architectures is how they become harder to selfhost (I know, Docker does the trick, but custom services do become a problem anyway), and tend to cause a lot of issues as they almost certainly imply starting on adding complex infrastructure around it (e.g. RabbitMQ, or an embedded Raft implementation, etc. to communicate and pass tasks to one another). This is an argument I'd argue against going microservice, at least yet.

That being said, the implementation I'm working on is based on Spring's event emitter system, with dispatcher components (EmailDispatcher, WebhookDispatcher, DiscordDispatcher, ...) listening to events (the notification emitter itself is listening for events, as this is how the project activity is being centralized). This means one day, if going the microservice route is thought about, the code is already built in an event-driven fashion which can be with probably little effort transformed into pushing to a distributed event queue.

While all those cause problems on Tolgee, the webhook system is IMHO sufficient as the community can build relays and use them to do all sorts of great additional integrations. It sure is less convenient as a marketplace, but is a much simpler way at this time that allows spending more time on all sorts of great features and still have a generic dispatch routine for custom handlers.

Git integrations are planned separately to design a richer and more polished experience (and use more appropriate internal events) in #1542. Discord integration would most likely not (as far as Tolgee's internal implementation is concerned) rely on bot applications but rather use Discord's own Webhook execution system that's more appropriate for notification dispatching.

That being said, while I'm not in favor of adding this in the initial iteration of the notifications system, adding ways to create new integrations in "no-code" might be something that can be considered in the future (although something I'd consider low priority). 😄

@cyyynthia cyyynthia self-assigned this Nov 19, 2023
@cyyynthia cyyynthia moved this from Todo to In Progress in Tolgee Roadmap Nov 19, 2023
@ZuzanaOdstrcilova ZuzanaOdstrcilova removed the roadmap item Items that are automatically added to the Roadmap label Apr 16, 2024
@github-project-automation github-project-automation bot moved this from In Progress to Done in Tolgee Roadmap Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

4 participants