Picking Your Framework to Build Bots on Cisco SparkFebruary 5 2018
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: NodeJS bot SDK specifically for Cisco Spark with native persistent storage.
Available Messaging Platforms: Cisco Spark only
Available Plugins: Persistent storage (native)
Example of a hear-say command:
Description: Fully fledged multi-platform bot SDK and framework with connectors to various services for NLP, Stats, and CRM.
Available Messaging Platforms: Cisco Spark, Slack, Facebook Messenger, Twilio SMS, Microsoft Teams
Available Plugins: Microsoft Luis, Api.ai, IBM Watson, Recast.ai, Wit.ai, Rasa, Mongo, Redis, Datastore, Firebase, Postgres, CouchDB, Botimize, Botkit Studio Metrics, Botmetrics, Dashbot Facebook, Dashbot Slack, Keen, Wordhop
Example of a hear-say command:
Language: NodeJS & Java
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!