How NOT to autocomplete

Ever fancied customising the default autocomplete to make it more appealing? Well, you’re in luck! Just make sure you don’t end up paying a lot more than what you should be, like we almost did.

Read on to understand how best to optimise calls to avoid unnecessary billing.

This probably has been the most time consuming issues we have looked at this year. Okay, I admit, not as much as what we faced last year, where a library randomly decided to throw errors (PS: It wasn’t the library’s fault, it was just a collision between duplicate libraries). Or when gitlab autodevops would magically configure kubernetes and not be explicit as to why our overriding didn’t work. The list is too long!

We had to implement google autocomplete . The ask is to have a google-search like autocomplete where one could simply search for places or queries. How one would normally implement this is simple. Leverage an autocomplete widget and integrate it with an input field. That’s basically it. There’s immense capability this widget offers out of the box. Debounced search, responsive styling, the confidence of being a google widget. It’s a win win.

We wanted to go a step further. How about customising the autocomplete layout for ourselves. Put it simply, the suggestion box should be independent of the input field and should be easily integrated as a plugin. Thus, one could play around with the input field and the suggestion box quite flexibly with the binding logic hooking the two up.

The Autocomplete service to get raw predictions in the json format and the Places service to fetch raw places data came to our rescue. One needs to write custom code to integrate the input field, suggestion box and the places api to work in unison with each other. That required a fair bit of complexity to make everything work. But in the end, everything worked!

While that was still a doable bit, we really want to touch up on an important aspect of the whole implementation — billing. It’s important to understand that using a widget comes with inherent advantages. The widget itself is optimised for least expenditure (although we realised there was still a scope of reducing the billing further). But when you’re building one on your own, it’s on you to make sure you don’t end up paying extra. We screwed up, and we realised it after spending hours understanding the pricing model and the scope. Mentioned below are few key areas to look at while implementing the same:

1. Session tokens
   These are important. Extremely important. Simply put, they inform google that when you search for “Time sq” and then eventually choose “Times square” from the list of suggestions, it’s just one search. If you don’t, well, you’ll end up paying for each request you make, i.e., 6 requests for the 6 characters you type + 1 request for choosing a suggestion. Compare this to a simple the scenario where a session token helps identify a sequence of requests as one complete search, hence charges incurred for only 1 final places request. That’s almost 7 times of what you should be paying for.
2. Optimising places response
   A lot of times, all you want from your search is the geo location of the place. May be you don’t want any nearby places, or any contacts associated with that place, data about weather etc. Each of these datasets (the official term used by google for these datasets is SKU) cost you money. As a result, you should be extremely explicit in asking for only the data you want. Surprisingly, the autocomplete widgets isn’t optimised to do that out of the box. It ends up bringing you a lot more data than just the Basic data.
3. Understand the pricing clearly
   Honestly speaking, the pricing model is complicated. It’s lengthy, has a lot of catches and conditions, and doesn’t simplify how much you might end up paying. As an example, the price you incur is different when you:
   - Search for a place and then fetch a place’s detail (for example, typing Times Sq and then eventually choosing Times Square)
   - Just type in a place’s name (Just typing in Times Sq and NOT choosing Time Square)
   - Directly request a place detail (for example, getting the details about Times Square directly, without even searching)
   The first lets you off from paying the price for the individual requests. You only pay for the places api call, as the intent was ultimately to find a place.
   The second charges you for just the search, even though you didn’t choose a place. The last one charges you just like the first one. Also, the time between searching and eventually selecting a result is also important. If you search for a place and choose a result, let’s say, 10 mins later, the price you incur might include the price for search api call + places api call.
   What I’m trying to say is, read the pricing very carefully. Nothing is hidden, it’s just a lot to digest.
4. Debounce!
   Let’s say you were searching for “Times square”. Do you really want to make 12 api calls for every keystroke you make while typing the place name? Or would you rather make intermittent api calls only when the user pauses typing. I used to think this might be a tricky bit as it might require one to understand user’s typing behaviour. But honestly speaking, using something as simple as debounce doesn’t really impact the user experience. We are yet to see how big a difference this makes to our volume of calls, but we are estimating a 90% reduction in the number of calls. Although google doesn’t charge you for the number of calls as long as you’re maintaining proper discipline like using session tokens, making justified search calls etc, there are per day/per minute upper limits you might want to avoid.
5. Monitor, monitor and monitor!
   This is the bit that helped us immensely. I really like the detailed monitoring google provides around its services. You can drill down to per minute granularity. I do agree that the interface is confusing. But it’s still great! You can literally start monitoring your expenditure from hour 1 of deployment.
6. Leverage free credits and promotions
   Google is quite modest in giving $200 of free monthly credits to verified accounts (the ones with their billing details updated). And that’s quite sufficient for a low traffic website. All you need to do is to make sure you don’t miss any requirements they have (for instance, using session tokens).

It’s quite easy to make sure everything is well covered while implementing all of the above stuff, but frankly speaking, it’s equally easy to miss one. We spent days tweaking our implementation to reduce the billing to a minimum. And we did. We have managed to bring it down by >90%.

Hope this helps!

Cheers!