Skip to main content

This is a repost that originally appeared on the Couchbase Blog: Chatbot on Azure and Couchbase for Viber.

A chatbot can be a novel way to interact with users. After writing a post introducing the basics of serverless, and also writing a post on writing Azure Functions, I decided I would try to build something a little more practical than a "hello, world".

Using a serverless architecture for a chatbot makes sense. Chatbot usage may be sporadic. Usage may peak and drop at various times of the day. By using serverless, you’ll only be paying for the resources and time that you need.

If you want to follow along, all the source code for this blog post is available on Github.

Viber Chatbot

I could have chosen a lot of different platforms to create a chatbot for: Facebook Messenger, Skype, WhatsApp, and more. But I decided to go with Viber.

In the United States, Viber doesn’t seem to have a huge following, but I’ve been using it a lot. It’s a very handy way to chat with my wife, send pictures, funny GIFs, and so on. I find it to be more reliable and faster than SMS, especially for pictures. I wish everyone in my family was using it! It’s also a nice side effect that Viber is a Couchbase customer. They switched from MongoDb to support their growing data needs.

Also, Viber’s REST API is simple and well documented. Between the use of serverless architecture and Viber’s API, I couldn’t believe how fast I went from 0 to chatbot.

Setup

First, You’ll need to start by creating a bot in Viber (you’ll need a Viber account at some point). Viber will give you an API key that looks something like 30a6470a1c67d66f-4207550bd0f024fa-c4cacb89afc04094. You’ll use this in the HTTP headers to authenticate to the Viber API.

Next, create a new Azure Functions solution. I’ve previously blogged about Azure Functions with a followup on Lazy Initialization.

I decided to use C# to write my Azure Functions. Unfortunately, there is no .NET SDK for Viber (as far as I know), so I’ll have to use the REST API directly. Not a big deal, I just used RestSharp. But if you prefer NodeJS or Python, Viber has got you covered with SDKs for those languages.

Before you start coding, you’ll need to setup a Webhook. This is simply a way of telling Viber where to send incoming messages. You’ll only need to do this at the beginning. I did this by first deploying a barebones Azure Function that returns a 200. I used Postman to set the initial webhook.

Chatbot webhook with Postman

Finally, I setup a Couchbase cluster on Azure. Getting started with Couchbase and Azure is easy and free. (You can even use the "Test Drive" button to get 3 hours of Couchbase Server without expending any Azure credit). I created a single user called "viberchatbot", a bucket called "ViberChatBot", and I loaded the "travel-sample" bucket.

Azure Function

For this application, I wanted to create a chatbot with a little more substance than "Hello, world" and I also wanted to have a little fun. Here are the commands I want my chatbot to understand:

  • If I say "hi" (or hello, etc), it will respond with "Howdy!"

  • If I ask for "metrics", it will tell me how many messages it’s processed so far.

  • If I mention "twitter", it will make a recommendation about who to follow.

  • If I ask for flights from CMH to ATL (or other airports) it will tell me how many flights there are today (I will use the travel-sample bucket for this data).

  • If I say "help", it will give me a list of the above commands.

I decided not to use any natural language processing or parsing libraries. I’m just going to use simple if/else statements and some basic string matching. If you are planning to create a robust chatbot with rich capabilities, I definitely recommend checking out libraries and tools like LUIS, wit.ai, NLTK and others.

Chatbot code

I started by creating a few C# classes to represent the structure of the data that Viber will be sending to my serverless endpoint.

Viber classes

This is not an exhaustive representation of Viber’s capabilities by far, but it’s enough to start receiving basic text messages.

public class ViberIncoming
{
    public string Event { get; set; }
    public long Timestamp { get; set; }
    public ViberSender Sender { get; set; }
    public ViberMessage Message { get; set; }
}

public class ViberSender
{
    public string Id { get; set; }
    public string Name { get; set; }
}

public class ViberMessage
{
    public string Text { get; set; }
    public string Type { get; set; }
}

Next, the Azure function will convert the raw HTTP request into a ViberIncoming object.

[FunctionName("Chatbot")]
public static async Task<HttpResponseMessage> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]HttpRequestMessage req,
    TraceWriter log)
{
    var incoming = req.Content.ReadAsAsync<ViberIncoming>().Result;

    var viber = new ViberProcessor(Bucket.Value);
    viber.Process(incoming);

    // return "OK" each time
    // this is most important for the initial Viber webhook setup
    return req.CreateResponse(HttpStatusCode.OK);
}

After this, I created a ViberProcessor class with a Process method that receives this object.

public void Process(ViberIncoming incoming)
{
    if (incoming?.Message?.Type == "text")
    {
        LogIncoming(incoming);
        ProcessMessage(incoming);
    }
}

Processing Viber messages

LogIncoming creates a record (in Couchbase) so that I know everything about each request that comes in.

ProcessMessage will analyze the text of the message and figure out what to do in response. You can check out the complete code on Github, but here’s a brief snippet to give you the idea:

// if the message contains "hi", "hello", etc say "howdy"
else if (HelloStrings.Any(incoming.Message.Text.ToLower().Contains))
    SendTextMessage("Howdy!", incoming.Sender.Id);
// if message contains "?" then link to the forums
else if (incoming.Message.Text.Contains("?"))
    SendTextMessage("If you have a Couchbase question, please ask on the forums! http://forums.couchbase.com", incoming.Sender.Id);
else
    SendTextMessage("I'm sorry, I don't understand you. Type 'help' for help!", incoming.Sender.Id);

Getting metrics

One of things my chatbot listens for is "metrics". When you ask it for metrics, it will give you a count of the incoming messages that it’s processed. Since I’m logging every request to Couchbase, querying for metrics is easily done with a N1QL query.

private string GetMetrics()
{
    var n1ql = @"select value count(*) as totalIncoming
                from ViberChatBot b
                where meta(b).id like 'incoming::%';";
    var query = QueryRequest.Create(n1ql);
    var response = _bucket.Query<int>(query);
    if (response.Success)
        return $"I have received {response.Rows.First()} incoming messages so far!";
    return "Sorry, I'm having trouble getting metrics right now.";
}

Sending a message back

The chatbot needs to communicate back to the person who’s talking to it. As I said earlier, there is no Viber .NET SDK, so I have to create a REST call "manually". This is easy enough with RestSharp:

private void SendTextMessage(string message, string senderId)
{
    var client = new RestClient("https://chatapi.viber.com/pa/send_message");
    var request = new RestRequest(RestSharp.Method.POST);
    request.AddJsonBody(new
    {
        receiver = senderId,    // receiver	(Unique Viber user id, required)
        type = "text",          // type	(Message type, required) Available message types: text, picture, etc
        text = message
    });
    request.AddHeader("X-Viber-Auth-Token", ViberKey);
    var response = client.Execute(request);

    // log to Couchbase
    _bucket.Insert("resp::" + Guid.NewGuid(), response.Content);
}

Note that I’m also logging each response from Viber to Couchbase. This could be very useful information for later analysis and/or troubleshooting. If Viber decides to change the structure and content of their response, the data in Couchbase is all stored as flexible JSON data. You will not get surprise errors or missing data at this ingestion point.

Summary

That’s all the basics. Check out the source code for the complete set of actions/operations that the chatbot can do. To test out the bot, I used my Viber app for Android on my phone (and my wife’s, to make sure it worked when I went public).

Conversation with chatbot

Beware: by the time you read this, the chatbot I created will likely be taken offline. Anyone else who creates a "Couchbase Bot" is not me!

Here’s a recap of the benefits of this approach to creating a chatbot:

  • The serverless approach is a good way to control costs of a chatbot. Whether it’s Viber or some other messaging platform, there is potential for sporadic and cyclic use.

  • Viber’s REST API utilizes JSON, which makes Couchbase a natural fit for tracking/storing/querying.

  • Couchbase’s ease of scaling and partnerships with Microsoft (and Amazon and Google) make it a great choice for a chatbot backend.

This was really fun, and I could definitely get carried away playing with this new chatbot. It could analyze images, tell jokes, look up all kinds of information, sell products and services, or any number of useful operations.

I would love to hear what you’re doing with chatbots! Please leave a comment or contact me on Twitter @mgroves.

This is a repost that originally appeared on the Couchbase Blog: Serverless Architecture with Cloud Computing.

Serverless is one of the new buzz words that you’ve probably heard. It refers to a type of deployment where the server is abstracted away. It doesn’t mean there aren’t servers, just that you don’t have to provision the servers yourself. We’ll explore this in the post.

In some cases, serverless can free your enterprise from the costs of maintaining infrastructure, upgrades, and provisioning servers. In this post, we’ll explore the basics of what serverless is, how it differs from microservices (another buzzword), some possible benefits, and how Couchbase Server fits into the picture.

What is Serverless?

With serverless, you simply write code (usually in form of functions/methods). You can do so with many popular languages, including C#, JavaScript (Node), Java, and so on. This code is deployed to a cloud provider like Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform (GCP), and more.

Your code is triggered by events. Events can be as simple as HTTP requests, or they could be many other types of events, depending on what the cloud platform supports. (Azure, for instance, supports Timer, GitHub, etc).

Within the cloud, the servers that execute that code are automatically provisioned (and decommissioned) by the cloud provider on an as-needed basis.

You might also see the terms BaaS (Backend as a Service) or FaaS (Function as a Service). Recently, the meaning of the "serverless" buzz word has been expanded, but this post mainly focuses on FaaS/BaaS cloud services.

Serverless vs Microservices

There are some similarities between serverless and microservices, but they are not the same thing. Both are approaches to break an application into smaller, independent pieces. They differ in what is deployed and what you manage.

As an example, if you are using a microservice architecture, you might have a "shopping cart" service (in addition to other services like "user profile", "inventory", etc). Here’s a diagram of a very simple microservice.

Microservices

Notice some properties of the microservice:

  • Its responsibility pertains only to the shopping cart. It is not a complete application by itself.

  • The service contains a number of possible operations, but they are all part of the service.

  • The microservice communicates with a database (possibly a dedicated database) to complete operations.

  • The microservice deployed to the cloud may use a VM that requires provisioning. Even while this service is idle, you’ll be charged for VM time.

Contrast this with a similar set of features, this time created with a serverless approach.

Serverless

In the serverless architecture,

  • There are 4 functions which can be deployed separately (instead of 1 service)

  • Each function is able to communicate with the database

  • You don’t have to provision a VM, you just deploy a function.

  • The function only consumes resources when needed (and you are only charged for actual use, not idle time)

Shown in the above diagram are only standard HTTP requests. You could also use a Timer event, for instance, to check every 5 minutes to see if there are any abandoned shopping carts.

Benefits of Serverless

There are some benefits (and trade-offs) when using a serverless architecture.

One benefit is that scalability is handled by the cloud provider. If demand or usage increases, the cloud provider can compensate by adding more server(s) when necessary.

Another benefit is that costs are tied to usage. If you have a service that is constantly in use, you might not see any benefits. But if you have a service that is sporadically used, then serverless may provide cost savings.

Finally, it’s possible that a serverless architecture can reduce administration costs. You don’t need to wait for a server to be commissioned. This may improve agile iteration if commissioning VMs or servers are time consuming. It can reduce your need for IT operations, at least initially, because there are no servers to deploy, fewer servers to manage/upgrade/etc. All this may lead to improved developer productivity.

It’s important to note that serverless is not a silver bullet. Your application may not be a good fit for this kind of decomposition. Also, if you end up deploying a large number of serverless functions, you will still need operations people to manage, monitor, and test your functions. Definitely check out the benefits and drawbacks in detail at MartinFowler.com.

Couchbase and Serverless together

There are several popular serverless providers:

Couchbase Server has partnered with each of these major cloud providers and can run on any of those platforms. In addition, you can run Couchbase Server across multiple cloud vendors for improved reach, disaster recovery, and diversification. You can also use Couchbase Server in a hybrid-cloud situation (a mix of cloud and on-premises).

This makes Couchbase a great choice when you need a NoSQL document database, no matter your cloud strategy:

No vendor lock in. With Couchbase, you aren’t even locked into the cloud, much less a single cloud vendor. With XDCR, you can go cloud-first, and have an on-premises cluster for disaster recovery, or deploy Couchbase to multiple clouds.

Cloud marketplace offerings. You can get started in minutes: on Microsoft Azure, AWS, or GCP.

Tools for your programming language. Couchbase offers SDKs for Node.js, .NET, Java, PHP, Python, Go, C/C++, as well as community support for many others. No matter your serverless platform or language preferences, Couchbase has you covered. Check out this blog post on Azure Functions with Couchbase Server for a technical intro using .NET/C#/Azure.

Scaling. With Couchbase Server, scaling is easy and efficient. Couchbase’s architecture is designed for scaling, with built-in replication, autosharding, and data distribution. Every node in a Couchbase cluster can do both reads and writes, providing efficient use of computing resources and high availability.

Flexibility of JSON. Many apps can benefit from a flexible schema, even if you’re using a relational database. Check out this whitepaper on why Couchbase is the engagement database that can work alongside your transactional and analytical database to provide an exceptional customer experience.

Summary

Serverless takes decomposition of your application back-end one step further.

Storing JSON data in Couchbase Server gives you flexibility with both schema and scaling.

Is serverless right for you? It’s not a silver bullet, but if you’re interested in benefiting from lower costs and easier deployment, we’d be happy to help you create a careful plan and discuss whether or not it’s a right fit for your application. You can contact me by leaving a comment, or finding me on Twitter @mgroves.

This is a repost that originally appeared on the Couchbase Blog: ASP.NET Core with Couchbase: Getting Started.

ASP.NET Core is the newest development platform for Microsoft developers. If you are looking for information about plain old ASP.NET, check out ASP.NET with Couchbase: Getting Started.

ASP.NET Core Tools to Get Started

The following video will take you from having no code to having an HTTP REST API that uses Couchbase Server, built with ASP.NET Core.

These tools are used in the video:

Getting Started Video

In the video, I touch quickly on Scan Consistency. For more details on that, check out the Scan Consistency documentation or read a blog post that I wrote introducing AtPlus, which also covers the other types of Scan Consistency.

Summary

This video gives you the absolute minimum to get started with Couchbase by walking you through a simple CRUD application.

If you have any questions, please leave a comment. Or, you can always ask me questions on Twitter @mgroves.

This is a repost that originally appeared on the Couchbase Blog: ASP.NET with Couchbase: Getting Started.

ASP.NET is the development platform that most Microsoft developers use. At the Couchbase Connect Silicon Valley 2017 conference, I spoke to some .NET developers in a workshop. I asked them what type of content they’d like to see me create that would be most useful for them. The answer was: videos on getting started.

ASP.NET Tools to Get Started

The below video takes you from having no code to having an HTTP-based REST API that uses Couchbase Server, built with ASP.NET.

The video uses the following tools:

Getting Started Video

In the video, I briefly gloss over Scan Consistency. For more details on that, check out the Scan Consistency documentation or read a blog post that I wrote introducing AtPlus, which also covers the other types of Scan Consistency.

Summary

This video gives you the absolute minimum to get started with Couchbase by walking you through a simple CRUD application. Stay tuned for a similar video on getting started with ASP.NET Core.

If you have any questions, please leave a comment. Or, you can always ask me questions on Twitter @mgroves.

UPDATE: The calendar is full. You can sign up to be an alternate, in case someone drops out or fails to deliver. I can't give you a date though, so you'd essentially have to have a post ready to go as soon as December 1st. And please, don't let the lack of an advent date keep you from writing that C# blog post! Finally, due to the tremendous response, I will double up the slots next year (from 25 to 50), assuming this advent goes well :)

I heard about the F# Advent Calendar, a traditional that's been carried on since 2010 (2014 in English). I think this is a great idea, and there needs to be one for C# too!

(I asked Sergey Tihon for permission!)

So, I need you to write a C# blog post!

Here are the rules:

  1. Reserve a slot on Twitter (with hash tag #csadvent) or leave a comment on this post. You do not have to announce your topic until the day you reserve.
  2. Prepare a blog post (in English).
  3. Add a link in your blog post that links back to here, so that your readers may find the entire advent.
  4. Publish your blog post on the specified date. Your post must be related to C# in some way, but otherwise the content is completely up to you. I've posted a few ideas below to get your creativity flowing.
  5. Post the link to your post on Twitter with hashtags #csharp and #csadvent

Below are all the slots, and who has claimed each date. I chose to go with 25 total slots (yes I know some advent calendars are 24).

I will do my best to keep this up to date. The slots will be first come first serve. I have already claimed December 25th for myself, since I assume that will be the least desirable date. But I'm happy to swap if you really really want that day.

DateClaimed byBlog Post
Dec 1, 2017 Hilary Weaver-Robb Combining Integration and UI Automation in C#
Dec 2, 2017 Jamie Rees Open Source, 2 years retrospective
Dec 3, 2017 Lucas Lansky Analyzing unit-ness of white-box tests using OpenCover
Dec 4, 2017 Andrei Ignat AOP with Roslyn–part 3–custom code at beginning of each method
Dec 5, 2017 Baskar rao Dsn Quick Actions in Visual Studio 2017
Dec 6, 2017 Bill Sempf Coding for an encrypted service
Dec 7, 2017 Brant Burnett Who says C# interfaces can't have implementations?
Dec 8, 2017 Lee Englestone Creating Alexa Skills with Web-API and hosting on Microsoft Azure
Dec 9, 2017 James Hickey Deck the Halls With Strategy Pattern Implementations in C#: Basic to Advanced
Dec 10, 2017 Carl Layton Using C# dynamic Keyword To Replace Data Transfer Objects
Dec 11, 2017 James Curran An Exercise in Refactoring - Specification Pattern
Dec 12, 2017 Andrew Lock Creating a .NET Standard Roslyn Analyzer in Visual Studio 2017
Dec 13, 2017 Jonathan Danylko 5 More C# Extension Methods for the Stocking! (plus a bonus method for enums)
Dec 14, 2017 Gérald Barré (aka Meziantou) Interpolated strings: advanced usages
Dec 15, 2017 Baskar rao Dsn Using BenchMarkDotNet for Performance BenchMarking
Dec 16, 2017 Chris Bohatka Breaking Down Dependency Injection and Inversion of Control in C# with SimpleInjector
Dec 17, 2017 David Pine C# Special Edition
Dec 18, 2017 Barret Blake Using C# and Azure Cognitive Services Text Analytics to Identify and Relate Text Documents
Dec 19, 2017 Ed Charbeneau 5 .NET Standard Features You Shouldn’t Miss
Dec 20, 2017 Kevin Miller Things you Should do with Strings While You’re Coworkers are on Holiday and No One is Checking the Production Code Branch
Dec 21, 2017 Angus Kinsey What makes C# great?
Dec 22, 2017 Jim Wilcox Unloading the UI Thread in C# on Windows 10 + UWP
Dec 23, 2017 Duane Newman All I want for Christmas is a C# Build System
Dec 24, 2017 Calvin Allen Live Unit Testing in Visual Studio 2017
Dec 25, 2017 Matthew D. Groves Swashbuckle and Swagger with ASP.NET Core

Alternates:

  • Leave a comment or tweet with #csadvent to be put on this list!

Some ideas:

  1. Introduction to [your favorite NuGet package]
  2. X C# Tricks and Tips
  3. JSON (De)serialization
  4. Streams
  5. The newer C# 6 and 7 features
  6. Async/await

Thanks to everyone who is participating! I hope this goes well and it can become an annual tradition.

Matthew D. Groves

About the Author

Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.

Latest Comments

Twitter