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.