I have a bot connected to appropriate IRC channels
It actually communicates with an API through rest to interact with a database
The API responds to the bot THEN the bot send messages to the appropriate user channel
Nothing too fancy.
As I dig dipper in my project, I’m wondering if it would not be a better solution to have the API send messages directly messages to the channel(s).
The pros I can think of :
getting rid of the layer of the bot having to process the returned response of the API
having all messages functions, internationalization etc in one project rather than scattered between API and bot
PHP is easier to maintain for me
The cons :
The API starts to be off of its supposed purpose
I’ll have to had an extra flag when I (don’t) want the message to be posted to the channel
opening and closing IRC connection each time i have a message to send is maybe bad practice, not performance friendly ?
Am I missing something ? thoughts on this are welcomed
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.
Thanks for your feedback, this makes sense
In the end, having the bot responsive is more important than the rest. UX above all. I’ll give a try to the extension API
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.
Sometimes the most obvious solutions are just in front of you. I’m not to the point
My bot is meant to be bilingual depending of user preference. It’s not a big deal actually.
They are but maybe it might change someday. I’m not aware of signaling. Searching this didn’t return much. Do you have documentation ?
My bot doesn’t do anything fancy : listen to commands, respond with text, send rest request, listens to a pubsub service. it’s just part of a larger project
But it will not be the main way to interact with the service. Meaning the streamer doesn’t necessarily have it installed to enjoy the service so I guess I can’t really rely on the extension yeah
