{"id":6998,"date":"2019-06-03T22:11:14","date_gmt":"2019-06-04T05:11:14","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=6998"},"modified":"2025-06-13T21:23:08","modified_gmt":"2025-06-14T04:23:08","slug":"build-chatbot-couchbase-amazon-lex-node-js","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/build-chatbot-couchbase-amazon-lex-node-js\/","title":{"rendered":"Building a Chatbot with Couchbase, Amazon Lex, and Node.js"},"content":{"rendered":"

Nic Raboy<\/a> is an advocate of modern web and mobile development technologies. He has experience in Java, JavaScript, Golang, and a variety of frameworks such as Angular, NativeScript, and Apache Cordova. Nic<\/a> writes about his development experiences related to making web and mobile development easier to understand.<\/em><\/p>\n

\"Nic<\/p>\n

It is no question that the future is going to be automated. We have automated self-driving vehicles, voice assistants, call center and text-based bots, and so much more. However, what does it take to bring automation to your business?<\/p>\n

The short answer is that it doesn\u2019t take much more than building standard applications if you\u2019re using the right tools.<\/p>\n

In this tutorial we\u2019re going to explore creating a chatbot that can take some of the workload off your human employees by leveraging Amazon Lex<\/a> for deep learning and conversational interfaces, Couchbase<\/a> NoSQL as the database, and Node.js<\/a> for interacting with the database.<\/p>\n

The Requirements for this Tutorial<\/h2>\n

There are a few software requirements that must be met in order to be successful with this tutorial and project:<\/p>\n

    \n
  1. Couchbase Server 5.0+ must be installed and available remotely.<\/li>\n
  2. An AWS account.<\/li>\n
  3. Docker or a virtual machine software.<\/li>\n<\/ol>\n

    Because we\u2019ll be using Amazon products such as Lex and Lambda, an AWS account must be available. Both products are pay as you go, so a free tier will likely be more than enough. Since we\u2019ll be using Amazon products, these products need access to Couchbase. For this reason Couchbase cannot be running from localhost, it must be installed somewhere remotely. Finally, since the Couchbase Node.js SDK uses native dependencies, Docker or some other virtual machine software must be available to download the dependencies as Linux, which is what Lambda expects.<\/p>\n

    Configuring Amazon Lex for User Interaction<\/h2>\n

    Before we get into the code, we can spend our time configuring Lex. While Lambda will allow us to make our bot useful, you don\u2019t need any kind of backend to play around with Lex.<\/p>\n

    Go to Lex<\/a> in your AWS portal and choose to create a new custom bot.<\/p>\n

    \"aws-lex-custom-bot\"<\/p>\n

    Since we\u2019re creating a text-based bot, the output voice should be none. Everything else should just be the defaults or whatever you deem to be most appropriate.<\/p>\n

    With the custom bot created, the first step is to start creating intents. For this example we\u2019re going to create an AboutIntent<\/code>, GetProfileIntent<\/code> and UpgradeServiceIntent<\/code>, two of which will use Couchbase for information.<\/p>\n

    Let\u2019s start with the AboutIntent<\/code>.<\/p>\n

    \"aws-lex-aboutintent\"<\/p>\n

    The idea behind the AboutIntent<\/code> is to just get us started. We won\u2019t be using the database for this intent, but it will eventually connect to our Lambda function. This intent is to give us information about the bot.<\/p>\n

    To trigger our intent, we need to define some sample utterances which are basically a list of possible phrases. Take the following for example:<\/p>\n

    who made this chatbot\r\nwhat can you tell me about yourself\r\ngive me information about this bot<\/code><\/pre>\n
    The above phrases are what a user might ask. The more the better because Lex will learn from the training data and be able to fill in the gaps if someone asks something that isn\u2019t from the list.<\/p>\n
    For now we\u2019ll leave Fulfillment<\/strong> as Return parameters to client<\/strong>, but we\u2019ll eventually switch it to Lambda.<\/p>\n
    Let\u2019s take a look at GetProfileIntent<\/code> now.<\/p>\n
    \"aws-lex-getprofileintent\"<\/p>\n
    This intent is a slightly different because we want to be able to accept dynamic information from the user, something that will change between different users. We can allow dynamic information through slot variables.<\/p>\n
    Take the following sample utterances which contain slot variables:<\/p>\n
    i need some information about my account\r\nget me some information about my account {AccountId}<\/code><\/pre>\n
    Not all sample utterances need to contain slot variables, but notice that the variable is wrapped in curly brackets. Each variable used can be defined within the intent configuration. For example, our AccountId<\/code> is defined as an AMAZON.EmailAddress<\/code> with a default prompt phrase.<\/p>\n
    So what does this mean?<\/p>\n
    When Lex determines our slot variable exists, it must be a valid email address. If Lex determines we\u2019re trying to execute the GetProfileInfo<\/code> intent, but the variable doesn\u2019t exist, it will use our prompt phrase to ask the user for that variable information. This makes the conversation fluid, but without omitting any required data.<\/p>\n
    Finally, let\u2019s look at UpgradeServiceIntent<\/code>.<\/p>\n
    \"aws-lex-upgradeserviceintent\"<\/p>\n
    The UpgradeServiceIntent<\/code> is similar to our GetProfileIntent<\/code>, but this time we have two possible slot variables. Take the following sample utterances:<\/p>\n
    i'd like {Service} and my account information is {AccountId}\r\ni'd like to upgrade my service to {Service}<\/code><\/pre>\n
    Remember, two sample utterances is not nearly enough, but hopefully you get the idea when it comes to how variables can be used. The idea is that you want conversation with this chatbot to be fluid like a real person because then you can replace the real person with the bot.<\/p>\n
    There is an exception though with the UpgradeServiceIntent<\/code> slot variables. The Service<\/code> variable is a custom slot that we must create.<\/p>\n
    \"aws-lex-custom-slot\"<\/p>\n
    In our example we want to create a CustomServiceSlot<\/code> where the name isn\u2019t important, but the data is. We want to define the possible things that can exist within the variable. In our example we are saying that the slot can be any of the following:<\/p>\n