Considerations when making External requests in your Actions

Carlo Huamán
OrbisMobile
Published in
5 min readAug 10, 2018

Probably during the development of your first Actions (App for Google Assistant), you added thousands of intents, different kinds of answers, language support, and everything you could, until you said, okay, it’s time to connect to some external API.

There are many ways that you can work it, as well as many libraries, many ways, many other good practices. I don’t pretend to be a definitive list, just an opinion on the things I’ve been through and would like to share. Well, let’s get started!

1 — Separate your constant and common config

Regardless of whether you use a third-party library or native libraries, there will always be a base url where you can make your requests, it is good to have this information in a separate object.

And then, you can use in any part of your code, something like this:

url: ApiConstant.BASE_URL

2— Javascript is Synchronous, work with promises

Nowadays exists many and different libraries for make request in NodeJs, so It’s important to know which one to use based on its features. And I consider one of the most important is that it works with Promises or make them yourself.

Why?, Because remember:

JavaScript is a synchronous, blocking, single-threaded language. That just means that only one operation can be in progress at a time. (Kait Hoehne)

So, it’s probably that you may have problems when you run a request and it takes a while for it to respond, until then your Action will launch a Timeout Exception. But with promises you can solve it. Here are some interesting libraries.

Work with Promises

  • Axios — Promise based HTTP client for the browser and node.js
  • Got — Simplified HTTP requests

Work without Promises (remember here make your owm promises)

I know there are many others available, remember that you are always free to choose the one that best suits your needs. 🙂

3 — console.log() A great ally 😎

I know that the Google console gives us a lot of help with its response, debug and error panel.

Response & Debug Tabs in Action on Google Console
Error Tab in Action on Google Console

But sometimes we need more information in order to see in detail what really happens behind our code. All you need is a console.log(whatever you need) to be able to look more closely at details that may go unnoticed.

Hi, I’m a console.log()

And where do I see the logs? Well, you can choose from the Google Cloud Platform or Firebase Console. Remember to use a tag to help you filter them quickly, I always use Tohure, it’s my nickname 😆.

Google Cloud Plantform
Firebase Console — I prefer this one, don’t tell anyone.😄

Actually at this point, you may use the console.log() not only when working with request, you can use it anytime actually, I just wanted to mention it in case I forgot.

4— Dont repeat the same query, only save the first result

I know it’s strange that I say that, but I’ve seen some people repeat the same query just so that the Assistant can give the result again in case the user needs it again. However this represents another query, another expense and another request, remember time is money.

So what can I do? Save the data in the session. How? With the conversationToken.

The conversationToken field is a string that contains an opaque token that is recirculated to the Actions every conversation turn. (Actions on Google Documentation)

So all we need to do is keep our small data on our object. And I say small because it’s for variables, small objects, some small list or other, it isn’t a database that can store Terabytes of information. There are other solutions for this, but I will talk about them in another post.

You can access conversationToken through the conversational interface “conv.data” and then type the names of the parameters that you want to store.

conversationToken -> conv.data

5 — And last but not least. Your Plan

Your request doesn’t work even though you’ve already checked everything? It’s likely that the error is on the other hand.

If your webhook is built on your own server or service, and depending on how it is configured, then no problem. But if you’re using Firebase Cloud Functions to make your webhook, it’s best to update your plan from Spark to Blaze.

Why? Spark plan does not allow requests to external APIs, only between Google products. It’s in the fine print.

That’s right, it’s there.

But don’t worry, if you’re new to the console, Google will give you a free year to use it as you please. Also, the charge for each request is not much unless your application becomes popular worldwide. Well, in that case, if we had to think of another solution 😅.

Always remember to use Blaze

Conclusion

And that’s it, I’m not a Javascript expert, but several of the situations mentioned in this post, they’ve happened to me and my friends. So I wanted to tell them in case anyone needs them. I’m missing some, so please write me your comments to improve this little ToDo List.

See you next time.

--

--

Carlo Huamán
OrbisMobile

#Jesus is the way, the truth and the life | Dad, Mobile Architect @ BCP, Assistant #GDE | 🚴🥭🍫🍊 | bio.link/tohure