Whether you are new to bot building or not, there is typically a big question you ask yourself whenever you start a new bot project: "How will I build it?"
That question usually begs a few more like: "Which messaging platform should I build it for?" "What programming language will I use to build it?," "Where will I host it?," and "Which bot framework should I use?"
Let's help by providing you with an overview of some of the different frameworks that are available for you to start building bots.
In today's development ecosystem, you are almost always using some kind of framework, especially for web development. If not, you would basically be manually sending cUrl requests to the different messaging platform APIs.
It's also important to specify what we mean by "framework." In this case, we consider "frameworks" as an additional layer of abstraction to a framework like ExpressJS, for example, with added features embedded within that framework to cater to bot developers solely - i.e., a bot framework or SDK.
Additionally, most bot frameworks are usually tied to a specific messaging service such as Facebook Messenger's Bot SDK or Microsoft's Bot Framework; or even Line, WeChat, Slack, and Viber's SDKs. The advantage here is that you know that the SDK is specifically thought out for that particular platform. However, it also means your bot will be tied solely to that specific messaging platform.
However, some bot SDKs like "Botkit", give you the ability to integrate your bot with multiple messaging platforms. This allows you to "build it once, deploy to all." Additionally, services like Message.io act as a gateway between your bot and the different messaging platforms' APIs to give you cross-platform interoperability.
It is true these bot frameworks provide simplicity and allow you to rapidly prototype a complex bot faster than if you were to solely rely on backend frameworks like ExpressJS. The main reason is that they bundle the requests (e.g., send message, receive message, send a file) into simple methods (that look almost like English!) and provide easy callback structure so as to create simple "hear-say" functions.
Take the example of a simple '/hello' command on Flint:
Another reason these bot frameworks provide added simplicity is they usually integrate at their core with middleware services and plugins, and take the hassle out of having to integrate them yourself with your backend framework (like ExpressJS).
For example, Botkit's available plugins span NLP, Storage, Stats, and CRM solutions with the popular API.AI (now DialogFlow), Wit.ai, IBM Watson, MongoDB, Firebase, or Keen.io. These "native" plugin integrations eliminate the hassle of having to import and integrate them yourself in a coherent logic (and ordered code!), as opposed to if you were to use more "bare bones" backend frameworks like ExpressJS.
The choice is yours, of course, and choosing to use these plugins and SDKs will most likely depend on your level of comfort with these services' APIs, the framework you're implementing them with, and how fast you write clean and ordered code.
On the other hand, the main advantage of NOT using these SDKs is that you get to organize and structure your code the way you choose to from the ground up. This can give you more flexibility - especially if you are planning to build an extremely complex bot - and also would likely make your codebase more lightweight (assuming you are actively refactoring to make it so or that you care at all about clean code!). Additionally, choosing not to use these bot frameworks allows you to not be tied to the plugin services that are available on them, and to import the ones of your choice as you please.
Comparing the Bot SDKs for Cisco Spark
As we've stated, you've got lots of options to work with. Here are three frameworks that you can use to build bots on the Cisco Spark platform, one specifically for use with Cisco Spark, the other two, multi-platform.
Description: The particularity of Gupshup is that it also provides you with a fully hosted development environment - like a Bot Builder IDE. It does a lot more than we need to cover here, but Gupshup also has a NodeJS SDK, hence the reason why we count it among the frameworks covered here.
Available Messaging Platforms: : Cisco Spark, Telegram, Hipchat, Skype, Kik, Line, Slack, and many more.
Available Plugins: API.AI (DialogFlow), Gupshup AI, Serverless Webview
Example of a hear-say command: Gupshup works a little differently than the other frameworks. In fact, Gupshup lets you create your own conversation logic as a scripting language.
The messaging handler will actually invoke the scripting handler method.
To wrap it all up, if you are satisfied with the plugin services offered by any of these bot frameworks we've referenced, AND that your bot uses many or most of the capabilities of these services, AND you are not too concerned about being 'lightweight', or, you just like the way they have structured the requests into something that sounds almost like English - go ahead and use them. Pick your framework and go build that new bot for Cisco Spark!
- Sacha Nacar, Sales Business Development Manager, Cisco Spark
Hello, Does anybody know why the Call Costume Variable Report does not match the number of Handle calls total from Contact Service Queue Activity Report? I have removed all Contact Disposition and focus on the Handle (2) calls and still, it doesn't m...
Hi allI wondering if anyone can help me with this issue. We have multiple UCCX11.6.2 HA clusters within our environment and have been having an issue with calls getting though the UCCX script queue and disconnecting when they are being presenting to ...
I have created a button to display when call is active and in agent in TALKING status but noticed button is displaying when Agent trying to Consult with other agent(since agent status is TALKING) and would need help on how to hide this button for Consults...
Setting up a small trial flow in CVP 12.5 to communicate with a Google DF agent. I find that when I use the DialogflowIntent and DialogflowParam elements that CVP ignores the text defined within Google DF and instead uses the local TTS defined in my call ...