Microsoft recently partnered with the makers of the Whim\u00a0service<\/a>\u00a0to\u00a0experiment with conversational user interfaces. Whim is a Mobility-as-a-Service (MaaS) solution\u00a0that allows people to leverage multiple kinds of transportation options with a single monthly fee. The makers of Whim found conversational interfaces interesting in the context of everyday mobility and\u00a0as an additional interaction channel with their service.<\/p>\n After exploring a few potential end-user scenarios, we decided to start building one of them using the Microsoft Bot Framework<\/a>. You can see the end result from this video<\/a>, which shows the basic features of the bot in action within Facebook Messenger.<\/p>\n One of the goals was to integrate the development and deployment of the related\u00a0components with the existing tools and practices of the\u00a0company. The implementation of the Whim service is heavily based on\u00a0serverless computing and leveraging the\u00a0Serverless framework<\/a>.<\/p>\n In this code story, we’ll talk about how we made it possible to\u00a0deploy a Node.js-based\u00a0bot using the Serverless framework and some challenges we had along the way.<\/p>\n <\/p>\n If you’d rather jump directly into the code, the Whim bot can be found on GitHub<\/a>.<\/p>\n The Serverless framework<\/a> is a set of tools that make it easier to\u00a0manage projects targeting serverless runtimes. It supports providers like Azure Functions, AWS Lamba, and\u00a0Apache OpenWhisk by implementing abstractions and helpers for things like configuration,\u00a0deployment, and debugging. At\u00a0a high level,\u00a0the steps to deploy a serverless project would be something like:<\/p>\n For more about using the Serverless framework, check out the documentation<\/a>.<\/p>\n Since the Whim backend was already using the AWS Lambda provider, the initial deployment targeted it. While the Microsoft Bot Framework is agnostic as to where a bot is hosted, we ran into two issues that needed to be fixed before the bot was functioning properly.<\/p>\n The first issue related to\u00a0the way authorization headers were passed between the systems. You can read more about the issue and our fix<\/a>\u00a0on GitHub. Afterward, the requests were properly authenticated\u00a0and reached the bot code from the Facebook Messenger channel as expected.<\/p>\n The second challenge was the differences between the request and response formats expected by the Serverless framework provider vs. the Microsoft Bot Framework. The basic usage is as follows:<\/p>\n You can see that\u00a0what connector.listen() returns above is directly given as a handler for the server created with the Restify framework. There is an assumption about what kind of request is passed to the bot framework code and how the bot framework code indicates when processing of the request has completed.<\/p>\n Restify uses common\u00a0request<\/a> and response<\/a> APIs that, for example, the popular Express framework<\/a> supports. However, this format isn’t what\u00a0serverless providers like AWS Lambda use.<\/p>\n Even though the format is not exactly the same, the concept is. As a result, it is possible to implement a small “glue code” in between the components to\u00a0achieve the desired functionality. You can see this solution in\u00a0an example<\/a>\u00a0from the AWS Lambda case.<\/p>\n The Whim API requires two-factor authentication before the bot can interact with it. The goal was to make the authentication as easy\u00a0as possible and make it feel well integrated into the overall Facebook Messenger experience.<\/p>\n For that, we leveraged the\u00a0Facebook Messenger Account Linking API<\/a>\u00a0through the Microsoft Bot Framework by using\u00a0channel-specific messages. You can read full details in\u00a0this blog post<\/a>.<\/p>\n User location is at the core of\u00a0the Whim service, so we paid specific attention to how we could provide the best location picking experience within Facebook Messenger. We achieved it by combining the suggested location from the service with the native location picker found within Facebook Messenger. You can see the implementation of this custom dialog on GitHub<\/a>.<\/p>\n As you can see, we were able to\u00a0use the Serverless framework to manage a Node.js bot project based on the Microsoft Bot Framework. In addition to managing the core bot project, the same tooling can be used to manage other serverless programs. For example, a bot project could\u00a0also include an image-processing component that is implemented as a separate “microservice.” The Serverless framework can help in managing\u00a0all these various pieces and how they are tied together.<\/p>\nDeployment with\u00a0Serverless framework<\/h2>\n
$ npm install -g serverless\r\n$ cd <your-serverless-project>\r\n\/\/ edit serverless.yml with your configurations\r\n$ serverless deploy<\/pre>\n
\/\/ Setup Restify Server\r\nvar server = restify.createServer();\r\nserver.listen(process.env.port || process.env.PORT || 3978, function () {\r\n console.log('%s listening to %s', server.name, server.url); \r\n});\r\n \r\n\/\/ Create chat connector for communicating with the Bot Framework Service\r\nvar connector = new builder.ChatConnector({\r\n appId: process.env.MICROSOFT_APP_ID,\r\n appPassword: process.env.MICROSOFT_APP_PASSWORD\r\n});\r\n\r\n\/\/ Listen for messages from users \r\nserver.post('\/api\/messages', connector.listen());<\/pre>\nOther challenges<\/h2>\n
User authentication<\/h3>\n
Determining location<\/h3>\n
Conclusion<\/h2>\n