I did a test on spinning up a chat bot on demand per message. It will “work” but has a much higher delay than just keeping it open. My idea was to create my entire app serverless, to reduce costs, so only pinging my api would trigger a chat message to occur. It did what I needed to do for my test, but scaling probably wouldn’t go as well as you would hope if you need to send chat messages very often. If you have an extension, there is an API endpoint to send chat messages too as the extension. This will only work if they have it installed, and allowed chat too, so there are more activation steps. I was going to use a combination of both, if they have the extension, use the API as the response time is quicker, and if not, spin up a chat instance.
The comparison here is that an API call might be slower/delayed/more prone to “fail” and need to retry.
Since it has to do all the connection overhead (to Twitch) each time.
Where as with a bot all the connection overhead is already done and you can super optimise traffic to/from your bot and your API than you cna between you and Twitch. Since you control both sides of your stuff.
What you describe doesn’t sound like it’s an extension, so the extension solution might not be appropriate.
Just write your bot in PHP. I for a long time used a self modified fork of SmartIRC (a PHP IRC Lib)
Not sure where internationalization comes in, with your bot.
Depens what the bot is for/does. Theres information missing about your use case onto why internationalization your API should just send “send this to chat” to your bot and your bot does that. So the bot doesn’t care whats in the message, it just shuttles it.
There are ways to optimise/adjust this traffic.
Like instead of a REST API you utilise a socket. Which improves speed since the connection is already open.
If they are both on the same server, you can use signalling or other things.
Theres a lot of what if’s depending on what the bot is for and supposed to do.