-
-
Notifications
You must be signed in to change notification settings - Fork 227
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
Comments
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:
Cons:
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:
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 HostingWhen self-hosting Tolgee the user can set their service, instead of using "Tolgee official App on Slack", by cloning the service and voilá. Community contributionCreating 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 ( 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.
The text was updated successfully, but these errors were encountered: