I am currently making a REST call to the place details api for the rating and review fields. A smaller percentage of requests are coming back with only the rating returned and not the review field. In those cases still getting a 200.
Reviewed examples of these businesses in google and verified they do have reviews. Most recent example had 22. Verified it was the same place id.
My only other thought was maybe a quota issue, however I dont believe I am reaching 100 per second and would generally receive a different status back.
Related
During an interview I was asked a question stating "There is a product_inventory table with product,quantity column. There is one product in it with quantity 10. You have to design an add to cart functionality such that only 10 requests(Each requesting 1 quantity) should succeed and others should fail".
I had the following approaches to this problem
Use pessimistic locking to update the inventory table quantity as the requests come. This one had the disadvantage that if the
number of requests coming in are too many than they might timeout
which is not a good experience for user.
use Optimistic locking, so even if multiple simultaneous requests come in, only one request
will successfully update theinventory and for ones which get the optimisticException, they can
be retried once before sending an error to UI.
Using trigger before update to check if inventory quantity - requested Qty should be >= 0
Are these valid approaches for this problem. On googling I get shopping websites as results, nothing much on the design of this. How do the websites that conduct Product online Sale handle the request to add to cart for so many simultaneous requests?
UPDATE:
Found this blog post that addresses exactly this problem
https://codingsight.com/the-lost-update-problem-in-concurrent-transactions/
I'm building a graphql schema through AWS AppSync and have a question regarding schema structure. My app will show users new posts and have them either join or pass on them. I'm trying to build in a way that I will only show users new posts and not repeat or at least not repeat for a certain amount of time. It's similar to swiping on tinder, they don't show you somebody again if you've already swiped on them. Does anybody have any ideas how to structure this in my schema. Do I need to store references to all of the seen posts in the user model or should I store each swipe as its own model and how should I structure the querying? I'd appreciate any advice on this.
Thanks!
Assuming a post has a creation time, you could keep track of the last (max created time) post they've seen, then display anything after that.
But think about what happens if they've been off the app for 5 minutes, or 5 days, or 5 weeks... depending on the volume of posts you anticipate they could quickly get behind and have to wade through too many older posts.
One thought would be to show the next oldest post, based derived from the creation time of the most recent post they viewed. Unless N number of posts were created since the last time they were online (a threshold you'd have to decide). Then start with displaying the N - Xth post (where X is 5, or 500, again depending on volume) until they're all caught up.
There are lots of ways you could program it, it all depends on your use case, you may want to take "popular" posts into account for example, those might be weighted above/before the other posts in their backlog.
Hope this helped.
I'm using the Google places autocomplete widget and since Google applied the billing changes the widget is becoming very costly to maintain. I have added the basic parameters which are supposed to be free but when I view the billing I'm still getting charged for the SKU: Autocomplete without Places Details – Per Session. This is the code I'm using:
var searchBox = new google.maps.places.Autocomplete(input);
searchBox.setFields(['place_id', 'name', 'types']);
So my question is, is there a way to get the autocomplete dropdown without getting charged with the new google places API?
Please note that the setFields() method is only applicable when a user selects a place from the autocomplete suggestions. When a place is selected, a Places Details request is made which is the one that generates Data SKUs (Basic, Contact, and/or Atmosphere), depending on the fields that are specified in the request. If you specify Basic Data in your Places Details request, you will be billed for the Places Details request and not for any additional Data SKUs (like Atmosphere and Contact Data) when a user selects a place.
In your case you are only charged for all autocomplete requests and not with any Data SKU. To explain the charge that you got for SKU: Autocomplete without Places Details – Per Session, you are charged for this for the times when a user has not selected any place from the autocomplete suggestions within a few minutes of the beginning of the session. This happens when a user only types characters in the autocomplete input box but is not selecting any place from the search results.
If you have setup your billing account, you will be entitled to the recurring $200 monthly free credits.
Currently, since API requests are charged as per the pricing, if you want to stay in the free tier usage, you can cap your API usage by setting a daily limit to them. This is to avoid unexpected charges by limiting the number of API calls you can make per day.
Hope this clarifies it.
The pricing for implementing the autocomplete SearchBox is different than using the autocomplete widget. The searchbox uses the places text search functionality, which automatically bills for all three places data categories. The widget, however, allows you to mask data fields and automatically creates a session that begins when the user starts typing and ends when a selection is made. With the searchbox, you are getting billed per end user keystroke, which will rack up your charges incredibly fast. I highly recommend implementing the widget over the searchbox.
I'm looking to store Google Place ID for several different places (millions of records). I have purchased a premium plan usage.
Will Google deduct my credits for those records which don't have a Place ID (or Place ID is not returned) ?
Maps API Credits are deducted based on the number of requests made to the Places API, not the values or fields like Place ID, returned within those requests. Credits will be consumed anytime the request doesn't return an error so if you're getting some results (or ZERO_RESULTS), credits are being consumed.
As a Google Maps API Premium Plan customer, feel free to contact the support team for these sort of questions.
I'm trying to build a simple reviews site for a very specific search parameter, which I can pull information back from Google Places API. I understand I cannot store any information other than what Google says I can, and it sounds like I can only store the "reference" parameter and the "id" parameter.
Upon creation of a review for a place returned from Google, I need to store some identifier so that when someone else searches Google Places through my site, I can do an AJAX call to my DB and pull all reviews for that Place.
Ultimately, my question is, which key should I store? Or both?
As per the documentation:
id contains a unique stable identifier denoting this place. This
identifier may not be used to retrieve information about this place,
but is guaranteed to be valid across sessions. It can be used to
consolidate data about this Place, and to verify the identity of a
Place across separate searches.
reference contains a unique token that you can use to retrieve
additional information about this place in a Place Details request.
You can store this token and use it at any time in future to refresh
cached data about this Place, but the same token is not guaranteed to
be returned for any given Place across different searches.
It would make sense to store both, reference to retrieve reviews from Google Places and id to group your place reviews in your db.
As of June 24, 2014 the id and reference fields are deprecated. placeId (for requests) and place_id (in responses) should be used instead.
The Places API currently returns a place_id in all responses, and accepts a placeid in the Place Details and Place Delete requests. Soon after June 24, 2015, the API will stop returning the id and reference fields in responses. Some time later, the API will no longer accept the reference in requests. We recommend that you update your code to use the new place ID instead of id and reference as soon as possible.