Closed Martin005 closed 7 months ago
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
The idea of abstracting integrations as a webhook and outsourcing it to a specific service:
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.
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
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
When self-hosting Tolgee the user can set their service, instead of using "Tolgee official App on Slack", by cloning the service and voilá.
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".
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). 😄
When something changes in a project, users will be notified, if enabled.