Comparing version 1.1.0 to 1.1.1
@@ -5,5 +5,5 @@ ## Should I use botmaster or botkit? | ||
Use Botmaster If you want to build platform agnostic conversational bots using a system like Wit.ai or Watson conversation [or your own system] to manage 1 on 1 conversations (On Messenger, Twitter, Telegram for now). e.g. a personal assistant, customer support etc. | ||
Use Botmaster If you want to build platform agnostic conversational bots using a system like Watson Conversation [or your own system] to manage 1 on 1 conversations (On Messenger, Twitter, Telegram for now). e.g. a personal assistant, customer support etc. | ||
Use Botkit if you want to build platform dependant bots on either Slack or Twilio IPM while managing simple conversations based on regex or also more complex ones using again Watson Conversation or wit etc. | ||
Use Botkit if you want to build platform dependant bots on either Slack or Twilio while managing simple conversations based on regex or also more complex ones using again Watson Conversation or wit etc. | ||
@@ -66,3 +66,3 @@ ### Main article | ||
Because of the nature of Twilio and the nature of channels and how they are dealt with, this only makes sense. We'll look at what other differences this brings in the next section. | ||
Because of the nature of Twilio and the nature of channels and how they are dealt with, this makes sense. We'll look at what other differences this brings in the next section. | ||
@@ -124,4 +124,6 @@ | ||
Because of the fixed endpoint and the fact that Botkit does not (according to their code as of today) verify the integrity of the requests using the Facebook App Secret, I would advise against using it as this means that anyone can make a request to https://YOUR_SERVER:PORT_CHOSEN/facebook/receive and fake requests from Facebook. | ||
NOTE: Because of the fixed endpoint and the fact that Botkit does not (according to their code as of Aug 18th 2016) verify the integrity of the requests using the Facebook App Secret, I would advise against using it as this means that anyone can make a request to https://YOUR_SERVER_URL:PORT_CHOSEN/facebook/receive and fake requests from Facebook. | ||
Of course, you can have multiple controllers in your app. But you will have to manage the various types of incoming messages. | ||
Botmaster does not have this concept of a controller. In fact, if you are coming from Botkit, you can think of Botmaster as a sort of supercontroller from which you can create a bot of any type as in this example: | ||
@@ -158,35 +160,66 @@ | ||
express app object | ||
Working with webhooks | ||
--- | ||
Both frameworks either expect an express() app object to be passed as argument either after controller creation in Botkit as such: | ||
In order to receive messages, some platforms make the use of webhooks. Which means they will send requests to some endpoints on your server. In order to do that, both frameworks make the use of express() app objects under the hood. Botkit does so for Messenger, Twilio IPM and some of the Slack solutions. Botmaster does do for Messenger and Telegram (for now). | ||
The standard way to deal with this in Botkit is the following: | ||
```js | ||
const port = 3000; | ||
controller.setupWebserver(port, function(err, webserver) { | ||
controller.createWebhookEndpoints(webserver) | ||
}); | ||
``` | ||
As you can see, this will create an express() webserver and send it onto the `createWebhookEndpoints` function. The server will now listen onto the `facebook/receive` endpoint on port 3000 if it is a Messenger controller. It will listen onto the `'/twilio/receive'` for Twilio IPM and `'/slack/receive'` for Slack (if using one of the services that uses webhooks). | ||
Of course, you might want to use your own express() app webserver to use accross multiple controllers or to serve all sorts of other purposes. You would do this like that in Botkit: | ||
```js | ||
const express = require('express'); | ||
const app = express(); | ||
var bodyParser = require('body-parser'); | ||
const bodyParser = require('body-parser'); | ||
app.use(bodyParser.json()); | ||
app.use(bodyParser.urlencoded({ extended: true })); | ||
... | ||
. | ||
. | ||
. | ||
controller.createWebhookEndpoints(app, bot, () => { | ||
console.log('This bot is online!!!'); | ||
}); | ||
app.listen(3000, function() { | ||
console.log('Server up'); | ||
}); | ||
``` | ||
Or during botmaster object instantiation in Botmaster as such: | ||
In Botmaster, instantiating a botmaster object, will by default just start an express server under the hood for you and make it listen onto port 3000. If you want it to listen onto another port, you can just do something like this when instantiating botmaster: | ||
``` | ||
const port = 3001; | ||
const botmaster = new Botmaster({ settings: botsSettings, | ||
port: port }); | ||
``` | ||
The webhook endpoints will be set according to your settings. Go to [webhooks](Readme.md#webhooks) in the main readme to read some more about webhooks in Botmaster. | ||
In order to use your own express app, you would do as follows in Botmaster. | ||
```js | ||
const express = require('express'); | ||
const app = express(); | ||
... | ||
const bodyParser = require('body-parser'); | ||
app.use(bodyParser.json()); | ||
app.use(bodyParser.urlencoded({ extended: true })); | ||
. | ||
. | ||
. | ||
const botmaster = new Botmaster({settings: botsSettings, | ||
app: app}); | ||
``` | ||
Both then expect the server to be started by you in this case. So you would have something like this in your code: | ||
```js | ||
app.listen(3000, function() { | ||
@@ -197,20 +230,5 @@ console.log('Server up'); | ||
If this isn't done in Botkit, they expect you to manually start it using their builtin methods: | ||
By default, Botkit will use different express app webservers for each controller. Botmaster, as mentioned earlier, is a sort of supercontroller. Because of that, it uses the same express webserver accross all channels by default. | ||
```js | ||
Controller.setupWebserver(3000,function(err,webserver) { | ||
Controller.createWebhookEndpoints(bController.webserver, bBot, function() { | ||
console.log('This bot is online!!!'); | ||
}); | ||
}); | ||
``` | ||
If unspecified in Botmaster, it will just start an express server under the hood for you and make it listen onto port 3000. If you want it to listen onto another port, you can just do something like this when instantiating botmaster: | ||
``` | ||
const port = 3001; | ||
const botmaster = new Botmaster({settings: botsSettings, | ||
port: port}); | ||
``` | ||
Supported Platforms | ||
@@ -227,8 +245,8 @@ --- | ||
conversations | ||
Conversations | ||
--- | ||
Botkit allows developers to specify a deterministic conversation flow within the code to simplify such flows. This is definitely handy and something that can help when creting Slack and Twilio bots | ||
Botkit allows developers to specify a deterministic conversation flow within the code to simplify such flows. This is definitely handy and something that can help when creating Slack and Twilio bots | ||
Because Botmaster was initialy built mainly as a standardization agnostic layer that assumes your messages will be sent to some sort of AI service like Watson conversation and others, this hasn't been builtin to the first version. This is however something that will come soon (in a different form from the ones in Botkit). Depending on requests however, it could come sooner or later. | ||
Because Botmaster was initialy built mainly as a standardization agnostic layer that assumes your messages will be sent to some sort of AI service like Watson Conversation and others, this hasn't been builtin to the first version. This is however something that will come soon (in a different form from the ones in Botkit). Depending on requests however, it could come sooner or later. | ||
@@ -235,0 +253,0 @@ Conclusion |
@@ -30,6 +30,10 @@ 'use strict'; | ||
botId: update.recipient.id, | ||
latestMid: update.message.mid, | ||
latestSeq: update.message.seq, | ||
lastActive: update.timestamp, | ||
}; | ||
if (update.message) { | ||
session.latestMid = update.message.mid; | ||
session.latestSeq = update.message.seq; | ||
} | ||
this.sessions[id] = session; | ||
@@ -51,2 +55,7 @@ resolve(session); | ||
if (update.message) { | ||
session.latestMid = update.message.mid; | ||
session.latestSeq = update.message.seq; | ||
} | ||
resolve(session); | ||
@@ -53,0 +62,0 @@ }); |
{ | ||
"name": "botmaster", | ||
"version": "1.1.0", | ||
"version": "1.1.1", | ||
"description": "Framework allowing developers to write bots that are agnostic with respect to the channel used by their users (messenger, telegram etc...)", | ||
@@ -5,0 +5,0 @@ "main": "./lib/index.js", |
130
Readme.md
@@ -5,7 +5,7 @@ # Botmaster | ||
Botmaster is platform agnostic in two important ways. Firstly, in its current state, developers can have bots running on Facebook Messenger, Twitter DM and Telegram - with just one integration. Secondly, BotMaster makes no assumptions about the back-end bot itself - you can write code that allows BotMaster to call engines such as IBM Watson, open source frameworks or even write the bot yourself. | ||
Botmaster is platform agnostic in two important ways. Firstly, in its current state, developers can have bots running on Facebook Messenger, Twitter DM and Telegram - with just one integration. Secondly, BotMaster makes no assumptions about the back-end bot itself - you can write code that allows BotMaster to call conversational engines such as IBM Watson's conversation API, open source frameworks or even write the conversation engine yourself. | ||
Its philosophy is to minimise the amount of code developers have to write in order to create a 1-on-1 conversational chatbot that works on multiple different platforms. It does so by defining a standard with respect to what format messages take and how 1-on-1 conversations occur. Messages to/from the various messaging apps supported are all mapped onto this botmaster standard, meaning the code you write is much reduced when compared to a set of point:point integrations. | ||
Its philosophy is to minimise the amount of code developers have to write in order to create a 1-on-1 conversational chatbot that works on multiple platforms. It does so by defining a standard with respect to what format messages take and how 1-on-1 conversations occur. Messages to/from the various messaging channels supported are all mapped onto this botmaster standard, meaning the code you write is much reduced when compared to a set of point:point integrations. | ||
## install | ||
## Install | ||
@@ -17,3 +17,3 @@ ```bash | ||
## Quick start | ||
(Go to 'Getting set up' to see how to get all the required credentials) | ||
(Go to [Getting set up](#getting-set-up) to see how to get all the required credentials) | ||
```js | ||
@@ -28,3 +28,3 @@ | ||
pageToken: 'YOUR pageToken', | ||
fbAppSecret: 'YOUR fbAppSecret' | ||
fbAppSecret: 'YOUR fbAppSecret', | ||
}, | ||
@@ -35,2 +35,3 @@ webhookEndpoint: '/webhook1234', // botmaster will mount this webhook on https://Your_Domain_Name/messenger/webhook1234 | ||
const twitterSettings = { | ||
credentials: { | ||
consumerKey: 'YOUR consumerKey', | ||
@@ -58,3 +59,3 @@ consumerSecret: 'YOUR consumerSecret', | ||
// you can pass in a port argument here to change this default setting: | ||
port: 3001 | ||
port: 3001, | ||
} | ||
@@ -66,10 +67,3 @@ | ||
botmaster.on('update', (bot, update) => { | ||
bot.sendMessage({ | ||
recipient: { | ||
id: update.sender.id, | ||
}, | ||
message: { | ||
text: 'Right back at you!', // yes, this bot doesn't really do anything smart | ||
}, | ||
}); | ||
bot.sendTextMessageTo('Right back at you!', update.sender.id); | ||
}); | ||
@@ -85,3 +79,3 @@ | ||
As you can see here, the Botmaster constructor takes a botmasterSettings argument. | ||
As you can see above, the Botmaster constructor takes a `botmasterSettings` argument. | ||
This object is of the following form: | ||
@@ -106,3 +100,3 @@ | ||
I.e. it is an array of single key objects. Where you specify the type as the key of each object and the settings is is the value. Here I show that you can define multiple bots of the same type at once (twitter ones in this example). As you surely guessed, each different platform will expect different credentials. So platform specific settings will differ. | ||
I.e. it is an array of single key objects. Where you specify the type as the key of each object and the settings as the value. Here I show that you can define multiple bots of the same type at once (twitter ones in this example). As you surely guessed, each different platform will expect different credentials. So platform specific settings will differ. | ||
@@ -118,5 +112,5 @@ ### Getting set up with Messenger | ||
pageToken: 'YOUR pageToken', | ||
fbAppSecret: 'YOUR fbAppSecret' | ||
fbAppSecret: 'YOUR fbAppSecret', | ||
}, | ||
webhookEndpoint: '/webhook1234' | ||
webhookEndpoint: '/webhook1234', | ||
}; | ||
@@ -128,5 +122,5 @@ ``` | ||
In step 2, where you setup your webhook, no need to code anything. Just specify the webhook, enter any secure string you want as a verify token and copy that value in the settings object. | ||
In step 2, where you setup your webhook, no need to code anything. Just specify the webhook, enter any secure string you want as a verify token and copy that value in the settings object. Also, click on whichever message [update] type you want to receive from Messenger (`message_deliveries`, `messages`, `message_postbacks` etc...). | ||
If you are not too sure how webhooks work and/or how to get it to run locally, go to the section about webhooks. | ||
If you are not too sure how webhooks work and/or how to get them to run locally, go to [webhooks](#webhooks) to read some more. | ||
@@ -148,5 +142,5 @@ ### Getting set up with Telegram | ||
Basically, you'll need to send a '/newbot' command to Botfather (go talk to him [here](https://web.telegram.org/#/im?p=@BotFather)). Once you're done with giving it a name and a username, BotFather will come back to you with your authToken. Make sure to store it somewhere. More info on BotFather can be found [here](https://core.telegram.org/bots#create-a-new-bot ) if needed. | ||
Basically, you'll need to send a `/newbot` command(message) to Botfather (go talk to him [here](https://web.telegram.org/#/im?p=@BotFather)). Once you're done with giving it a name and a username, BotFather will come back to you with your authToken. Make sure to store it somewhere. More info on BotFather can be found [here](https://core.telegram.org/bots#create-a-new-bot ) if needed. | ||
And you can find the telegram api docs [here](https://core.telegram.org/bots/api) | ||
For more on Telegram, you can find the telegram api docs [here](https://core.telegram.org/bots/api) | ||
@@ -161,3 +155,3 @@ Setting up your webhook requires you to make the following request outside of Botmaster (using curl for instance or a browser): | ||
If you are not too sure how webhooks work and/or how to get it to run locally, go to the section about webhooks. | ||
If you are not too sure how webhooks work and/or how to get it to run locally, go to [webhooks](#webhooks) to read some more. | ||
@@ -170,2 +164,3 @@ ### Getting set up with Twitter | ||
const twitterSettings = { | ||
credentials: { | ||
consumerKey: 'YOUR consumerKey', | ||
@@ -188,10 +183,10 @@ consumerSecret: 'YOUR consumerSecret', | ||
* Navigate to the somewhat hard to find Twitter developer app dashboard at: https://apps.twitter.com/ | ||
* Click Create New App. Enter your details (callback URL is not required if you are starting from scratch here). Website can take in a placeholder like (http://www.example.com) | ||
* Now navigate straight (do this before going to the 'Keys and Access Tokens' page). Select 'Read, Write and Access direct messages' and then click 'Update Setting' | ||
* Navigate to the 'Read, Write and Access direct messages'. You'll find your consumerKey and consumerSecret right here | ||
* Click Create New App. Enter your details (callback URL is not required if you are starting from scratch here). 'Website' can take in a placeholder like (http://www.example.com) | ||
* Now navigate straight to the 'Permissions' tab(do this before going to the 'Keys and Access Tokens' tab). Select 'Read, Write and Access direct messages' and then click 'Update Setting' | ||
* Navigate to the 'Keys and Access Tokens' tab. You'll find your consumerKey and consumerSecret right here | ||
* Scroll down and click on 'Create my access token'. You now have your accessToken and your accessTokenSecret | ||
! Makes sure not to create your access token before havng reset your permissions. If you do that, you will need to change your permissions then regenerate your access token. | ||
! Makes sure not to create your access token before having reset your permissions. If you do that, you will need to change your permissions then regenerate your access token. | ||
That should about do. Because twitter DM is not completely separate from the rest of Twitter, it behaves quite differently than the other platforms on many aspects. All the points will be mentioned in the rest of this doc. | ||
That should about do it. Because twitter DM is not completely separate from the rest of Twitter, it behaves quite differently from the other platforms on many aspects. All the points will be mentioned in the rest of this doc. | ||
@@ -201,3 +196,3 @@ | ||
Now that you have your settings, you can go ahead and create a botmaster object. This essentially 'starts' botmaster. Doing so will look a little something like this: | ||
Now that you have your settings, you can go ahead and create a botmaster object. This essentially 'starts' botmaster. Briefly rehearsing what was mentioned in the 'Getting set up' section, doing so will look a little something like this: | ||
@@ -228,6 +223,6 @@ ```js | ||
|--- |--- | ||
| botsSettings | An `array` of platform specific settings. See 'Getting set up' for more info on that | ||
| port | (__optional__) The port to use for your webhooks (see the below 'webhooks' to understand more about webhooks). This will only be used if the `app` parameter is not provided. Otherwise, it will be ignored | ||
| app | (__optional__) An `express.js` app object to mount the webhookEnpoints onto. If you choose to do this, it is assumed that you will be starting your own express server and this won't be done by Botmaster. | ||
| sessionStore | (__optional__) a `sessionStore` object to store basic context and information about the bot and the updates it receives. See the 'session' section below to understand more about sessions | ||
| botsSettings | An `array` of platform specific settings. See [Getting set up](#getting-set-up) for more info on that | ||
| port | (__optional__) The port to use for your webhooks (see [webhooks](#webhooks) to understand more about webhooks). This will only be used if the `app` parameter is not provided. Otherwise, it will be ignored | ||
| app | (__optional__) An `express.js` app object to mount the `webhookEnpoints` onto. If you choose to do this, it is assumed that you will be starting your own express server and this won't be done by Botmaster. | ||
| sessionStore | (__optional__) a `sessionStore` object to store basic context and information about the bot and the updates it receives. See the [session](#sessions) section below to read more about sessions | ||
@@ -250,3 +245,3 @@ ### Events | ||
I am registering two new listeners onto the botmaster object. One that listens for any updates that come in and one that listens for any potential error that might occur when receiving updates. The `update` events is of course the one you will want to focus most of your attention onto. You see here that every `update` event will come with a `bot` and an `update` in the arguments. This will always be the case. In general, the updates are standardized as well as the methods to use from the bot object (i.e. sending a message). | ||
I am registering two new listeners onto the botmaster object. One that listens for any updates that come in and one that listens for any potential error that might occur when receiving updates. The `update` events is of course the one you will want to focus most of your attention onto. You see here that every `update` event will come with a `bot` and an `update` object as arguments. This will always be the case. In general, the updates are standardized as well as the methods to use from the bot object (i.e. sending a message). | ||
@@ -257,7 +252,7 @@ ### Bot object | ||
Bot instances can be accessed through that array or more commonly, directly within an `update` event. Because you might want to act differently on bots of a certain type or log information differently, every bot comes with a `bot.type` parameter that is one of: `messenger`, `twitter` or `telegram` (for now). Use these to write more platform specific code (if necessary). | ||
Bot instances can be accessed through that array or more commonly, directly within an `update` event. Because you might want to act differently on bots of a certain type or log information differently based on type, every bot comes with a `bot.type` parameter that is one of: `messenger`, `twitter` or `telegram` (for now). Use these to write more platform specific code (if necessary). | ||
I'll note quickly that each bot object created comes from one of the `TelegramBot`, `MessengerBot` or `Twitterbot` classes. They act in the same way on the surface (because of heavy standardization), but have a few idiosynchrasies here and there. | ||
You can also create bot object directly from their base classes. Here is an example of creating a twitter bot. | ||
You can also create bot objects directly from their base classes. Here is an example of creating a twitter bot. | ||
@@ -278,3 +273,3 @@ ```js | ||
All bot items are also eventEmitters. So you will be able to do something like this: | ||
All bot items are also of the EventEmitters class. So you will be able to do something like this: | ||
@@ -294,3 +289,3 @@ ```js | ||
``` | ||
This is important if you create your own Bot that extends the `Botmaster.botTypes.BaseBot` class. For instance, you might want to create your own class that supports your pre-existing messaging standards. Have a look in the `writing_a_botmaster_supported_bot-class.ms` file to learn how to do this. | ||
This is important if you create your own Bot that extends the `Botmaster.botTypes.BaseBot` class. For instance, you might want to create your own class that supports your pre-existing messaging standards. Have a look at the [writing_a_botmaster_supported_bot-class.md](writing_a_botmaster_supported_bot_class_readme.md) file to learn how to do this. | ||
@@ -303,3 +298,3 @@ ## Message/Update format | ||
### incoming update | ||
### Incoming update | ||
@@ -333,5 +328,5 @@ Typically, it would look something like this for a message with an image attachment. Independant of what platform the message comes from: | ||
This allows developers to handle these messages in on place only rather than doing it in multiple places. For more info on the various incoming messages formats, read the messenger bot doc on webhooks at: https://developers.facebook.com/docs/messenger-platform/webhook-reference/message-received. | ||
This allows developers to handle these messages in one place only rather than doing it in multiple places. For more info on the various incoming messages formats, read the messenger bot doc on webhooks at: https://developers.facebook.com/docs/messenger-platform/webhook-reference/message-received. | ||
Currently, you will only get updates for `Messages` for all platforms. On Messenger, it is assumed that you don't want to get updates for delivery, read and echo. This can't be turned on at the moment, but will be in later versions as it might be a requirement. | ||
Currently, you will only get updates for `Messages` (and not delivery, echo notification etc) for all platforms. On Messenger, it is assumed that you don't want to get updates for delivery, read and echo. This can't be turned on at the moment, but will be in later versions as it might be a requirement. | ||
@@ -349,7 +344,7 @@ #### Note on attachment types and conversions | ||
Also, here's an important caveat for Twitter bot developers who are receiving attachments. Image links that come in from the Twitter API will be private and not public, which makes using them quite trky. You might need to make authenticated requests to do so. The twitterBot objects you will receive in the update will have a `bot.twit` object. Documentation for how to use this is available [here](https://github.com/ttezel/twit). | ||
Also, here's an important caveat for Twitter bot developers who are receiving attachments. Image links that come in from the Twitter API will be private and not public, which makes using them quite tricky. You might need to make authenticated requests to do so. The twitterBot objects you will receive in the update will have a `bot.twit` object. Documentation for how to use this is available [here](https://github.com/ttezel/twit). | ||
Attachment type conversion works as such for __Telegram__: | ||
| Twitter Type | Botmaster conversion | ||
| Telegram Type | Botmaster conversion | ||
|--- |--- | ||
@@ -367,3 +362,3 @@ | audio | audio | ||
### outgoing messages | ||
### Outgoing messages | ||
@@ -401,3 +396,3 @@ Again, outgoing messages are expected to be formatted like messages the Messenger platform would expect. They will typically look something like this for a text message: | ||
Because you might not always want to write in a complex json object just to send in a simple text message or photo attachment, Botmaster comes with a few methods that can be used to send messages with less code: | ||
Because you might not always want to code in a complex json object just to send in a simple text message or photo attachment, Botmaster comes with a few methods that can be used to send messages with less code: | ||
@@ -519,3 +514,3 @@ `bot.sendMessageTo` | ||
The function defaults to sending `quick_replies` in Messenger, setting Keyboard buttons in Telegram and simply prints button titles one on each line in Twitter as it deosn't support buttons. The user is expecting to type in their choice in Twitter. | ||
The function defaults to sending `quick_replies` in Messenger, setting `Keyboard buttons` in Telegram and simply prints button titles one on each line in Twitter as it deosn't support buttons. The user is expecting to type in their choice in Twitter. | ||
@@ -549,2 +544,3 @@ | ||
}); | ||
``` | ||
@@ -632,3 +628,3 @@ Here we simply added the sessionStore object to our settings passed into the Botmaster constructor. | ||
## webhooks | ||
## Webhooks | ||
@@ -689,2 +685,38 @@ Most platforms rely on webhooks to work. As such, you are expected to setup webhooks on the various platforms that use them in order to use Botmaster with these platforms. In the 'Getting set up' part of this documentation, we briefly touched onto that for Telegram and it is mentioned in one of the steps in the Messenger documentation. | ||
If you keep on getting an error that looks like this: | ||
```bash | ||
your url is: https://customname.localtunnel.me | ||
/usr/local/lib/node_modules/localtunnel/bin/client:58 | ||
throw err; | ||
^ | ||
Error: connection refused: localtunnel.me:44404 (check your firewall settings) | ||
at Socket.<anonymous> (/usr/local/lib/node_modules/localtunnel/lib/TunnelCluster.js:47:32) | ||
at emitOne (events.js:96:13) | ||
at Socket.emit (events.js:188:7) | ||
at emitErrorNT (net.js:1272:8) | ||
at _combinedTickCallback (internal/process/next_tick.js:74:11) | ||
at process._tickCallback (internal/process/next_tick.js:98:9) | ||
``` | ||
This is due to a bug in localtunnel. You can either go try out ngrok (which you will have to pay for), or try this workaround in the terminal: | ||
```bash | ||
(while true; do | ||
lt -p 3000 -s botmastersubdomain | ||
done) | ||
``` | ||
or | ||
```bash | ||
( while true; do; lt -p 3000 -s botmastersubdomain; done; ) | ||
``` | ||
If you prefer a one liner. | ||
This will just restart the process whenever it crashes (which can happen very often...), making sure your webhook will always be up and listening for incoming requests. | ||
## Using Botmaster with your own express() object | ||
@@ -750,1 +782,5 @@ | ||
## License | ||
This library is licensed under the MIT [license](LICENSE) | ||
@@ -27,3 +27,3 @@ # Bot classes | ||
You would then be expected to mount your bots express `.app` onto your own express `app` by doing something like this: | ||
You would then be expected to mount your bot's express mini-app `messengerBot.app` onto your own express `app` by doing something like this: | ||
@@ -40,3 +40,3 @@ | ||
## Making Botmaster objects and bot objecst work together | ||
## Making Botmaster objects and bot objects work together | ||
@@ -47,4 +47,4 @@ In the main`Readme.md` we saw how botmaster objects return a bot object along with every update it receives. I.e. something like this happens: | ||
botmaster.on('update', (bot, update) => { | ||
console.log(bot.type); | ||
console.log(update); | ||
console.log(bot.type); | ||
console.log(update); | ||
}); | ||
@@ -84,5 +84,5 @@ ``` | ||
In this example the botmaster object will start a new express() app server running locally on port 3000 as expected. However, we later want to add to botmaster the object we created in the first section, namely, `messengerBot`. | ||
In this example the `botmaster` object will start a new `express()` `app` server running locally on port `3000` as expected by default. However, we later might want to add to botmaster the object we created in the first section, namely, `messengerBot`. | ||
We can achieve this by doing this: | ||
We can achieve this by doing the following: | ||
@@ -93,3 +93,3 @@ ```js | ||
This will mount your bot onto: `https://Your_Domain_Name/messenger/webhook1234`. Note how the bot type __is__ part of the endpoint here. This is because the Botmaster class assumes that you want your endpoint to be mounted onto its botType. This is just another way in which Botmaster is opinionated. | ||
This will mount your bot onto: `https://Your_Domain_Name/messenger/webhook1234`. Note how the bot type __is__ part of the endpoint here. This is because the Botmaster class assumes that you want your endpoint to be mounted onto its botType. | ||
@@ -105,3 +105,3 @@ You will then get updates from the botmaster object as if you had instantiated it with the messenger settings too. | ||
### `constructor(settings)` | ||
### `#constructor(settings)` | ||
@@ -127,17 +127,17 @@ ```js | ||
Let's look into this line by line. The first line reads `super(settings)`. Which of course just means it calls the constructor of `TelegramBot`'s superclass, namely, BaseBot. `BaseBot`'s constructor doesn't actually do anything fancy a part from calling its own superclass's constructor and settings a few default values [as pointers for you]. BaseBot calls its own superclass's constructor as it inherits from node.js's `EventEmitter` which will allow your bot's classes to listen to events as well as emit them. | ||
Let's look into this line by line. The first line reads `super(settings)`. Which of course just means it calls the constructor of `TelegramBot`'s superclass, namely, BaseBot. `BaseBot`'s constructor doesn't actually do anything fancy a part from calling its own superclass's constructor and setting a few default values [as pointers for you, the developer]. BaseBot calls its own superclass's constructor as it inherits from node.js's `EventEmitter` which will allow your bot's classes to listen to events as well as emit them. | ||
The following three lines setup some important values. | ||
1. `this.type`: the type of bot that is being instantiated. It's omportant to specify that as developers might want condition some code on the type of bot you are writing. | ||
1. `this.type`: the type of bot that is being instantiated. It's important to specify that as developers might want condition some code on the type of bot you are writing. | ||
2. `this.requiresWebhook`: whether the bot requires webhooks. If the platform you are coding for requires webhooks, you will be expected to set a `this.app` variable at some point in the setup. We'll look into this when we have a look at what the `this.__createMountPoints();` does. | ||
3. `this.requiredCredentials`: sets up an array of credentials that are expected to be defined for the platform you are coding your class for. Telgram only takes in 1, so we just have an array with the value `'authToken'`. | ||
### `__applySettings(settings)` | ||
### `#__applySettings(settings)` | ||
The next line calls the `this.__applySettings(settings)`. This function is implemented in BaseBot and will just make sure that the settings passed on to the bot constructor are valid with respect to the parameters you defined. You should always call this function directly after setting the three [or more if you want] parameters specific to the platform you are coding for. If valid, the settings will then be applied to the bot object. e.g. `this.webhookEndpoint` will be set to `settings.webhookEndpoing`. | ||
### `__createMountPoints()` | ||
### `#__createMountPoints()` | ||
The last line of our controller makese a call to `this.__createMountPoints();`. This line should only be present if your bo class requires webhooks. If this is the case, you will be expected to define a class member function that looks like: | ||
The last line of our controller makese a call to `this.__createMountPoints();`. This line should only be present if your bot class requires webhooks. If this is the case, you will be expected to define a class member function that looks like: | ||
@@ -168,7 +168,7 @@ ```js | ||
very importantly, this function creates an express router `this.app` that will be mounted onto the main `app` router from the botmaster object if `botmaster.addBot` is used. | ||
Very importantly, this function creates an express router `this.app` that will be mounted onto the main `app` router from the botmaster object if `botmaster.addBot` is used. | ||
It then sets up the post endpoint that listens onto `this.webhookEnpoint`. No further assumption is made here. | ||
### `__formatUpdate(rawUpdate)` | ||
### `#__formatUpdate(rawUpdate)` | ||
@@ -180,3 +180,2 @@ Although you can technically handle the body of the request as you wish. In our example here (the TelegramBot code), we make a call to the `__formatUpdate` function with the body of the request. | ||
```js | ||
Typically, it would look something like this for a message with an image attachment. Independant of what platform the message comes from: | ||
@@ -211,7 +210,7 @@ | ||
### `__emitUpdate(update)` | ||
### `#__emitUpdate(update)` | ||
Like `__applySettings`, this method is implemented in `BaseBot`. It handles errors, setting up the session to the update if sessionStore is set, and most importantly, actually calling `this.emit(update)` to emit the actual update. You can overwrite this method is you wish, but in its current state, it handles the most important cases you will want to deal with. | ||
### `sendMessage(message)` | ||
### `#sendMessage(message)` | ||
@@ -242,3 +241,3 @@ All previous methods had either something to do with object instantiation or with incoming messages. We'll now have a look at what needs to be done within your bot class to send messages. | ||
### `__formatOutgoingMessage(message)` | ||
### `#__formatOutgoingMessage(message)` | ||
@@ -245,0 +244,0 @@ Your `sendMessage` methos is expected to call a `__formatOutgoingMessage(message)` method that will format the Messenger style message into one that is compatible with the platform your are coding your bot class for. |
154097
2954
757