One day I opened my bank account statement and realized I got charged $100 from Google Console Team, my first reaction was “What!? I thought it was free”. I then immediately contacted our project team and we had to pause all the development.
That was a surprising instance when we used Google Places API which is a service we used to retrieve information about taco restaurants in the United States. Our original idea was to create a custom progressive application to display taco restaurants based on the user’s location. Although Google Map itself already provides the feature where users can type in “Taco near me” to find taco, our application is uniquely designed for taco junkies who like to hunt the best local tacos in town. We do not just want to bring our users the convenience but also the vibe and mood of how tacos can be recommended anywhere and anytime.
Our team started with a data set on Excel provided by Datafiniti, however, we were concerned about how to bring that data into the code base (“it got to be stored somewhere”) and about how we could display useful information to users. In that situation, we basically have input but do not know how to output it. That was when Google API came up as a solution. In a nutshell, Google as a company has collected data of places and those are stored in a database, from there, through the Application Programming Interface (API), we can write a function to return details of nearby places using the keyword “taco”. Data returned from the API is JSON (JavaScript Object Notation — a lightweight data-interchange format), which is written as name/value pairs such as {“firstName”: “John”}, therefore, making it very easy for our developers to work with.
Given the valuable data including photos, reviews, price level, and basic information of restaurants, we stumbled at monitoring how requests are measured. Every time we make a call to the API to retrieve information, it is considered as one or multiple requests to the web server and because of that unknown and uncertain multiple number of requests, our development accidentally surged up to ~48,000 requests within only 20 days, which ended up costing us $100 since it came across $200 threshold credit provided by Google. It was an immense shock toward our expectation that “everything is free”.
With further investigation, we learnt that there are many hidden factors that cause the number of requests to skyrocket. First and foremost, we did not understand how many requests are made through one call to the API. Secondly, we naively imagine that on a free tier, everything will be free. Thirdly, there must be some operational inefficiency in our code that we need to improve to avoid loop calls.
Did we stop using Google APIs? After weighing the pros and cons of keeping using the service without a solid understanding of how the requests work, we had to pivot to a different direction. What we care the most remains on how to bring much value to our users and to get our hands dirty in data visualization, therefore, this challenge did not shut our door completely. Due to budget constraint, we ended up crafting a JSON file on our own as a fixed set of data for rendering places. As a developer, this is not the most exciting thing I would want to tackle because we all love things to be automated and dynamic, however, we managed to keep 70% of features we set out originally. The biggest feature we had to trade off was that users are not able to get suggestions based on locations and to provide direction from point A to point B anymore, instead every time they go to the application, they will see the same set of restaurants. With this direction, we switch our goal from servicing our users to just demonstrating our idea, which is much more humbling. Half way through the project, we had to give up on building something useful and to narrow down the scope as a Minimum Viable Product (MVP). In addition to that, we simulate the Distance Matrix API by writing a function to calculate distance between two locations on a straight line using latitude and longitude.
Did we have something to launch? No. Did we learn? Plenty of lessons. Perhaps the lessons were painful, we take them for our future experimental projects. Setting a specific budget and researching potential cost for a project is the number one. It is careless to just jump on a project and “just do it”. As much as how we work with our client, we deliberately have a discovery phase to see if we can meet their needs within their budget. Another important thing is to be ready to pivot. With a mindset of being agile, we want to fail fast and learn fast so we do not want to just hold on to the first idea we had. This is what we find incredibly useful when we do our research and receive feedback from end users or insights from our clients. Our designers and developers are willing to work backward and to make adjustments if it makes sense. All in all, we built our muscles on working with API and on weighing between technology and project management stand points to make tough decisions.
And, we manage to get some tacos in place, check it out: https://tacolocation.netlify.app/
