Migrate from Websockets to REST/Webhook based Architecture

[theSoberSobber]

The usage of websockets is one of the biggest pain points for this type of system.
Even despite not being CL (continuously listening) system (it is triggered by the user performing a GET request on the given endpoint, and as for the AT BOT, it is initiated by the checkAndReturn() function), the usage of websockets proves to be a bottleneck. Since no REST API hosting service supports websockets.

With that said, the problem here is that whatsapp doesn't have built in Integration for BOTS (like '/' in telegram), hence we need to listen to all messages and react to the one's meant for us.

Whatsapp does provide support for BOTs through webhook, but they probably run a similar websockets based approach (where they are constantly listening for message.upsert excluding groups on your session) on a server that sends HTTP Notifications to you. That's probably the reason they charge money for it.

A (maybe?) better approach could've been to just open up a selenium and message using headless web-scraping. That way we can atleast deploy a simple RESTful endpoint (or a HTTP based - CL function, like checkAndReturn ) that interacts with whatsapp.

Although I am not entirely positive that services like Vercel/Netlify would support a selenium/puppeteer instance running on what is supposed to be a RESTful API backend.

[theSoberSobber]

The original inspiration for this project @DTUAlertBot, uses a service hosted on @heroku to monitor the site and cache updates every 15 seconds.
Then it calls the HTTP webhook of Telegram & Whatsapp to send a update message to the users.
The webook servers at WA and Tel probably spin up on network requests, use their native auth to create session on the server and after performing the action, spin down again after some threshold time, killing the instance.