search

cedricdelpoux / react-google-places-suggest

React component to select geolocated suggestion from Google Maps Places API
https://cedricdelpoux.github.io/react-google-places-suggest/
MIT License
86 stars 44 forks source link

Implement Session Tokens. #78

Closed WesleyHovick closed 3 years ago

WesleyHovick commented 3 years ago

The Problem

The current implementation has two flaws:

  1. Currently this component calls the Google Maps Places API on every user inputted keystroke. This results in several, separately billed, API calls which in large quantities can result in very large bills from Google.
  2. This component also calls the Geocoding API on every user's autocomplete selection. This results in additional billed API calls, which in large quantities also results in significant billing from Google.

The Solution to 1

This PR implements session based autocomplete. The AutocompletionRequest allows us to pass in a sessionToken.

Place Autocomplete uses session tokens to group the query and selection phases of a user autocomplete search into a discrete session for billing purposes. The session begins when the user starts typing a query, and concludes when they select a place and a call to Place Details is made. Each session can have multiple autocomplete queries, followed by one place selection. The API key(s) used for each request within a session must belong to the same Google Cloud Console project. Once a session has concluded, the token is no longer valid; your app must generate a fresh token for each session. If the sessiontoken parameter is omitted, or if you reuse a session token, the session is charged as if no session token was provided (each request is billed separately).

I believe this would be a significant win for the google billing portion for consumers of this component.

As I understand it, a session begins with a user typing, and ends with the auto complete being selected from the list. Upon typing again, a new session token is generated. The advantages and benefits here should be quite clear: a potential significant reduction in API calls and billing from Google.

Additionally, consumers of this component no longer have to implement their own debouncing for user input, since it will all be billed together on one session token.

The Solution to 2

This PR implements session based Places Details retrieval, through the PlacesService. We can utilize our existing sessionToken with a getDetails request through this service, and specify the fields that we want to retrieve. In the case of the existing functionality, the Geocoding appeared to be returning the following fields on the payload: address_components, geometry, types. By specifying those fields to the getDetails we can return a payload that looks identical to the current functionality, so there shouldn't be a large breaking change here. One caveat however, is formatted_address. This field appears to exist on the Geocoding result under address_components but no longer appears as a field from the getDetails. We can include the formatted_address in the getDetails by specifying it on the fields, however I don't believe it would live under address_components any longer and would technically be a breaking change to anyone using formatted_address from the address_components property.

This fields data falls under the Basic Data SKU for a Places request and do not result in any additional charge.

This would also allow the component to easily accept a fields prop to address #46

WesleyHovick commented 3 years ago

I'm not sure the rules on your PR validation, so I'm not sure why checks are failing - I didn't change any lock files or anything.

WesleyHovick commented 3 years ago

Closing PR due to inactivity on this repo - Forking instead.

WesleyHovick commented 3 years ago

Re-opening - After thinking about this I decided to leave this open despite forking, as I think it's a very worthwhile change.

atrus777 commented 3 years ago

This change looks awesome! This would be a massive help in reducing some costs! I'd like to have this change as well for my team, ASAP!

WesleyHovick commented 3 years ago

@cedricdelpoux - Thoughts on this PR?

cedricdelpoux commented 3 years ago

Sorry for the delay. Thank you very much for your great work. I will publish asap

WesleyHovick commented 3 years ago

Sorry for the delay. Thank you very much for your great work. I will publish asap

Awesome, thank you! We were still working on integrating the fork into our systems - so we will wait for your publish and use that instead.

cedricdelpoux commented 3 years ago

Published in v3.12.0