feat(i18n): Watch beabee content for locale changes #3
Conversation
…to the latest tag in the beabee/telegram-bot repository
…r:push" for consistency and correctness
fix(telegram.service.ts): import readJson function from utils/file.ts to parse JSONC files feat(telegram.service.ts): add printInfo method to log package name, version, and bot username on startup fix(file.ts): use parseJsonc function from deps.ts to parse JSONC files instead of JSON.parse
There was a problem hiding this comment.
I love the attempt to make this as pure as possible but I think this might be a bit over engineered 😛
In practice an instance's language basically never changes once it's been set up, and this solution generates a lot of API requests. I think it would be better just to have an endpoint we can push to.
This actually already exists for the intended use case (watching for locale changes)
https://github.com/beabee-communityrm/beabee/blob/master/src/core/services/OptionsService.ts#L123
The services all share an internal network in their Docker stack which they can use to communicate. Obviously it's very hacky at the moment, I'd love for this to just broadcast to the internal network, but I think it's better than polling the API so much. What do you think?
|
thanks that's better, I'll implement it |
|
Do I just need to add the telegram bot service to the notify list and implement a reload controller in the bot to refetch the content? |
|
Yeah you can see the very simple route that gets created here for the legacy app, API and webook app: https://github.com/beabee-communityrm/beabee/blob/master/src/core/server.ts#L13 It basically creates an internal HTTP server that listens to :4000, I'd do the same for the telegram bot too. Then just needs to refetch the content when it gets that signal. Ideally we wouldn't reference the telegram bot in the core app but it might be the simplest thing to do for now, just behind an env var so it can be enabled/disabled. You could do a quick bit of research into what it would take to create an internal broadcast messaging service like RabbitMQ that services can subscribe to, but if it's not really simple them just hardcode it for now. |
|
Or I know that people often use Redis for this sort of thing too: https://redis.com/solutions/use-cases/messaging/ |
|
But just to emphasise: this is not a priority right now and hardcoding is also okay 🙃 |
|
Okay, since we don't plan for the bot to have its own interface anyway, we can simply set the port of the existing web server to 4000 and use it for that |
|
As long as this communication is really only internal and cannot be intercepted, I think this is a good and simple solution. But maybe we should change http to https |
|
Hmm I don't think you could use HTTPS here as app, api_app, etc. are internal names resolved by Docker's DNS so you'd only be able generate self signed certs in any case. I guess in theory someone could accidentally expose :4000 to the outside world. Clients using our hosted solution will be fine but maybe we should add a secret or something just to be safe? |
|
@wpf500 I have now also implemented the |
Watch beabee content for locale changes by pulling the API.
waitForUrlutil method to wait for the beabee api on bootstrapping the bot.