Geocode information for search autocomplete and input query

[khusbuchandra]

Modify the backend api to include geocode information needed for Search component:

• search/autocomplete api should pass along the lat long values along with predictions
• endpoint for search input query to get back search results and its corresponding geocode details.

The above endpoints are needed to avoid additional calls from frontend for getting the geocode information.

[jkwening]

overview for endpoint for search input query to get back search results and its corresponding geocode details:

• ~/controllers/google-api-controllers.js: see exports.autocomplete code snippet as reference. Create a similar api end point using googles places search service. I would simply name the function nearBySearch.
  • key, location, and radius/rankby are required fields. For location I would pass user location, it is stored as state value. I would suggest using rankby=distance param instead of radius - which requires passing "keyword", "name", or "type". Please use "keyword" in that case and just pass search input as the keyword. Actually reading the guide further, maybe we should go with the default - rankby = prominence?
• ~/routes/search.js: under the "Search and Places query endpoints" section, add router.get('/search/:input', <controllerFunc>); and router.post('search/:input', <controllerFunc>)
  • if used what I suggested, then = 'nearBySearch' which you will need to require into the search.js module; see line 9 for reference.
  • the first for generic search request with default params: user location for location and whichever rankby option we go with.
  • the second for flexibility for future enhancement if we want to allow user to configure personal settings which we can inject automatically into the search request calls.

[jkwening]

@khusbuchandra I'll take care off: search/autocomplete api should pass along the lat long values along with predictions while you take a crack at the new end point.

[khusbuchandra]

For input query search, I want to use textSearch request instead of nearby search, as it provides support for ambiguous address queries or incomplete address. Moreover the nearbySearch needs the latlng details as mandatory request parameter, which is not available similar to autocomplete in search. @jkwening , I will proceed with textsearch in case it has limitations for our usage, we can switch.

[jkwening]

@khusbuchandra sounds good to me. If you do run into issues with textSearch, regarding the lat/lng comment for nearby search, it is needed for location biasing of what places to prioritize. As I mentioned, you can pass the user location which is stored as a state object in MapContainer, so you can pass it down to Search component as a prop.

[khusbuchandra]

@jkwening , you have added /map/geocode does it means frontend should make a separate call for selected prediction or you would modify autocomplete api as well to pass geocode data for each prediction?

[jkwening]

@khusbuchandra the former - have frontend make a separate call for the selected prediction. Else, we may end up making too many calls to the api that will surpass our limits since a user can keep changing their mind.

[khusbuchandra]

Thanks @jkwening , exactly my thoughts. I even got the maxed out error today. We need to implement a strategy for that too.

[jkwening]

Completed in PRs #188 and #189. The next steps related to this issue are in #181