Add fanciness: socket updates

[kamikazechaser]

Request to add fanciness to receive updates via a websocket in the same way we would recieve updates via a web hook, except that we won't need a SSL certificate or domain to receive the updates! This idea has been inspired by @GingerPlusPlus and a similar project can be found here. The advantage of this would be recieving updates faster without any polling and we will bypass the requisites of setting up a webhook! We can modify the above project and suite us!

[wojpawlik]

I think my bridge (not sure if that's the best word for it) is already usable (which does not mean there is no room for improvement, iirc handling errors could be done better than rejecting request), we'd just need a "client side" to it, which, if I recall correctly (I created the bridge some time ago) shouldn't be more than (pseudocode)

const ws = new WebSocket(`${url}/${token}`)
ws.onmessage = text => {
    const json = JSON.parse(text)
    bot.processUpdate(json)
}

Anyone could write alternative bridge if he wishes, of course, and as long as it has the same API (take the token as the last part of the path, and send raw updates as text), bridges should be interchangeable.

I'm also wondering if it wouldn't be better to add the functionality to the base, yagop/node-telegram-bot-api, instead.

[kamikazechaser]

Yeah, we can just drop in yours. However this feature is a fancy feature, even though a better replacement to original webhooks, it cannot be added to node-telegram-bot-api, as people refer it to the official documentation.

[wojpawlik]

I could try creating PR.

Any preferences about websocket library (websocket / ws / something else)?

Also, how the user could enable and configure getting updates via websocket? I mean, probably passing options.websocket = url or options.tgfancy.websocket = url (which one?), but how would user sgnal that he wishes to use default bridge? By passing some constant instead of url perhaps?

And, before we get solid bridge server set up, we can use https://telegram-websocket-bridge-qalwkrjzzs.now.sh as default.

[GochoMugo]

As @kamikazechaser mentions, node-telegram-bot-api is more of a "driver" for the Telegram Bot API. It should do that one job, and do it perfectly! (/cc @yagop)

I have been comparing websocket and ws. I prefer ws as its code seems quite organised and better written.

The user would do something, like:

const bot = new Tgfancy(token, {
    tgfancy: {
        // enable websocket updates (i.e. this fanciness)
        websocket: true,
        // options for this fanciness
        websocketOptions: {
            url: "wss://custom-url.com", // for now, it may default to "https://telegram-websocket-bridge-qalwkrjzzs.now.sh/"
        },
    },
});

[yagop]

As @GochoMugonode-telegram-bot-api is justo a low Kevel API and I think we want to keep like that.

I would choose ws too. Much more popular BTW:

5.119.503 downloads in the last month Over 187.829 downloads in the last month

[wojpawlik]

@GochoMugo I see no point in having this split to 2 options (websocket and websocketOptions), seeing your comment, I'd suggest only having options.websocket; passing empty object to that would mean use defaults.

Also, one detail -- webhook is written like webHook, not webhook, so I think it'd be better to use webSocket for consistency.

const bot = new Tgfancy(token, {
    tgfancy: {
        // enable websocket updates (i.e. this fanciness)
        webSocket: {
            // if omitted (ie. empty object passed), uses default url
            url: "wss://custom-url.com",        },
    },
});

[GochoMugo]

Added in v0.8.0