Search code examples
javaamazon-web-servicesgoogle-places-apibackendhazelcast

Suggestion to create a proxy API over Google Places autocomplete API

I am a mobile developer and have started using Google Place API for an autocomplete suggestion to find places in my app. But I have observed that Google Places API becomes costly when scaling. So i have made some optimization on the mobile side as follows:-

  1. Limit autocomplete for at least 3 character
  2. The threshold value to make API call for autocomplete is the 500millisecond difference between 2 characters typed
  3. Do a local caching of results with LRU mechanism

With all this optimization client side is good. But now I am also thinking to optimize from backend API side also. For this optimization, I will create a wrapper for google places auto-complete api with server-side caching. This caching will have a time-span of 30days as per Google Guidelines.

I need help to understand how can i design this? Like what key and value combination i need to store autocomplete suggestion? Should I use Redis or Hazelcast? I am writing my Backend in Java with aws server using micro-service architecture. Any already implemented solution where I can look into and learn.

Please help as I am a newbie Backend developer.

Solution

  • Before going down this path, have you done a cost analysis to see if this will be worthwhile? Keep in mind, this is now code that you need to maintain, and cloud infrastructure does require some care and feeding. i.e. in your pricing analysis, don't forget to factor in your time to the cost calculations. Is it still financially worth it?

    Not knowing your transaction volumes, it sounds like you've done a fair amount of free optimization on the client side. If you add the server-side optimizations, you're effectively adding a cloud-to-cloud call, and the extra latency of the various AWS services you're using. Are you ok, taking a performance hit?

    If you still think it's worthwhile, the path I would recommend is to go the serverless route using API Gateway -> Lambda -> DynamoDB. This will keep your costs relatively low since Lambda has a fairly generous free tier. If you need faster performance, you can always insert Redis via Elasticache into the stack later.

    As far as what you need to store, you'd probably want to cache the various inputs the user is entering along with the information returned from the places API. For example, you'll probably want to capture search string, location information, and then any of the fields you want (e.g. place_id, icon, opening_hours, etc.); basically whatever you're using today. It would have very similar needs to your LRU cache.