DEV Community: Kelly Andrews

Navigating the World of Developer Relations

Kelly Andrews — Thu, 19 Jan 2023 13:26:26 +0000

Welcome to the world of developer relations! As a developer relations professional, you play a critical role in building and maintaining relationships between a company and its developer community. Whether you're working for a startup or a large enterprise, the importance of developer relations in the tech industry cannot be overstated.

From technical evangelism to community management, developer relations professionals wear many hats. They act as the voice of the developer community inside the company, providing valuable feedback and insights to help shape product development. They also serve as the company's voice in the developer community, sharing updates, resources, and best practices.

So, whether you're just starting in developer relations or a seasoned pro, this post will give you a better understanding of the field and help you navigate the many roles and responsibilities of a developer relations professional. Let's dive in!

Skills

When it comes to excelling in developer relations, there are a few essential and critical skills. The first is strong communication skills. As a developer relations professional, you will interact with developers from all backgrounds, colleagues, and stakeholders from other teams. Communicating effectively verbally and in writing is crucial to building trust and establishing solid relationships.

Another essential skill is technical acumen. While you don't need to be a software developer yourself (although it does help a bit), having a solid understanding of the technical side of things is critical to understand developers' needs and concerns and effectively advocating for them within the company. This can be achieved through experience working in a technical role or ongoing learning and education.

In addition to these skills, building relationships and advocating for developers are also vital. Developer relations foster a sense of community and connection between a company and its developer base. Building relationships with developers, understanding their needs and concerns, and advocating for them within the company are critical to the success of a developer relations professional.

Finally, empathizing with developers and understanding their perspectives is crucial to building trust and establishing effective relationships. This skill is often developed through experience and continuous learning of the developer ecosystem and its trends.

Roles

The role of a developer relations professional can vary depending on the company and the specific needs of the developer community. However, a few key responsibilities are shared across the field.

One of the primary roles of a developer relations professional is to act as the voice of the developer community within the company. This means gathering feedback and insights from developers and then sharing that information with other teams, such as product development, marketing, and customer support. This helps ensure that the needs and concerns of the developer community are taken into account when making decisions about products and services.

Another critical responsibility of a developer relations professional is to act as the company's voice within the developer community. This means sharing updates and resources with developers, answering questions, and addressing concerns. This helps build trust and strong relationships with the developer community, which can lead to increased adoption of products and services.

A developer relations professional also often plays a crucial role in community management. This includes organizing and hosting events, such as meetups and hackathons, and creating and maintaining online communities, such as forums and social media groups. Community management helps to foster a sense of community and connection among developers and can also be a great way to gather feedback and insights.

Finally, a developer relations professional also serves as the company's technical evangelist. This means promoting and showcasing the company's products and services to developers and providing technical support and resources. Technical evangelism helps to increase awareness and adoption of the company's products and services among the developer community.

Advice

Transitioning into a developer relations role can seem daunting, but it can be a rewarding and fulfilling career path with the right mindset and approach. Here are some tips and advice on how to make the transition.

Networking is one of the most important things you can do when transitioning into a developer relations role. Attend conferences and meetups, join online communities and groups, and connect with other developer relations professionals. Not only will you learn from others in the field, but you'll also have the opportunity to make connections that can lead to job opportunities.

Gaining relevant experience is also crucial when making the transition. Participating in open-source projects, working in a technical role, or volunteering at developer events can help to build your skills and knowledge. It also allows you to showcase your experience and skills to potential employers.

Building a personal brand can also be beneficial when making the transition. Creating a portfolio of your work, writing blog posts or articles, and sharing your knowledge and experience on social media help establish you as a thought leader. This can attract potential employers and showcase your skills and experience.

It's also important to stay current with the latest trends and best practices in the field and to continuously learn and grow your skills. Reading industry publications, following influential people in the area, and taking online courses are great ways to stay up-to-date and continue developing your skills.

Finally, don't be afraid to take risks and try new things. Developer relations is a field that is constantly evolving, and those who are willing to adapt and try new things are often the most successful. Keep an open mind, be ready to learn and grow, and don't hesitate to step out of your comfort zone.

Conclusion

In conclusion, developer relations is a dynamic and critical field in the tech industry. It is vital in building and maintaining relationships between a company and its developer community. It is essential for the success of any organization that creates and distributes technology.

By understanding a developer relations professional's various roles and responsibilities and the critical skills needed to excel in this field, you can transition into a developer relations role and help bridge the gap between companies and the developer community. We hope this post has provided you with valuable insights and resources to help you pursue a career in developer relations and make an impact in the tech industry.

Remember to stay current with the latest trends and best practices in the field, continuously learn and grow your skills, and don't be afraid to take risks and try new things. Keep building connections and relationships, and always be open to new opportunities to improve your developer relations skills.

My Attempt To Answer How I Lost Weight

Kelly Andrews — Thu, 12 Jan 2023 14:28:56 +0000

Over the last several months, I've been able to reconnect with people again after a couple of years. After their initial shock and surprise that they know who I am, they ask me: "how did you do it?"

I honestly don't know how to answer the question because, even to me, it still is a mystery. This post will collect my thoughts and hopefully provide some answers to those curious.

The Who

I remember during my senior year of high school when I realized I had put on so much weight that my clothes no longer fit me, and I needed to buy larger sizes. What I didn't know at that time was that it would be a 25-year battle of self-image, self-loathing, and motivation.

Over that time, I've tried just about everything to lose weight: Atkins, South Beach, Juice cleanses, Weight Watchers, Mediterranean, Cabbage, Paleo, Keto, Low Carb, Body For Life, Low Sugar, Calorie counting, Weight lifting, Cardio, Aerobics, Running, etc.

Sometimes I took those efforts seriously, getting down to 280 pounds twice. 280 does not seem like a good number for a 5'11" male who is supposed to weigh under 190 lbs, but when you previously clocked in at 400 lbs or more, it feels incredible. However, I would always gain the weight back.

I learned that diets are not sustainable and surgery doesn't work for everyone. More importantly, I started to understand that programs are designed to make you temporarily lose weight, are unsustainable, or worse for your health than you think.

You would think that being diagnosed with Type 2 Diabetes would have pushed me to get things under control, but I had convinced myself that no matter what I weighed, I was healthy or that even thin people get sick. I became an expert at evading my efforts.

Anything can be okay in moderation, but not when dieting is so far off course that even moderation is excess. I would eat plateful after plateful, never feeling full or satisfied. I would wake up hungry, despite eating 2500 calories for dinner the night before. I was sick but had convinced myself that I was healthy and that my body was naturally heavy and needed the extra weight.

The Why

Before I get to how I lost weight, I want to talk about my love of amusement parks and roller coasters. Around 13, our school went on a field trip to Cedar Point. It wasn't my first time at an amusement park, but this time I finally talked myself into riding a coaster with loops, and after that, I was hooked. Every summer, I would get to a park and ride as many roller coasters as I could. The atmosphere, the heat, the lines, all of it, I loved it.

However, most rides don't cater to larger bodies. I recall countless times feeling dejected after waiting in line for a ride I couldn't fit in. I had to watch my kids enjoy riding coasters from the sidelines. Ultimately, this reality sinking in and watching my wife lose weight the year before finally pushed me towards action.

The How

Most people wish this were where I could say, "I did X," and that was it - end of the post. Typically, my answer to those who ask is, "I ate less." This answer never feels good enough or can even be condescending and rude. So let me try and explain what that means exactly.

Eat Less

I used to love eating at Wendy's. I would order a double (mayo and cheese only), large fries, and a large diet drink (saving calories, of course). Besides the two days' worth of caloric intake in a sitting, the number of addictive chemicals in that meal made me only want it more.

The most important lesson was how addictive food could be. I used to think ice cream and pizza were "bad foods" or salads and veggies were "good." Both things are the same - food. The ingredients make all the difference.

Two brands of peanut butter, with 200 calories/serving, can have completely different ingredients, depending on the amount of sugar and oils added. Removing processed foods from my diet didn't all happen at once. I backed down slowly. I think this is critical - quitting anything this addictive without stepping down is dangerous and fruitless. It tends to lead to severe levels of bounce back.

A triple became a single, and fries became small. I could get the taste without as many calories. Over time, I wanted it less and less. The foods many of us eat, especially diet foods, contain so much stuff that our bodies don't know what to do with them.

The more I eliminated fast foods - frozen meals, dining out, prepackaged foods - the more I lost. Do I still eat junk? Yep. Just so much less often and on a significantly lower amount.

Eat Less Often

I found myself eating around the same time every day, regardless. The first habit I had to break was eating on a schedule, not when I was hungry. This behavior would lead me to eat 4000+ calories daily without thinking. I honestly didn't even know what hunger was anymore.

Searching for what hunger felt like took some time, but I'm not sure how long. It took paying close attention to my body and waiting to eat only when I truly felt hungry. Asking the simple question, "am I hungry" I typically answer no.

Eventually, I could turn this new understanding into a more rigorous fasting approach. I am now able to fast and control intake without the initial struggles.

Measuring Success

My initial measurement of success was stepping on a scale 2-3 times a day. Any loss was a win and felt great. Setting weight goals helped - my first was to get under 300 lbs. After that, I used 20-pound increments to not overwhelm myself with taking on too big of a goal.

Recording my weight was a big eye-opener. There was a pattern of loss/gain that I had never noticed before seeing the pattern and associating that with how I was eating and feeling at the time helped my brain comprehend what was happening. It was something I could repeat now, with consistent results.

I also used roller coasters at a nearby theme park that year as a measurement - starting the season only fitting on a few to ending the year by riding them all. Clothing sizes also became a gauge. Going from 3XL to L and a 56" waist to 36" was a clear indicator that things were working.

Final Thoughts

While it may seem like a brush-off type of answer, "I eat less food" is the only way I can sum up a year of retraining my mind and body to understand how to feed itself again. The problem with asking me how is I am still in disbelief myself and do not believe I have any level of expertise that will ultimately help.

What I can say is - you will have a different journey. You will find the patterns, habits, and foods that work best for you. If I have learned anything, it is this - no one else will do the work for you. No diet, book, video, class, or anything else will change you. It was not easy, but the extra time I may have with my family makes it worth it.

From Magic Shows to Marching Bands: A Busy 2022

Kelly Andrews — Thu, 05 Jan 2023 14:33:38 +0000

Hey there! It's hard to believe that it's already 2023. It seems like just yesterday we were ringing in 2022, and now here we are at the start of a new year.

Looking back on last year, there's no denying it was great. In April, I joined Zoom. I love being a part of such a fantastic team. I also had the opportunity to watch my son learn the vibraphone and play with the high school marching band, which was a fantastic experience. The family even took a trip to Universal Studios, which was so much fun.

But perhaps the year's highlight was my first professional magic performance. I've always been interested in magic and have been practicing for years, but finally, being able to perform for a paying audience was a dream come true. It was a little nerve-wracking at first, but the reactions I got from the crowd made it all worth it.

In addition to that, I was fortunate enough to be invited to speak at two conferences last year. It was an excellent opportunity to share my knowledge and experiences with others, and I hope to have the chance to do more of that in the future.

As great as 2022 was, though, it went by fast, and now we are at the start of 2023. But I'm excited about all that this year has in store.

At Zoom, we've got some inspiring initiatives that will significantly impact developers' lives. I'm also working on a small project that has the potential to turn into something huge in the long term.

And on a personal level, my wife and I are planning a trip to Vegas, which we've wanted to do for a long time, and then later in the year to see Metallica. Who knows what other adventures and opportunities the year will bring?

One thing I'm committed to this year is producing more content. I've always enjoyed blogging and streaming, and I look forward to doing more in 2023. I'm also hoping to have the chance to give more talks and possibly even host some workshops.

Overall, I'm feeling pretty optimistic about the year ahead. Here's to an incredible 2023!

Reflecting on my time at Vonage

Kelly Andrews — Fri, 01 Apr 2022 16:09:29 +0000

It's my last day at Vonage today - no joke. While hard to completely grasp everything that's happened over the last couple of years, I wanted to try and take a moment and sum up everything since starting in August 2018.

Firebase

One of the more forward-looking platforms used during my tenure was Firebase. I was able to spend a ton of time here learning how to use as much of the functionality that Firebase had to offer. Whether it was SMS translation, or adding two-factor authentication, the tool kit that Firebase gives you is extremely powerful, and always a consideration when I create new projects.

Sentiment Analysis

While easy to implement, Sentiment analysis is hard to get right and is far from perfect. However, as a general guide for intervention, it can do a good job of finding customers that may be more upset and can make that actionable. For call centers, it's a great tool.

Read my comparison - although it's a bit dusty now

Chatbots

Chatbots can be super fun, or really frustrating. While they can provide easy solutions to simple problems, covering all cases can be tricky, and it's easy to miss flows. Couple that with also trying to use speech transcription to match nouns and verbs programmatically, and now it's a disaster.

With the right amount of effort and planning, however, they can be extremely powerful and handle quite a lot of typical use cases. You can always push the call to a human when the script isn't working as a last resort.

You can read the tutorial for that here.

Transcription

I feel like transcription is really well solved in most cases. Listening to audio and transcribing it word for word is the main function of these APIs, and they all do it efficiently and accurately. Don't be afraid to use them.

Read another outdated comparison

Translation

Translation, much like transcription, has been fairly well solved. Every translation API has some kind of lexicon customization to cover industry-specific terms and can cost a lot more than the base service, however, the basic level of translation is really good in general. I plan on using these more in the future as well.

One more ancient review

XState

One of my favorite tools in JavaScript these days is XState. The ability to define how an application should work as a state machine, and use that in any front or back end to control the flow of states - chef's kiss. I found it extremely useful with things like video, as I could create states that matched exactly what was happening with the SDK and API.

It's really a lot of fun to use - I recommend you try it out.

Oclif and CLI Design

I built the Vonage CLI using Oclif, and I've really learned to love using oclif, CLI best practices, CLI history, and the command line itself.

Building a CLI isn't always the easiest thing to do, as it can run in so many environments, but solving these types of problems are fun for me.

Lerna/Monrepo

While building the CLI and an updated SDK, I decided to work in a monorepo structure, using Lerna to manage the publication of the modules. I plan on writing more on how that is used in the future as well. It's a great resource, easy to understand, but hard to get started.

Typescript (sorta)

Last, and well, least, Typescript. I have an appreciation for types now, and while I still feel like I have a long way to go, learning Typescript has been rewarding, if not frustrating. This was one of the harder things to learn for me, but I really am better off for doing it.

Conclusion

Overall - it was a great learning experience. Being able to learn new things as a developer advocate is one of my favorite aspects of the job.

I'm thankful for the opportunities I've had here, and look forward to the future.

Learn and Apply XState with Vonage Video

Kelly Andrews — Wed, 01 Jul 2020 13:55:12 +0000

Over the last few months, I have heard more about state machines used for front-end development. The idea of a state machine is that it has only a finite number of states and can only be in one state at any given time. Conceptually this makes perfect sense for app development – there are only a certain number of states available.

The concept of state machines and statecharts is not new, and it isn’t rooted in front-end development, either. It’s a mathematical model, and one used in many things around us. As an example, a light can be OFF or ON. You can describe anything with a state machine, even though this is a simple example.

Introduction to XState

Using a state machine in front-end development has become much less complicated with the creation of the package XState. XState helps us define state machines, create events and effects, and control the entire application flow. XState uses JavaScript methods and objects to describe the state machine.

The light bulb example from above would be written out like the following:

const lightBulb = Machine({
  id: 'lightBulb',
  initial: 'off',
  states: {
    off: {
      on: {
        TURN_ON: 'on'
      }
    },
    on: {
      on: {
        TURN_OFF: 'off',
      }
    }
  }
});

The state machine defined here shows the two states for the light bulb, OFF and ON, and the transitions from the events TURN_ON and TURN_OFF.

The object itself isn’t very complex to read, but as the state machine grows in complexity, it can be harder to understand. XState has create a tool to help out with this – the XState visualizer.

https://xstate.js.org/viz/?gist=a8a33932a88951692a8c94de647db40b

Using the XState visualizer helps to see how the state machines work and are interactive, so playing with them is fun. If you want to check out the code for the machine, you can also click the code button to take a peek.

Building a Vonage Video State Chart

When I set out to learn state machines, and XState, my overall goal was to build an application similar to Google Meet using Vonage Video. The app would allow a user to create a meeting room, share the URL, and have a meeting with multiple streams. To get to that point, I had to learn some of the various concepts for state charts and how to represent those in XState.

Thinking through the possible application states is not an easy task, I found. There are many possibilities to explore, and ultimately finding the right solution takes some trial and error.

The rest of this article will cover some basic concepts and build a state chart visualization that will mimic the eventual state machine. I will also provide some additional links and resources throughout so you can explore on your own.

States and State Nodes

A state is a representation of a machine at any given time. This moment can be defined and then made into a state node in XState, captured as a configuration.

In my Vonage Video app, there are a couple of different possible solutions to this, but I’ve found that describing the states in as simple of terms as possible is the best way to get to a useful result.

Creating a machine uses the following pattern:

const machine = Machine(state_nodes, options)

With a video state machine in mind, there are two compound states – connected and disconnected.

https://xstate.js.org/viz/?gist=2d260c1f9c7b51ed47c4cf7bbc61b4df

Two state nodes may seem overly simplified, but there are only two states after some trial and error. Each of these states, however, are more complex than an atomic (no children) node. Instead of creating every possible state at the top level, XState helps us organize with hierarchical and parallel state nodes.

Hierarchical State Nodes

XState provides the option to create nested states called hierarchical state nodes. When we first start the machine, we can set it to idle first, as the machine will be ready but doing nothing. Why not just make another top-level atomic state node?

Adding states to the top level is called “state explosion” and is a typical side-effect of finite state machines. Since Vonage Video is still technically disconnected, nesting idle makes sense as the video is both disconnected and idle. Another disconnected substate should be ready. The disconnected.ready state would happen just before moving to the connected state. The state machine also has a state node in-between idle and ready to get everything set up. This middle state can be called the init phase.

The state machine now would look like this:

https://xstate.js.org/viz/?gist=da00b68575ceb12f88b1ad7ad0219020

You should notice that we don’t currently have a way to move in between the two nodes. We will cover events and actions in a moment.

Parallel State Nodes

A parallel state node allows the application to be in all of its substates at the same time. The Vonage Video state machine is highly event-driven, so we need to manage multiple states at once.

To specify that a state node is parallel, we use type:parallel in the configuration. After the transition to connected, three parallel states will occur – session, publisher, and subscribers. Each of these states will set up events and event listeners to control the Vonage Video service’s responses.

The resulting visualization looks like this:

https://xstate.js.org/viz/?gist=bf9c3dd275206505c12bb0bb88df5d58

With these primary states, we can control what our application shows at particular times. Currently, however, we are unable to move between states. Let’s have a look at events and transitions.

Events and Transitions

Since a state node is just the configuration of an individual state, their inherently is not a way to move from state to state without declaring that in the state node.

Each node listens for a sent event to transition to the next state. In the light bulb example, the TURN_ON event sent tells the machine to transition to on.

Transitions only occur between top-level nodes and within hierarchical nodes. Parallel nodes are not allowed to transition between each other. For our Vonage Video app, this means the following:

When the page is ready, we can send a START event. This event will transition the state to disconnected.init.
The disconnected.init state will transition out once the VIDEO_ELEMENT_CREATED event has fired.
Once we reach disconnected.ready, we can allow the user to connect, sending the CONNECT event, and transition to connected.
If the application passed the DISCONNECT event, the state machine would disconnect.

https://xstate.js.org/viz/?gist=53c4772dc742ce1b84c40e3fa6669c6e

Declaring an event and transition in XState uses the following pattern:

on: {
  EVENT_DESCRIPTOR: 'nextState'
}

You can add specific actions to the transition as well. I would recommend you read the sections on internal and external transitions in the documentation. They cover in great detail the various types of transitions possible.

Guarded Transitions

You may have noticed that one of the transitions has a cond node in the transition. This conditional is what’s called a guarded transition. Guarded transitions help protect the machine from moving to a state that is not allowed based on certain conditions. In this case, I don’t want to transition to ready until the token and video element are both created.

on: {
  'VIDEO_ELEMENT_CREATED': {
    target: 'ready',
    cond: 'checkToken'
  }
}

The guard condition checkToken is a named reference to the guards object in the options paramater sent to machine:

const video = Machine(
  state_nodes,{
  guards: {
    checkToken: () => true
  }
});

Context

In order to be more useful to an application, our state machine will need a longer living state, called an extended state, or context. The context object updates using various effects with the assign() method.

Speaking of actions, let’s get to these now and finish out the rest of the skeleton.

Actions and Services

There are what’s known as “side-effects” in state machines that XState puts into one of two categories:

“Fire-and-forget” – where the effect doesn’t send events
Invoked – where sending events are required

Actions

Actions are single effects and tend to be one of the more common effects in the video state machine. You can use actions when you enter or exit a node, or during a transition. Understanding the order of actions is incredibly important.

An excellent resource for learning the action order (and all of the topics on XState) is a video published by @kyleshvlin over at Egghead.io. It helped me understand how actions fired.

The bulk of the actions for this machine revolve around updating the context as a transition. When events are called, we can use the action to run the assign() method:

on: {
  'SOME_EVENT': {
      actions: assign({'someContext': (ctx, e) => e.someValue})
  } 
}

Services

Invoked Services are the other main effect in the video state machine. To use promises and event listeners, you need to invoke a service. This concept was, by far, the hardest for me to grasp. The main difficulty I had to work through was understanding that an invoked service stops when the state exits. If you transition too quickly, your promise or callback will disappear.

There are two primary services that I’m using in the video state machine, promises, and callbacks. The invoke promises service allows the state machine to use a promise to either resolve or reject and then act accordingly. I used this to interact with the server asynchronously and then update the context when complete.

The function signature of invoked promises looks like this:

src: (context, event) => new Promise((resolve, reject) => {
  if (event.error) reject('Rejected')
  resolve('Resolved')
}),
onDone: {/*success transition*/}
onError: {/*error transition*/}

The second, and probably the most important part of this machine, is the invoked callbacks. The Vonage Video architecture relies heavily on events and event listeners. In a state machine, those are set up through a callback. Let me show you an example:

invoke: {
  id: 'initPublisher',
  src: (ctx) => (cb) => {
    let publisher = initPublisher(pubOptions);
    publisher.on('videoElementCreated', (e) => {
      cb({ type: 'VIDEO_ELEMENT_CREATED', publisher: publisher })
    })
    return () => publisher.off('videoElementCreated');
  }
}

The function signature of an invoked callback looks like this:

src: (context, event) => (callback, onReceive) => {

  callback('EVENT');
  onReceive(event) => { callback('OTHER_EVENT') };

  return () => cleanup()
};

Using actions and services, our Vonage Video state machine now looks like the following:

https://xstate.js.org/viz/?gist=826cd253fd9eac80c2daa6bfa0924f50

Don’t forget to click around, and click the code tab to see what the state machine looks like as a configuration.

Resources and Wrap-up

Ok – so you’ve made it this far.

If this is your first time looking at XState, it’s a lot to take in all at once. I’m still exploring and learning new ways to do things. This post is just a small portion of what’s out there. As you are learning – here are a few great resources you will want to check out

Feel free to reach out if you have questions about XState, and we can learn something new together!

The post Learn and Apply XState with Vonage Video appeared first on Vonage Developer Blog.

Using Dialogflow with Firebase and the Vonage Messages Sandbox

Kelly Andrews — Mon, 01 Jun 2020 18:11:24 +0000

Using Dialogflow to build a chatbot to interact with your customer is a great way to handle incoming requests like reservations, bank inquiries, FAQs, and initial support. When you combine Dialogflow with Firebase and Vonage Messages API, things start to heat up.

Prerequisites

For this tutorial, you are connecting a Dialogflow agent with the Vonage Messages API using Firebase. When complete, you can send a message in Facebook Messenger to the Dialogflow agent and get a response based on the agent’s rules.

You’ll want to make sure you have:

Vonage API Account

To complete this tutorial, you will need a Vonage API account. If you don’t have one already, you can sign up today and start building with free credit. Once you have an account, you can find your API Key and API Secret at the top of the Vonage API Dashboard.

Create a Firebase Application

If this is your first time setting up a Firebase project, I would recommend you work through Google’s Firebase getting started tutorial first to get yourself acclimated to the environment. If you are accustomed to Firebase or feeling adventurous, the first step is to create a new Firebase project. Feel free to name this anything memorable.

Once through the initial creation process (less than 5 minutes), set up these two items in the dashboard of your project:

Upgrade to Blaze Pay-As-You-Go You can locate this under Settings -> Usage and Billing -> Details & Settings -> Modify Plan. Firebase requires Blaze for any 3rd party integrations to work.
Pick a Resource Location Find this in Settings -> Project Settings -> General

Once those are all set, you can set up the Dialogflow agent and associate it with the new Firebase/GCP project.

Set Up Dialogflow Agent

Now you are ready to create a new Dialogflow agent—the chatbot that you will be interacting with later. Dialogflow uses Natural Language Processing to determine the user’s intents based on what they type or speak and return an action based on that intent.

Next, import a “Prebuilt Agent” provided by Google to help get you started. If you are new to DialogFlow, you need to create a blank agent on the landing page.

Once you have an agent, you can select the “Prebuilt Agents” from the left menu. You are presented with many different types of agents that might help you start learning how to build your chatbot. For this example, I picked “Easter Eggs.”

Import an agent and wait for it to complete the build process. Once finished, get the credentials for the service account.

Download Service Account Keys

Navigate to the GCP IAM & Admin service for service accounts. Make sure you select the correct project that you have been using already.

You should see a service account that looks similar to dialogflow@myexampleproject.iam.gserviceaccount.com. Click the dots on the right and select Create Key and then pick JSON from the options. This process generates and downloads a JSON file. Save this file for later.

Build Functions Locally

You now have a Firebase project and a Dialogflow agent ready to go. The two systems need to communicate with each other and with Vonage APIs. To do that, you need a little code to make things work.

The Firebase CLI has some helpful tools to get you started. Make sure you have the latest version and run the following:

firebase init functions

This command creates the project inside your root folder and asks you to connect it to an already existing project. After a few prompts, the command runs npm install to install all of the requirements. Once complete, navigate to the functions folder and use this command to install the other packages you need:

npm i @google-cloud/Dialogflow axios

At this time, you should also move the service account JSON file over to the functions directory. Once you’ve done that, make sure to add it to your .gitignore file as well.

The Code

Inside the functions directory is index.js. They provide some sample code to get you started, but you can delete and replace it with the following code to send a message to the Vonage Messages Sandbox. Make sure to have your Vonage API key and secret handy for this.

const functions = require('firebase-functions');
const axios = require('axios');
// the service account JSON file downloaded earlier - make sure this is named properly
const serviceAccount = require('./service_account.json');
const Dialogflow = require('@google-cloud/Dialogflow');
// This method takes the TO_ID, FROM_ID, MSG from the webhook defined later
// DialogFlow responses will be sent using this function
// You will need to get your API Key and Secret from the Vonage Dashboard.
function sendMessage(TO_ID, FROM_ID, MSG) {
  return axios.post('https://messages-sandbox.nexmo.com/v0.1/messages', {
    "from": { "type": 'messenger', "id": FROM_ID },
    "to": { "type": 'messenger', "id": TO_ID },
    "message": {
      'content': {
        'type': 'text',
        'text': MSG
      }
    }
  }, {
    auth: {
      username: 'API_KEY',
      password: 'API_SECRET'
    }
  })
}

The next function is the gateway between Firebase and Dialogflow. The incoming message from Vonage is sent to the Dialogflow agent to determine the intent of the message. Once the intent is determined, Dialogflow passes back a message to forward on to the client.

async function DialogflowGateway(text, sessionId) {
  const sessionClient = new Dialogflow.SessionsClient({ credentials: serviceAccount });
  const sessionPath = sessionClient.projectAgentSessionPath('YOUR-GOOGLE-PROJECT', sessionId);
  const request = {
    session: sessionPath,
    queryInput: {
      text: {
        text: text,
        languageCode: 'en-US',
      },
    },
  };
  console.log(request)
  return sessionClient.detectIntent(request);
}

The Vonage Messages Sandbox uses an inbound webhook to receive the messages using a POST method to Firebase.

exports.webhook = functions.https.onRequest(async (req, res) => {
  const { message, from, to } = req.body;
  try {
    // the message from the user is sent to Dialogflow, and a response is returned
    const response = await DialogflowGateway(message.content.text, from.id);
    // the response from Dialogflow is sent back to the user through Vonage
    await sendMessage(from.id, to.id, response[0].queryResult.fulfillmentText);
  } catch (error) {
    console.error(error);
  }
  res.sendStatus(200);
});

These three functions should be inside the index.js file and saved. All that is left is to deploy these functions.

Deploy Functions

Using the Firebase CLI, deploy the functions to Firebase using this command:

firebase deploy --only functions

On successful deployment, you get the webhook required for the Vonage Messages Sandbox Inbound webhook.

✔  functions: Finished running predeploy script.
i  functions: ensuring required API cloudfunctions.googleapis.com is enabled...
✔  functions: required API cloudfunctions.googleapis.com is enabled
i  functions: preparing functions directory for uploading...
i  functions: packaged functions (47.86 KB) for uploading
✔  functions: functions folder uploaded successfully
i  functions: creating Node.js 8 function webhook(us-central1)...
✔  functions[status(us-central1)]: Successful create operation.
✔  functions[webhook(us-central1)]: Successful create operation.
Function URL (webhook): https://us-central1-myexampleproject.cloudfunctions.net/webhook
✔  Deploy complete!

Once you have the webhook updated, you can test it out on Facebook Messenger.

Feel free to change intents and actions in Dialogflow to start to see how it can work in your communication strategy.

If you’d like to see a full version of this and other Google Cloud examples, you can find it here – https://github.com/nexmo-community/google-cloud-sample-code. If you have any questions or requests for other examples with Google Cloud, Dialogflow or Firebase, open up a pull request or shoot me a message on Twitter.

The post Using Dialogflow with Firebase and the Vonage Messages Sandbox appeared first on Vonage Developer Blog.

Adding 2FA to a React App Using Firebase Functions

Kelly Andrews — Wed, 01 Apr 2020 12:06:34 +0000

If you’re like me, you probably have a few “smart” devices around your home. There are multiple ways to interact and control these devices, but I wanted to be able to control them with text messages and eventually voice as well.

So I set out to build some tooling in Firebase to get me going. The first step I wanted to take, however, was securing the phone numbers that have access, and I thought it would be a perfect time to try out the Verify API. It’s admittedly a bit over-the-top since this isn’t a distributed app, but for safety, a phone number must go through the verification process to access my devices.

Verify API

The Verify API is a way to confirm that the phone belongs to the user. Performing the verification helps protect against spam and suspicious activity, as well as validating ownership.

The API itself has quite a lot packed into it. Its configuration options let you build the exact workflow that works for your system. As an example, the default workflow sends an SMS with a PIN code, waits 125 seconds, then calls with a Text-to-Speech event, waits 3 additional minutes, then calls again and waits 5 minutes before expiring the request altogether.

I like having this level control over something like this as it allows me to be very specific about how I can interact with my users. In my particular instance, I kept it very simple and did just one SMS message that expired in two minutes, since I wanted this mostly for my own purposes.

    let opts = {
      number: context.params.phoneNumber,
      brand: "Total Home Control",
      workflow_id: 6,
      pin_expiry: 120
    };

If you want to get started with the Verify API, you can sign up for a Vonage account today to get going.

Firebase Functions

Since I decided on using Firebase and Firestore, setting up some Cloud Functions to interact with the data and the Verify API was my next step. Each time a new phone number was created, I wanted to send it a verification code and then have a function to check the code.

Promises, Promises

When you first learn Cloud Functions, you may try some simple operations and build your confidence, which is what I did. After going through some of the simple functions first, I figured I’d be able to build this out fairly quickly.

And I was wrong. One detail I completely overlooked is that callback methods do not evaluate in the Cloud Function environment the way they do in other environments. Once there is a returned value or promise, the CPU stops. Since the Nexmo JavaScript SDK is running on callback methods, it stops processing.

Not knowing this had to be one of the more frustrating problems I’ve run into in a long time. The timing of everything was weird because the call back would run when I tried again, causing me to think I wasn’t waiting long enough or the latency was terrible.

Once I sorted that out, I realized I needed to create Promise wrappers for the SDK methods, and everything worked perfectly. If you want some useful tips & tricks, I recommend reading this Firebase documentation guide.

Requesting the Verify Code

The Verify request method in the Nexmo JavaScript SDK is quite minimal code, as the framework there makes it simple to do most everything. The first thing I had to do was wrap it in a promise.

function verifyRequest(opts) {
  return new Promise((resolve, reject) => {
    nexmo.verify.request(opts, (err, res) => {
      if (err) reject(err);
      resolve(res);
    })
  });
}

Creating this wrapper allows the callback method to run and return as a Promise resolution, instead of being ignored.

With this method, I could now create a Firebase function to run when the app added a new number to Firestore.

exports.requestVerify = functions.firestore.document('/phoneNumbers/{phoneNumber}')
  .onCreate((entry, context) => {
    let opts = {
      number: context.params.phoneNumber,
      brand: "Total Home Control",
      workflow_id: 6,
      pin_expiry: 120
    };

    return verifyRequest(opts)
      .then((res) => {
        console.log(res);
        return admin.firestore().doc(`/phoneNumbers/${context.params.phoneNumber}`).update({ req_id: res.request_id })
      })
      .then((res) => console.log(res))
      .catch((err) => console.error(err));
  });

With the Verify API, we need to keep track of the request_id to use in the check process. I use this to indicate that the verification process started but not yet completed.

Checking the Verify Code

Same as the previous example, the SDK method needs to first be wrapped as a Promise.

function verifyCheck(opts) {
  return new Promise((resolve, reject) => {
    nexmo.verify.check(opts, (err, res) => {
      if (err) reject(err);
      resolve(res);
    })
  });
}

Once the user receives it, the React application asks for the code and then calls the function directly from the application, passing the request_id, and the code.

exports.checkVerify = functions.https.onCall((data) => {
  let opts = {
    request_id: data.req_id,
    code: data.code
  };

  return verifyCheck(opts)
    .then((res) => {
      if (res.status === "0") {
        return admin.firestore().doc(`/phoneNumbers/${data.phoneNumber}`).update({ req_id: null, verified: true });
      }
    })
    .then((res) => console.log(res))
    .catch((err) => console.error(err));
});

As long as the code checks out, the document updates to include a verified flag, and the process is over. There are error status responses to check for and respond to accordingly—for example, if the code has timed out. My app currently assumes it passes.

React App

I won’t spend too much time explaining all the code I wrote for my app, but the highlights are adding the data, and then calling the Firebase function from the frontend.

In my app, I have a form to add a new number, consisting of just the phone number field. On submission, it merely adds it to the database. I’ve also set up a Firebase context file that sets the connections between my app and Firebase, so I can easily import everything I need.

import { db, fb } from '../../context/firebase';

//-----//

function _handleSubmit(e) {
  e.preventDefault();

  let data = {
    owner: fb.auth().currentUser.uid,
    verified: false,
  };

  return db.collection('phoneNumbers').doc(phoneNumber).set(data);
}

//-----//

The verification is nearly the same form with a similar submit method.

import { functions } from '../../context/firebase';

//-----//

function _handleSubmit(e) {
  e.preventDefault();
  var checkVerify = functions.httpsCallable('checkVerify');
  checkVerify({ code: code, req_id: value[0]?.data().req_id, phoneNumber: value[0]?.id }).then(function (result) {
    //close the form
  });
}

//-----//

The Firebase SDK provides a functions export to let you use httpsCallable() and name the function. Instead of needing to write any HTTP requests and waiting on those, this simplifies the process.

Wrap Up

The Verify API is simple to use, and with Firebase and React you can quickly write the code needed to validate your users and their phone numbers. Feel free to try it out. You can sign up for a Vonage account, and if you need some credits to get you started send us an email at devrel@vonage.com.

You can find my https://github.com/kellyjandrews/smart-home-app. The app I built is more of a personal app for me, but feel free to have a look and use anything you might find useful. Over the next month or so, I’ll be adding some additional functionality to the app as well—first is opening and closing my garage door.

The post Adding 2FA to a React App Using Firebase Function appeared first on Vonage Developer Blog.

Real-time SMS Demo with React, Node, and Google Translate

Kelly Andrews — Wed, 11 Mar 2020 13:02:01 +0000

Last year I worked with the Google Translate API to translate SMS messages. After showing the rest of the team, they wanted a demo they could show off to other developers at conferences we attended. Based on that, I set out to create a frontend with React that could display the translations in real-time.

Building the WebSocket

What's a WebSocket?

For this demo, I decided that using a WebSocket would be a great solution. If you haven't used a WebSocket before, it's a protocol that allows a client and server to communicate in real-time. WebSockets are bi-directional, meaning the client and server can both send and receive messages. When you first connect to a WebSocket, the connection is made by upgrading an HTTP protocol to the WebSocket protocol and is kept alive as long as it goes uninterrupted. Once established, it provides a continuous stream of content. Exactly what we need to receive incoming, translated SMS messages.

Create the WebSocket Server in Node

As an initial step to creating the WebSockets, the server requires a path to allow for client connections. Starting with the original server file from my previous post, we can make a few minor changes to create the WebSocket server and the events and listeners required by the client.

Using the ws package on NPM, we can quickly create what we need to get this working.

npm install ws

Once installed, include the package in your server file, and create the WebSocket server. WS allows a path option to set the route the client uses to connect.

const express = require('express');
const WebSocket = require('ws');

const app = express();
const server = http.createServer(app);
const wss = new WebSocket.Server({ server, path: "/socket" });

With this bit of code, the client now has a place to connect to the WebSocket route /socket. With the server ready to go, you need to now listen for a connection event. When the client connects, the server uses the following to set up the other listeners we need:

wss.on('connection', (ws) => {
  ws.isAlive = true;
  ws.translateTo = 'en';

  ws.on('pong', () => {
    ws.isAlive = true;
  });

  ws.on('message', (message) => {
    translateTo = message;
  });

});

There are two main points to call out:

On connection, we set the property isAlive to true, and listen for the pong event. This event is for the server to check and maintain a connection with the client. The server sends a ping and responds with pong to verify it's still a live connection.
Here I set up translateTo as a property to store. translateTo is set through each client using a dropdown. When someone using our booth demo app selects a different language, that action sets this to translate the SMS texts into the requested language.

Keeping the Connection Alive

One essential item to be concerned with is checking for clients that disconnect. It's possible that during the disconnection process, the server may not be aware, and problems may occur. With a good friend setInterval(), we can check if our clients are still there and reconnect them if needed.

setInterval(() => {
  wss.clients.forEach((ws) => {
    if (!ws.isAlive) return ws.terminate();
    ws.isAlive = false;
    ws.ping(null, false, true);
  });
}, 10000);

Sending Messages to the Client

Now that the WebSocket is connected and monitored, we can handle the inbound messages from Nexmo, the translation, and the response to the client. The method handleRoute needs to be updated from its original state to add the response for each client.

const handleRoute = (req, res) => {

  let params = req.body;

  if (req.method === "GET") {
    params = req.query
  }

  if (!params.to || !params.msisdn) {
    res.status(400).send({ 'error': 'This is not a valid inbound SMS message!' });
  } else {
    wss.clients.forEach(async (client) => {
      let translation = await translateText(params, client.translateTo);
      let response = {
        from: obfuscateNumber(req.body.msisdn),
        translation: translation.translatedText,
        originalLanguage: translation.detectedSourceLanguage,
        originalMessage: params.text,
        translatedTo: client.translateTo
      }

      client.send(JSON.stringify(response));
    });

    res.status(200).end();
  }

};

The wss.clients.forEach method iterates through each connection, and sends off the SMS parameters from Nexmo to the Google Translate API. Once the translation comes back, we can decide what data the front-end should have, and pass it back as a string as I've done here with client.send(JSON.stringify(response)).

To recap what has happened here: Each client connects to the WebSocket server by calling the /socket route and establishing a connection. An SMS message goes from the sender's phone to Nexmo, which then calls the /inboundSMS route. The app passes the text message to Google Translate API for each connected client, and then finally sends it back to the client UI.

Next, let's build the UI parts to display it on the screen.

WebSockets with React

With the WebSocket server running, we can move on to the display of the messages on screen. Since I enjoy using React, and more importantly, React Hooks, I set out to locate something to help with connecting to WebSockets. Sure enough, I found one that fit my exact need.

The demo app UI is built with create-react-app, and I used the Grommet framework. These topics are out of scope for this post, but you can grab my source code and follow along.

Connecting to the WebSocket

The first step here is to establish a connection and begin two-way communication. The module I found is react-use-websocket, and it made setting this up super simple.

npm install react-use-websocket

There are tons of these React hook libraries out there that help you create some impressive functionality in a short amount of time. In this instance, importing the module and setting up a couple of items for the configuration is all it took to get a connection.

import useWebSocket from 'react-use-websocket';

const App = () => {
  const STATIC_OPTIONS = useMemo(() => ({
    shouldReconnect: (closeEvent) => true,
  }), []);

  const protocolPrefix = window.location.protocol === 'https:' ? 'wss:' : 'ws:';
  let { host } = window.location;
  const [sendMessage, lastMessage, readyState] = useWebSocket(`${protocolPrefix}//${host}/socket`, STATIC_OPTIONS);

  //...
}

In the component, we import the useWebSocket method to pass the WebSocket URL and the object STATIC_OPTIONS as the second argument. The useWebSocket method is a custom hook that returns the sendMessage method, lastMessage object from the server (which is our translated messages), and the readyState which is an integer to give us the status of the connection.

Receiving Incoming Messages

Once react-use-websocket makes the connection to the server, we can now start listening for messages from the lastMessage property. When receiving incoming messages from the server, they populate here and update the component. If your server has multiple message types, you discern that information here. Since we only have one, it's an easier implementation.

const [messageHistory, setMessageHistory] = useState([]);

useEffect(() => {
  if (lastMessage !== null) {
    setMessageHistory(prev => prev.concat(lastMessage))
  }
}, [lastMessage]);

return (
  <Main>
    {messageHistory.map((message, idx) => {
      let msg = JSON.parse(message.data);
      return (
        <Box>
          <Text>From: {msg.from}</Text>
          <Heading level={2}>{msg.translation}</Heading>
        </Box>
      )
    })}
  </Main>
)

The built-in hook useEffect runs every time the state is updated. When lastMessage is not null, it adds the new message to the end of the previous message state array, and the UI updates using the map function to render all of the messages. It is in the messageHistory where all of the JSON strings we passed from the server are stored. The main functionality of our WebSocket is complete, but I still want to add a few more items.

Sending Messages to the Server

Since this is a translation demo, having more than one language is an excellent way to show the power of the Google Translate API in conjunction with Nexmo SMS messages. I created a dropdown with languages to pick. This dropdown is where bi-directional communication happens with the server, and the app sends the selected language from the client.

const languages = [
  { label: "English", value: "en"},
  { label: "French", value: "fr"},
  { label: "German", value: "de"},
  { label: "Spanish", value: "es"}
];

<Select
  labelKey="label"
  onChange={({ option }) => {
    sendMessage(option.value)
    setTranslateValue(option.label)
  }}
  options={languages}
  value={translateValue}
  valueKey="value"
/>

Here, the sendMessage function from react-use-websocket is how we can send information back to our server and consume it. This process is where the event handler we set up comes in handy from earlier. It is this dropdown that determines what language the Google Translate API translates the message into and displays on the screen.

Connection Status Display

Since this is a demo in a conference environment, I thought having a connectivity indicator would be a good idea. As long as the front-end remains connected to the WebSocket, the light displays green.

const CONNECTION_STATUS_CONNECTING = 0;
const CONNECTION_STATUS_OPEN = 1;
const CONNECTION_STATUS_CLOSING = 2;

function Status({ status }) {
  switch (status) {
    case CONNECTION_STATUS_OPEN:
      return <>Connected<div className="led green"></div></>;
    case CONNECTION_STATUS_CONNECTING:
      return <>Connecting<div className="led yellow"></div></>;
    case CONNECTION_STATUS_CLOSING:
      return <>Closing<div className="led yellow"></div></>;
    default:
      return <>Disconnected<div className="led grey"></div></>;;
  }
}

//....
<Status status={readyState} />
//...

The Status component uses the readyState to switch between the various statuses and indicates that to the user. If it turns red, you know something is wrong with the WebSocket server, and you should check into it.

Once everything is up and running, it looks something like this:

Try It Out

The demo application code is on our community GitHub organization, and you can try it out for yourself as well. I've created a README that should help you get through the setup and run it locally on your server or deploy it to Heroku. I've also provided a Dockerfile, if you'd prefer to go that route. Let me know what you think of it, and if you have any trouble, feel free to reach out and submit an issue on the repo.

Send and Receive SMS Messages with Node, Nexmo, and Firebase Functions

Kelly Andrews — Tue, 18 Feb 2020 10:18:00 +0000

The Firebase platform allows developers to build an application backend rapidly. It's also enjoyable to use as well. For this tutorial, I wanted to start using it for some SMS messaging with Nexmo. After this walk-through, you will be able to create an SMS message log, and a response to the sender using Firebase Functions and Firestore alongside the Nexmo SMS API.

Before You Get Started

You will need a few items to get going - so take a moment and make sure you have both of these ready to go.

Setting up Firebase

The first step is to set up a Firebase project. The following will walk you through setting up a new project using the Firebase console.

Create the Firebase Project

Go to Firebase console
Click add project

Add a name and click continue

Leave Google Analytics on and click continue (not required)
Select a Google Analytics account and then click Create Project (if added)

Wait a bit for the project to be created - takes less than a minute
Set the Billing type under ⚙️ -> Usage and Billing -> Details & Settings to Blaze. The Pay-as-you-go plan is required to use a third-party API. For more details regarding billing with Google, go here.
Set the Google Cloud Platform (GCP) resource location in ⚙️ -> Project Settings

Install Firebase Tools

Most everything you will need to do with Firebase can be done directly from the command line with the toolset they provide.

Install the Firebase tools with npm

 npm install -g firebase-tools

Setup Local Environment

Writing Firebase functions requires some initialization work to get started, but it's mostly done for you using Firebase Tools commands.

Create a project folder mkdir nexmo-project && cd nexmo-project
Initialize Firebase Functions firebase init functions

     ######## #### ########  ######## ########     ###     ######  ########
     ##        ##  ##     ## ##       ##     ##  ##   ##  ##       ##
     ######    ##  ########  ######   ########  #########  ######  ######
     ##        ##  ##    ##  ##       ##     ## ##     ##       ## ##
     ##       #### ##     ## ######## ########  ##     ##  ######  ########

You're about to initialize a Firebase project in this directory:

 /your_folders/your-project-name


=== Project Setup

First, let's associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add,
but for now, we'll just set up a default project.

? Please select an option: (Use arrow keys)
❯ Use an existing project
 Create a new project
 Add Firebase to an existing Google Cloud Platform project
 Don't set up a default project

Since you already created a project in the dashboard, you can select Use an existing project which will prompt you to choose the desired project. If you haven't done this, use Create a new project and give it a unique name to create one. You would still need to go to the console to update the location and billing, but it is another option to create Firebase projects.

Select the project name you created
Select JavaScript
Choose Y for ESLint if you desire (I recommend it)
Install all dependencies now

These steps will create the folders and files required to build Firebase Functions and installs all dependencies. Once NPM completes, switch to the functions directory and open index.js in your favorite editor to start adding code.

Create Your First Function

The first function you create will act as a webhook to capture and log incoming SMS messages from Nexmo.

The index.js file has some example code provided you won't need. Delete everything and start at the top to add the following code.

const functions = require('firebase-functions');
const admin = require('firebase-admin'); 

// Initialize Firebase app for database access
admin.initializeApp();

Calling admin.initializeApp(); allows the functions to read and write to the Firebase Real-Time database. Next, use the following method to create your function.

// This function will serve as the webhook for incoming SMS messages,
// and will log the message into the Firebase Realtime Database
exports.inboundSMS = functions.https.onRequest(async (req, res) => {
  await admin.database().ref('/msgq').push(req.body);
  res.send(200);
});

The inboundSMS method listens for HTTPS requests - which is precisely what Nexmo webhook needs. The Firebase Function will capture the req.body and send it to the /msgq object in the Real-Time Database as a log.

Since we are using req.body, the webhook will need to be a POST Method. If you'd prefer to (or you have to) use the GET method for Nexmo webhooks, just replace it with req.query, and the GET method will work the same way.

Now that you have some code written be sure to save your file an deploy the function to Firebase:

firebase deploy --only functions

=== Deploying to 'nexmo-project'...

i deploying functions
Running command: npm --prefix "$RESOURCE_DIR" run lint

> functions@ lint /Users/kellyjandrews/Google Drive/Apps/nexmo-project/functions
> eslint .

✔ functions: Finished running predeploy script.
i functions: ensuring necessary APIs are enabled...
✔ functions: all necessary APIs are enabled
i functions: preparing functions directory for uploading...
i functions: packaged functions (38.78 KB) for uploading
✔ functions: functions folder uploaded successfully
i functions: creating Node.js 8 function inboundSMS(us-central1)...
✔ functions[inboundSMS(us-central1)]: Successful create operation.
Function URL (inboundSMS): https://us-central1-nexmo-project.cloudfunctions.net/inboundSMS

✔ Deploy complete!

Project Console: https://console.firebase.google.com/project/nexmo-project/overview

The vital piece from the output is Function URL (inboundSMS). This URL is required to set up the webhook in Nexmo, which you will do next.

Setting up Nexmo

There are a few quick steps to setting up Nexmo - all done from the command line.

Install the CLI

 npm install -g nexmo-cli

Setup the CLI with your API key and secret from the dashboard https://dashboard.nexmo.com/getting-started-guide
Purchase a new phone number

 nexmo number:buy --country_code US

This command retrieves the first available phone number in the US. For more info on Nexmo numbers, you can view the [numbers documentation](https://developer.nexmo.com/numbers/overview
Type confirm, then copy the number
1. Link the phone number to the webhook using this command

 nexmo link:sms YOUR_NUMBER YOUR_FUNCTION_URL

Give the process a few seconds to completely provision, then test out the new function to make sure the message is getting logged.

Grab your phone and send a message to the phone number. Open up the Firebase console and navigate to database page, and you should see something like this:

Now that there is a way to log incoming messages, you can write a function to do something with the incoming message.

Create the Send Function

So far, you have created a Firebase Function linked to a Nexmo phone number for capturing inbound SMS messages. Firebase Functions can also react to database updates. Upon a new entry, the code sends an echo of the original text.

Start by adding Nexmo to the dependency list - make sure you do this in the functions directory:

npm i nexmo --save

Add the following environment variables to the Firebase config

firebase functions:config:set nexmo.api_key="YOUR_KEY" nexmo.api_secret="YOUR_SECRET"

Next, open index.js add nexmo to the requirements at the top, and import the environment variables to initialize Nexmo:

const functions = require('firebase-functions');
const admin = require('firebase-admin');
const Nexmo = require('nexmo');

// Initialize Firebase app for database access
admin.initializeApp();

// get Firebase environment variables for Nexmo
const {
  api_key,
  api_secret
} = functions.config().nexmo;

// Initialize Nexmo with application credentials
const nexmo = new Nexmo({
  apiKey: api_key,
  apiSecret: api_secret
});

Now you can create the new function for Firebase to send the response:

// This function listens for updates to the Firebase Realtime Database
// and sends a message back to the original sender
exports.sendSMS = functions.database.ref('/msgq/{pushId}')
  .onCreate((message) => {
    const { msisdn, text, to } = message.val();
    // the incoming object - 'msisdn' is the your phone number, and 'to' is the Nexmo number
    // nexmo.message.sendSms(to, msisdn, text);
    return nexmo.message.sendSms(to, msisdn, `You sent the following text: ${text}`, (err, res) => {
      if (err) {
        console.log(err);
      } else {
        if (res.messages[0]['status'] === "0") {
          console.log("Message sent successfully.");
        } else {
          console.log(`Message failed with error: ${res.messages[0]['error-text']}`);
        }
      }
    })
  });

The new function will watch for new messages added to the /msgq database object. When triggered, the full Nexmo object gets passed as message . This object includes msisdn, which is the originating phone number - yours in this case, and the to number, which is the Nexmo virtual number you purchased.

With the phone numbers in hand, as well as the text message, you can now do any number of things. You can create a lookup table to respond with specific data based on the keyword, forward to another system, or in our case, send the original message.

Deploy the Firebase Functions again from the command line:

firebase deploy --only functions

Grab your phone, send another message, and then you should get a response back that looks something like You sent the following text: Test message.

Wrap Up

You have now completed all the steps for this tutorial. You can see the full code on Github.

Now that the initial steps to send and receive messages are complete, my next few posts will take this concept and expand it into controlling some of my home automation via text messages. I would love to hear what you plan to do as well so send me a message on Twitter and let me know.

Translating SMS Messages With Azure Translator Text

Kelly Andrews — Mon, 25 Nov 2019 17:37:06 +0000

In my previous posts, I showed how you can translate text messages with the Google Translation API, AWS Translate. and IBM Watson Language Translator.

Overview

In this post, I show you how to create an inbound Nexmo SMS webhook and translate the message into English using the Azure Translator Text.

In order to get started, you will need the following items set up:

Create Your Project

You will only need a couple of packages to get things going.

@azure/ms-rest-js—this is the Azure SDK and will assist with the credentials
@azure/cognitiveservices-translatortext—this is the Azure Translator Text SDK
express—web framework to serve the webhook
dotenv—a package to load environment variables
body-parser—middleware for Express to handle the incoming webhook object

Initialize the project and then install the above requirements using npm or yarn.

npm init && npm install @azure/ms-rest-js @azure/cognitiveservices-translatortext express dotenv body-parser
# or
yarn init && yarn add @azure/ms-rest-js @azure/cognitiveservices-translatortext express dotenv body-parser

Once installed, create an index.js and .env file.

touch index.js .env

Next, open the index.js file and put the following code inside:

'use strict';
require('dotenv').config();

const express = require('express');
const bodyParser = require('body-parser');
const CognitiveServicesCredentials = require("@azure/ms-rest-js");
const { TranslatorTextClient } = require("@azure/cognitiveservices-translatortext");

const app = express();

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

const server = app.listen(3000, () => {
  console.log(`Express server listening on port ${server.address().port} in ${app.settings.env} mode`);
});

This will set up the server to run the example.

Installing ngrok

Publicly available webhooks are required so that Nexmo can communicate with the application to receive incoming SMS messages. You could push your code up to a publicly available server, or you can use ngrok to allow for public traffic to reach your local application.

You can learn more about installing ngrok with this post. After you have everything ready to go you can start ngrok using the following command to create your tunnel.

ngrok http 3000

Make a note of the ngrok address, as you will need that in a later step.

Setting Up Azure Translator Text

Next you can set up the Azure Translator Text service in the Azure portal. Start by opening the portal and clicking Create New Resource.

On the next screen do a search for Translator Text and click on the result to be taken to the Translator Text info page. Click Create to start the process.

Fill out the name, select Pay As You Go and the resource group, and then click Create at the bottom of the page.

The creation process take a few moments, so relax for a bit until that completes.

Open up the .env file first, and copy and paste the following:

TEXT\_TRANSLATION\_SUBSCRIPTION\_KEY=TEXT\_TRANSLATION\_ENDPOINT=https://api.cognitive.microsofttranslator.com/translate

Grab the key and endpoint from the quick start page and update the .env file with that information.

During my trials, I attempted to use the services endpoint presented in the dashboard, but didn’t have any luck getting it to work correctly. The URL above is the global endpoint that will work if you run into the same troubles.

Setting Up Nexmo Inbound SMS Messages

This example requires a phone number from Nexmo to receive inbound messages. We can do this by using the Nexmo CLI right from a terminal.

Purchase a Virtual Phone Number

First, purchase a number directly from Nexmo (feel free to use a different ISO 3166 alpha-2 country code as needed).

nexmo number:buy --country\_code US

You haven’t created the route as of yet, however you will name it /message. The phone number needs to be linked to this route so inbound messages know where to go. Get the ngrok host name from the previous setup and use it here:

nexmo link:sms phone\_number https://my-ngrok-hostname/message

Now the Nexmo webhook is set up to route inbound SMS messages.

Finish the Application

The only step now is to create the Express route and functions to handle the incoming SMS message and the translations.

Build the Webhook

We can set up the route handler first. Nexmo allows the setting of a default SMS webhook behavior. In the settings panel you can change the default HTTP method used. Mine is set to POST-JSON, and I recommend using this setting. If you are unable to modify your setting, the code used here will handle all three options.

Open up the index.js file, and at the bottom, paste the following code:

// Reading the inbound SMS messages
const handleRoute = (req, res) => {

  let params = req.body;

  if (req.method === "GET") {
    params = req.query
  }

  if (!params.to || !params.msisdn) {
    res.status(400).send({'error': 'This is not a valid inbound SMS message!'});
  } else {
    translateText(params);
    res.status(200).end();
  }

};

This handler will be passed directly to the /message route. If the incoming message HTTP method is POST, the handler uses req.body, and uses req.query for the GET option. It then checks the inbound payload ensuring it has the correct info, then sends the object to the translateText method to display the translation.

Now you can add the route and proper HTTP methods to the application.

app.route('/message')
  .get(handleRoute)
  .post(handleRoute)
  .all((req, res) => res.status(405).send());

The above code will create the GET and POST methods to handle either from the inbound SMS webhook message. If any other method is used, a 405 - Method Not Allowed response will be returned.

The webhook is ready to go and the final piece is the actual translations.

Translation Method

In the previous step we call translateText. This step will create that method.

You will initially get your credentials by using CognitiveServicesCredentials.ApiKeyCredentials. This will need to be passed as the first parameter to the TranslatorTextClient constructor.

After create the client, use the translate method to translate the text. The first argument is an array of languages you wish to translate the text into—allowing you to translate into multiple languages. The service will automatically detect the incoming language if it can. The second argument is an array of objects for the text you want to translate.

function translateText(params) {
  const creds = new CognitiveServicesCredentials.ApiKeyCredentials({ inHeader: { 'Ocp-Apim-Subscription-Key': process.env.TEXT_TRANSLATION_SUBSCRIPTION_KEY } });
  const client = new TranslatorTextClient(creds, process.env.TEXT_TRANSLATION_ENDPOINT);

  client.translator
    .translate(["en"], [{text:params.text}])
    .then(result => {
      console.log(`Original Text: ${params.text}`);
      console.log(`Translation: ${result[0].translations[0].text}`)
    })
    .catch(err => {
      console.error("error:", err);
    });
}

Now you can test out the functionality by starting the server and sending a text message to the number you purchased earlier.

node index.js
# Text "Hola" to your phone number

# expected response
Original Text: Hola
Translation: Hello

The Azure Translator Text full response object has a lot of details as well, so you can change the response to include console.dir(translationResult, {depth: null}) to see the full payload.

Recap

Azure Translator Text is a great tool to translate your inbound messages from Nexmo. This example only scratches the surface, but should be a good start. You can venture off in several directions from here using this as a jumping point. Let me know what ideas you have for using these two services together.

You can find a completed version of this tutorial at https://github.com/nexmo-community/sms-azure-translate-js.

If you want to learn more about the Extend projects we have, you can visit https://developer.nexmo.com/extend to learn more.

The post Translating SMS Messages With Azure Translator Text appeared first on Nexmo Developer Blog.

Translating SMS Messages Using Google Cloud’s Translation API

Kelly Andrews — Thu, 24 Oct 2019 12:12:44 +0000

Text messaging has become a part of our daily lives. We integrate it into multiple aspects like banking, alerts, marketing, and support. It has become simple to implement, and Nexmo is no different.

As a part of the Extend team here, integrating text messages with translation API’s makes perfect sense. Translating incoming text messages can help break down communication barriers and help you reach a broader audience.

Overview

In this post, I show you how to create an inbound Nexmo SMS webhook and translate the message into English using the Google Cloud Translation API.

In order to get started, you will need the following items setup:

Create Your Project

The setup for this example is minimal, and you only need a couple of packages to get going.

@google-cloud/translate – this is the official Cloud Translation SDK
express – web framework to serve the webhook
dotenv – a package to load environment variables
body-parser – middleware for Express to handle the incoming webhook object

Initialize the project and then install the above requirements using npm or yarn.

npm init && npm install @google-cloud/translate express dotenv body-parser
# or
yarn init && yarn add @google-cloud/translate express dotenv body-parser

Once installed, create an index.js and .env file.

touch index.js .env

Open up the .env file first, adn copy and paste the following:

GOOGLE_APPLICATION_CREDENTIALS=./google_creds.json
TARGET_LANGUAGE='en'

Next, open the index.js file and put the following code inside:

'use strict';
require('dotenv').config();

const express = require('express');
const bodyParser = require('body-parser');
const { Translate } = require('@google-cloud/translate');

const app = express();

app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

const server = app.listen(3000, () => {
  console.log(`Express server listening on port ${server.address().port} in ${app.settings.env} mode`);
});

This will set up the server to run the example.

Installing Ngrok

Webhooks need to be publicly available so that the Nexmo service can reach the application when incoming SMS messages are received. You could push your code up to a publicly available server, or you can use ngrok to allow for public traffic to reach your local application.

You can learn more about installing ngrok with this post. After you have everything ready to go you can start ngrok using the following command to create your tunnel.

ngrok http 3000

Make a note of the ngrok address, as you will need that in a later step.

Setting Up Google Cloud Translation API

Once you have the initial items set up, you can now add Google Cloud Translation API to your account. Follow this link to enable the Translation API. Select a project, and then click the Enable button to activate the API on that project.

It is recommended to create a service user that has access to the Translation API. Click here and click + Create Service Account.

Give the account any name you’d like, and press the Create button. After the account is created, add the Cloud Translation API User role, and click Continue.

You will need to create keys for this user. Go ahead and click the + Create Key button, and then select JSON and click create. This will download a JSON file to your machine that you will need to use the account. When that is completed, click Done to complete the creation process.

Copy the credentials file into your project folder:

cp /path/to/file/project-name-id.json ./google\_creds.json

The Google Cloud Translation API is now set up and ready to use.

Next, we can set up the phone number.

Setting Up Nexmo Inbound SMS Messages

This example requires a phone number from Nexmo to receive inbound messages. We can do this by using the Nexmo CLI right from a terminal.

Purchase a Virtual Phone Number

The first step will be to purchase a number (feel free to use a different ISO 3166 alpha-2 country code as needed).

nexmo number:buy --country\_code US

Although the actual route to use in the application isn’t set up, you will name it /message. The phone number needs to be linked to this route so inbound messages know where to go. Get the ngrok host name from the previous setup and use it here:

nexmo link:sms phone\_number https://my-ngrok-hostname/message

Now we have the Nexmo webhook set up as a place for inbound SMS messages to be routed.

Finish the Application

All that is left for this tutorial is creating the Express route to handle the incoming data and a couple of small functions to actually perform the translation.

Build the Webhook

First, we need to build the webhook code. Nexmo has a built in feature for setting default SMS behaviour. In the settings panel you can change the default HTTP method used. Mine is set to POST-JSON. I would recommend using this setting if possible, however the code used in this example will handle all three options in case you are unable to modify this setting.

Open up the index.js file, and at the bottom, paste the following code:

// Reading the inbound SMS messages
const handleRoute = (req, res) => {

  let params = req.body;

  if (req.method === "GET") {
    params = req.query
  }

  if (!params.to || !params.msisdn) {
    res.status(400).send({'error': 'This is not a valid inbound SMS message!'});
  } else {
    translateText(params);
    res.status(200).end();
  }

};

The above snippet is the method we will pass into the routes. If the incoming message is using POST it will use req.body, and it will use req.query for the GET option. As long as the inbound payload is properly set up, the object will be sent along to the translateText method to display the translation.

Now you can add the route and proper HTTP methods to the application.

app.route('/message')
  .get(handleRoute)
  .post(handleRoute)
  .all((req, res) => res.status(405).send());

The above code will create the GET and POST methods to handle either from the inbound SMS webhook message. If any other method is used, a 405 - Method Not Allowed response will be returned.

The webhook is ready to go and the final piece is the actual translations.

Translation Method

In the previous step we call translateText. This step will create that method.

Using the @google-cloud/translate package is really straight forward. We first instantiate the Translate class, which will give us the translate method. This is called within the translateText method and uses the text field from the inbound SMS message object. The target input is any two-letter code for the language to translate into.

const translationApi = new Translate();

function translateText(params) {
  const target = process.env.TARGET_LANGUAGE || 'en';

  translationApi.translate(params.text, target)
        .then(results => {
           console.log(`Original Text: ${params.text}`);
           console.log(`Translation: ${results[0]}`);
         })
         .catch(err => {
           console.log('error', err);
         });
}

Now you can test out the functionality by starting the server, and sending a text message to the number you purchased earlier.

node index.js
# Text "Hola" to your phone number

# expected response
Original Text: Hola
Translation: Hello

The Google Cloud Translation API does an amazing job at detecting the incoming language and processing the translation quickly. Have fun and try it out.

Recap

The example above is just a small introduction to translation, but should be a good start to get you going. From here you can translate the inbound message, and then translate the outbound message into the correct language as well (future blog post, for sure).

For a completed version of this tutorial you can find it at https://github.com/nexmo-community/sms-translate-google-js.

If you want to learn more about the Extend projects we have, you can visit https://developer.nexmo.com/extend to learn more.

The post Translating SMS Messages Using Google Cloud’s Translation API appeared first on Nexmo Developer Blog.

Extending Nexmo – Streaming Transcription Comparison

Kelly Andrews — Tue, 10 Sep 2019 11:00:12 +0000

In the world of communication, words are vital, and getting the right ones is incredibly important. Transcriptions of voice calls can help businesses understand emerging trends in content from sales and support phone calls.

Transcription is the process of taking audio conversations and turning them into written words. In the past, this was handled by humans listening to a recording and typing out the words manually. This practice still exists today. There are now automated services that have emerged, allowing software developers to send audio files to services for a more immediate result.

This work alone can provide incredible insights, but I’m focused specifically on streaming transcriptions where real-time information can provide another level of detail to your sales and support team.

Overview

This post is a comparison and overview of the four leading cloud provider’s streaming transcription services: Amazon Transcribe, Azure Cognitive Speech Service, Google Cloud Speech-to-Text, and IBM Watson Speech-to-Text.

Using the Nexmo Voice API and WebSockets, I connected a voice call from my cell phone and streamed the audio to test the service. During the process, I took a few notes regarding things like features, ease of use, accuracy, and costs.

Accuracy

One of the more critical factors when selecting a transcription service is its accuracy. Having incorrect information would cause any data to be untrusted.

I tested each service using an 8kHz sample rate using my cell phone. You can also use 16kHz, but in some cases, it’s actually less accurate. Using various phrases, I spoke at a relatively average rate of speech at a moderate volume. The room was also quiet enough to remove background noises.

Every service transcribed the phrases I used with no issues, but some of it depended on how well I spoke. Unfortunately, any service struggles with lack of enunciation.

Otherwise, you can feel reasonably confident with any one of these services to handle your transcriptions.

“Stand clear of the doors.”

IBM Watson Speech-to-Text – 90% (It couldn’t get “stand” no matter how clear I spoke)
Azure Cognitive Speech Service – 100%
Google Cloud Speech-to-Text – 100%
Amazon Transcribe – 100%

“Shake well before serving”

IBM Watson Speech-to-Text – 100%
Azure Cognitive Speech Service – 100%
Google Cloud Speech-to-Text – 100%
Amazon Transcribe – 100%

“Peter Piper picked a peck of pickled peppers.”

IBM Watson Speech-to-Text – 100%
Azure Cognitive Speech Service – 100%
Google Cloud Speech-to-Text – 100%
Amazon Transcribe – 100%

Features

The feature sets for most of the services are very similar:

Uses Machine Learning for Accuracy
Custom models for optimization
Audio files and streaming
Contextual formatting for proper nouns
Punctuation support

Language Support

Google Cloud Speech-to-Text has far-and-away the highest number of supported languages at 120 and can auto-detect the language in most cases. The next closest language support is Azure Cognitive Speech Service with 30 and IBM Watson Speech-to-Text with 15. Amazon Transcribe is most restrictive with only 5 languages available for streaming transcription (more available for audio files).

Ease of Use

Each provider has their unique path to success. All of them provide getting started guides in various formats. However, they tend to either be for sending an audio file or capturing microphone input. While microphone input is the streaming method we need to use with the Nexmo WebSocket, it comes with some additional front end code that was unnecessary.

Google Cloud Speech-to-Text

The Google SDK was simple to implement by creating a SpeechClient with the provided SDK and the Google credentials file provided during the service account user.

The SpeechClient provides a method called streamingRecognize which provides events.

const client = new speech.SpeechClient(); let request ={ config: { encoding: 'LINEAR16', sampleRateHertz: 8000, languageCode: 'en-US' }, interimResults: false }; const recognizeStream = client .streamingRecognize(request) .on('error', console.error) .on('data', data => { console.dir(data, {depth: null}); });

Google’s simplicity gets an advantage over other competitors. You can get up and running with little effort, and for me, that’s a huge win.

Google Cloud Speech-to-Text Documentation

Azure/IBM

Both IBM and Azure provide language-specific SDKs and plenty of getting started documentation to get you going, but the API direct call is straightforward to implement. These services can both be used with just connecting to an API route with the wss:// protocol and providing a key.

Azure Cognitive Speech Service

wss://region.stt.speech.microsoft.com/speech/recognition/interactive/cognitiveservices/v1?format=simple&language=LANG\_CODE

IBM Watson Speech-to-Text

wss://stream.watsonplatform.net/speech-to-text/api/v1/recognize?model=langage\_model

There are some additional headers to be provided, but you can find the documentation for each service to be a beneficial resource.

Amazon Transcribe

I have to admit, AWS was the hardest for me to implement. The documentation had very few examples, and the SDK didn’t seem to support streaming services at all. When I first set out to build the Amazon Transcribe integration, HTTP/2 was the only protocol available and required signing every request sent to the server. Being a bit of a novice with AWS in general, this proved to be quite tricky for me.

Where this story makes a great turn around, is when Developer Relations lead, Brandon West stepped in, and wrote some sample code using a WebSocket connection and saved me. The sample code made things much more accessible, but the general authorization process and call signing make Amazon Transcribe a bit harder to implement in general.

Here I used the WebSocket Node package and created a signed URL to create the connection.

let url = v4.createPresignedURL( 'GET', `transcribestreaming.${process.env.AWS_REGION}.amazonaws.com:8443`, '/stream-transcription-websocket', 'transcribe', crypto.createHash('sha256').update('', 'utf8').digest('hex'), { 'key': process.env.AWS\_ACCESS\_KEY\_ID, 'secret': process.env.AWS\_SECRET\_ACCESS\_KEY, 'protocol': 'wss', 'expires': 15, 'region': process.env.AWS\_REGION, 'query': `language-code=${process.env.LANG_CODE}&media-encoding=pcm&sample-rate=${process.env.SAMPLE_RATE}` } ); let socket = new WebSocket(url);

Amazon Transcribe is an excellent service, but if it’s not something you are accustomed to, the learning curve can be a challenge.

Amazon Transcribe Documentation

Cost

All of the service providers offer a lite or free tier to get you started. The base cost is on the amount of audio time transcribed. The providers use different increments of time, so I normalized them in the table below to help you understand precisely the difference in costs.

Provider	Free Tier	Cost	Normalized Cost
Amazon Transcribe	60 min/month for 12 months	$0.006/~10 seconds	$0.036/minute
Azure Cognitive Speech Service	5 audio hours free per month	$1/audio hour	$0.016/minute
Google Cloud Speech-to-Text	60 minutes free	$0.006/15 seconds	$0.024/minute
IBM Watson Speech-to-Text	500 Minutes per Month	$0.02/minute	$0.02/minute

Recap

Streaming transcription is a great way to provide insight in real-time. Each of the four leading cloud providers has great offerings with reliable, accurate speech-to-text services. Using Nexmo as the audio stream is a great extension that allows for more in-depth communication experiences for your customers.

I highly recommend Google Speech-to-text as a solid pick. The price is competitive, and the service is robust and reliable. It’s easy to get set up and start using it immediately, which is a bonus.

If you would like to try out any or all of these services, the Nexmo Extend team has created example code to help you get started.

The post Extending Nexmo – Streaming Transcription Comparison appeared first on Nexmo Developer Blog.

DEV Community: Kelly Andrews

Navigating the World of Developer Relations

Skills

Roles

Advice

Conclusion

My Attempt To Answer How I Lost Weight

The Who

The Why

The How

Eat Less

Eat Less Often

Measuring Success

Final Thoughts

From Magic Shows to Marching Bands: A Busy 2022

Reflecting on my time at Vonage

Firebase

Sentiment Analysis

Chatbots

Transcription

Translation

XState

Oclif and CLI Design

Lerna/Monrepo

Typescript (sorta)

Conclusion

Learn and Apply XState with Vonage Video

Introduction to XState

Building a Vonage Video State Chart

States and State Nodes

Hierarchical State Nodes

Parallel State Nodes

Events and Transitions

Guarded Transitions

Context

Actions and Services

Actions

Services

Resources and Wrap-up

Using Dialogflow with Firebase and the Vonage Messages Sandbox

Prerequisites

Vonage API Account

Create a Firebase Application

Set Up Dialogflow Agent

Download Service Account Keys

Build Functions Locally

The Code

Deploy Functions

Adding 2FA to a React App Using Firebase Functions

Verify API

Firebase Functions

Promises, Promises

Requesting the Verify Code

Checking the Verify Code

React App

Wrap Up

Real-time SMS Demo with React, Node, and Google Translate

Building the WebSocket

What's a WebSocket?

Create the WebSocket Server in Node

Keeping the Connection Alive

Sending Messages to the Client

WebSockets with React

Connecting to the WebSocket

Receiving Incoming Messages

Sending Messages to the Server

Connection Status Display

Try It Out

Send and Receive SMS Messages with Node, Nexmo, and Firebase Functions

Before You Get Started

Setting up Firebase

Create the Firebase Project

Install Firebase Tools

Setup Local Environment

Create Your First Function

Setting up Nexmo

Create the Send Function

Wrap Up

Further Reading

Translating SMS Messages With Azure Translator Text