RSS and Multi-FAQ Chatbot: Choices and Decisions (Part 2)

This post is part of a series of blog posts about a chat bot RazType™ that I implemented recently. Given that chat bots are advertised as a modern application that’s super easy to do, I decided to implement a prototype to learn through hands-on experience. There are 5 parts to this series:

  1. High Level Design (Part 1)
  2. Choices and Decisions (Part 2) — this post
  3. RSS Implementation Learnings (Part 3)
  4. FAQ Implementation Learnings (Part 4)
  5. Adding the Facebook Channel (Part 5)

Quick Disclaimer

In this post, I will be discussing some of the technical choices that I made — not as an expert, but rather, as a beginner. This is NOT an expert opinion and does not represent the organization that I work for. Actually, this disclaimer is true for all my blog posts, but I just had to reemphasize it here.

C# vs Node.js

Bot Service provides an integrated environment that is purpose-built for bot development, enabling you to build, connect, test, deploy, and manage intelligent bots, all from one place. Azure Bot Service leverages the Bot Builder SDK with support for .NET and Node.js.

Source: (v4 was not yet GA when I was working on this)

I had 2 choices, C# or Node.js

  • C#: I have 10+ years of C# software delivery experience. It is practically the language that I used day in and day out from my undergraduate until a few years ago. I wouldn’t exactly call myself an expert, but definitely a tenured and proficient C# developer. (Public documentation for C# is found here.)
  • Node.js: <1 year learning experience with 0 actual software delivery experience. But most of the people I work with today use Node.js more than C#. Node.js is also supported by most (if not all) Azure services. (Public documentation for Node.js is found here.)

Another consideration was the availability of sample code. I find sample codes as a great supplement to public documentation. I didn’t have a lot of issues here since Microsoft shared public repositories with samples for both languages.


My choice: Node.js

I took this as a good opportunity to learn Node.js. I also wanted to get accustomed to Visual Studio Code as the IDE.

Web App Bot vs Functions Bot

There are 2 options when creating the actual Azure Bot Service resource:


Web App Bot is basically hosted in an Azure App Service, where the price is based on an App Service Plan.

Functions Bot is hosted in Azure Functions, which is a cool serverless computing option. The price is free for <1 million executions per month, which means that using this is almost always free for POCs.

Given that Functions Bot is cool and new, I really preferred it. Here were my considerations:

Consideration #1: Quick Local Development

I need to run my code locally, test against it, and set breakpoints for debugging. I also need the Bot Framework Emulator to send chat messages and see how the bot responds.

With Azure Functions though, I found out that this wasn’t so simple. In order to run functions locally, the installation of Azure Functions Core Tools is required. This includes having to figure out how to properly create and configure a local functions project.

This was really a struggle as there is no clear instruction on how to do this in the Bot Service documentations page (at least at the time of this writing). After spending a lot of time figuring out how to run functions locally, I decided to move on.

Consideration #2: Continuous Delivery

I wanted to have continuous delivery. Having my code immediately deployed after every push allows me to quickly test how my bot will respond in Facebook Messenger. The documentations page shows clear, step-by-step, instructions on how to do this.

Unfortunately, it wasn’t that simple for Functions Bot. My code was deploying “successfully”, but the bot responses weren’t changing. After spending a few more hours and asking the Azure community, I learned that I needed to package my code using Azure Functions Pack before deployment.



Now I did consider creating a custom release pipeline using Azure DevOps. This is totally possible but will take some time to do.

Final Decisions: Web App Bot using Node.js

Given the above 2 considerations, I decided to keep it simple and go with Web App Bot using Node.js.

Web Apps made local development a lot simpler. I just needed to run npm start and that’s it. I even used nodemon which made local Node.js development even easier.

I also had an easier time configuring for continuous delivery, since the step-by-step documentation works perfectly.

Learning Node.js was kind of a personal secondary objective. I really wanted to gain more experience with this beautiful runtime engine. Given that it is easier to create a Web App Bot with Node.js, this further stengthened my decision of choosing Web App Bots.

Up next: Implementation Learnings (coming soon)

This post is licensed under CC BY 4.0 by the author.