I'm currently working on a project in which we perform "Nearby" queries for places using keywords, and then we make follow-up "Detail" requests to obtain more information about specific places of interest.
With Google's new pricing model in the works, the documentation warns about the cost of the Nearby search, but the warning seems to imply that the follow-up detail request will no longer be necessary because our original search should give us everything we need:
By default, when a user selects a place, Nearby Search returns all of
the available data fields for the selected place, and you will be
billed accordingly. There is no way to constrain Nearby Search
requests to only return specific fields. To keep from requesting (and
paying for) data that you don't need, use a Find Place request
instead.
However, I'm not seeing this. When I run a sample request, the results from my Nearby request contains only minimal data related to the places Google finds. To get details, I still have to do a follow-up detail request.
Does anyone know if there's something I may be overlooking? I'm including my request URL (sans API key).
https://maps.googleapis.com/maps/api/place/nearbysearch/json?key=xxxxxxxxxx&location=30.7329,-88.081987&radius=5000&keyword=insurance
And this is an example of one of the results I received:
{
"geometry": {
"location": {
"lat": 30.69254,
"lng": -88.0443999
},
"viewport": {
"northeast": {
"lat": 30.69387672989272,
"lng": -88.04309162010728
},
"southwest": {
"lat": 30.69117707010728,
"lng": -88.04579127989273
}
}
},
"icon": "https://maps.gstatic.com/mapfiles/place_api/icons/generic_business-71.png",
"id": "53744cdc03f8a9726593a767424b14f7f8f86049",
"name": "Ann M Hartwell - Aflac Insurance Agent",
"place_id": "ChIJj29KxNZPmogRJovoXjMDpQI",
"plus_code": {
"compound_code": "MXV4+26 Mobile, Alabama",
"global_code": "862HMXV4+26"
},
"reference": "CmRbAAAAcHM1P7KgNiZgVOm1pWojLto9Bqx96h2BkA-IyfN5oAz1-OICsRXiZOgwmwHb-eX7z679eFjpzPzey0brgect1UMsAiyawKpb5NLlgr_Pk8wBJpagRcKQF1VSvEm7Nq6CEhCfR0pM5wiiwpqAE1eE6eCRGhQPJfQWcWllOVQ5e1yVpZYbCsD01w",
"scope": "GOOGLE",
"types": [
"insurance_agency",
"point_of_interest",
"establishment"
],
"vicinity": "70 N Joachim St, Mobile"
}
I thought about deleting this question, but I guess I'll leave it up in case anyone else is confused like I was.
It turns out the extra detail fields I was looking for in the Nearby Search results were there...sort of.
Google's new pricing model categorizes place data fields into three tiers: Basic, Contact, and Atmosphere (Basic data is free, but the other two add to the cost).
As part of these changes, Place API calls have been expanded to allow users to specify the data fields they want so that they don't have to pay for that extra data if they don't need it.
The Nearby Search query, as per the note in the question, includes all the data fields available, and doesn't support a parameter for controlling the data -- it's always going return data that falls into the [Basic + Contact + Atmosphere] bucket.
So far, that's all well and good.
Where things became confusing to me, though, is the specifics of what is included in the different data tiers. I skimmed through these notes several times before I noticed the contents were different.
This is how the fields break down with the Places details request:
Basic
The Basic category includes the following fields: address_component,
adr_address, alt_id, formatted_address, geometry, icon, id, name,
permanently_closed, photo, place_id, plus_code, scope, type, url,
utc_offset, vicinity
Contact
The Contact category includes the following fields:
formatted_phone_number, international_phone_number, opening_hours,
website
Atmosphere
The Atmosphere category includes the following fields: price_level,
rating, review
And this is how it looks for the Places search request:
Basic
The Basic category includes the following fields: formatted_address,
geometry, icon, id, name, permanently_closed, photos, place_id,
plus_code, scope, types
Contact
The Contact category includes the following field: opening_hours
(Place Search returns only open_now; use a Place Details request to
get the full opening_hours results). Atmosphere
The Atmosphere category includes the following fields: price_level,
rating
I haven't found documentation for it, specifically, but the results from a Nearby Search request seems close (but not identical) to the Place search (including Contact and Atmosphere).
I had originally thought the fact that Nearby Search results now include Contact and Atmosphere data (when available), that meant it would contain all the fields itemized as Contact and Atmosphere data in the Place details documentation, but that's not the case.
Related
We have stumbled across a bug that I can only assume is a bug with the JSON API code. This is for the old laravel JSON API (in my composer.json file its "cloudcreativity/laravel-json-api": "^2.0")
The issue is when a resource is included multiple times (in different ways), it is possible to not get all the include information you asked for.
In my example, I am dealing with timesheets. Timesheets belong to a user. They are also approved by a user. Those users are usually different users, but not always. If I want to include both, I would add include=user,approved-by, and this works great.
The front end also sometimes needs to know the employeeType of the user, so we instead use include=user.employee-type,approved-by, and again this works, we get the employee type info for the user. The issue arises when the user is the same as the approver. It appears that JSON-API gets the approved-by user (without the employee type include data), then when it tries to get the timesheet user, it sees that is has already grabbed that user, and just stops there.
The difference in the output is:
The include with the related in
"employeeType": {
"data": {
"type": "employee-types",
"id": "1"
},
"links": {
"self": "link url",
"related": "link url"
}
},
Vs the include without all the related info
"employeeType": {
"links": {
"self": "link url",
"related": "link url"
}
},
We have a work around, where we need to include the employee type of the user and a the approver, but that seems cumbersome and annoying.
I was wondering if anyone knows if there is any good fix for this? Or if this has been fixed in the more recent version (could be the kick in the pants we need to actually migrate to the most recent version of the library)
I was wondering if an object type that has an id property has to have the same content given the same id. At the moment the same id can have different content.
The following query:
const query = gql`
query products(
$priceSelector: PriceSelectorInput!
) {
productProjectionSearch(
priceSelector: $priceSelector
) {
total
results {
masterVariant {
# If you do the following it will work
# anythingButId: id
id
scopedPrice {
country
}
}
}
}
}
`;
If the PriceSelectorInput is {currency: "USD", country: "US"} then the result is:
{
"productProjectionSearch": {
"total": 2702,
"results": [
{
"name": "Sweater Pinko white",
"masterVariant": {
"id": 1,
"scopedPrice": {
"country": "US",
"__typename": "ScopedPrice"
},
"__typename": "ProductSearchVariant"
},
"__typename": "ProductProjection"
}
],
"__typename": "ProductProjectionSearchResult"
}
}
If the PriceSelectorInput is {currency: "EUR", country: "DE"} then the result is:
{
"productProjectionSearch": {
"total": 2702,
"results": [
{
"name": "Sweater Pinko white",
"masterVariant": {
"id": 1,
"scopedPrice": {
"country": "DE",
"__typename": "ScopedPrice"
},
"__typename": "ProductSearchVariant"
},
"__typename": "ProductProjection"
}
],
"__typename": "ProductProjectionSearchResult"
}
}
My question is that masterVariant of type ProductSearchVariant has id of 1 in both cases but different values for scopedPrice. This breaks apollo cache defaultDataIdFromObject function as demonstrated in this repo. My question is; is this a bug in apollo or would this be a violation of a graphql standard in the type definition of ProductSearchVariant?
TLDR
No it does not break the spec. The spec forces absolutely nothing in regards caching.
Literature for people that may be interested
From the end of the overview section
Because of these principles [... one] can quickly become productive without reading extensive documentation and with little or no formal training. To enable that experience, there must be those that build those servers and tools.
The following formal specification serves as a reference for those builders. It describes the language and its grammar, the type system and the introspection system used to query it, and the execution and validation engines with the algorithms to power them. The goal of this specification is to provide a foundation and framework for an ecosystem of GraphQL tools, client libraries, and server implementations -- spanning both organizations and platforms -- that has yet to be built. We look forward to working with the community in order to do that.
As we just saw the spec says nothing about caching or implementation details, that's left out to the community. The rest of the paper proceeds to give details on how the type-system, the language, requests and responses should be handled.
Also note that the document does not mention which underlying protocol is being used (although commonly it's HTTP). You could effectively run GraphQL communication over a USB device or over infra-red light.
We hosted an interesting talk at our tech conferences which you might find interesting. Here's a link:
GraphQL Anywhere - Our Journey With GraphQL Mesh & Schema Stitching • Uri Goldshtein • GOTO 2021
If we "Ctrl+F" ourselves to look for things as "Cache" or "ID" we can find the following section which I think would help get to a conclusion here:
ID
The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache. The ID type is serialized in the same way as a String; however, it is not intended to be human‐readable. While it is often numeric, it should always serialize as a String.
Result Coercion
GraphQL is agnostic to ID format, and serializes to string to ensure consistency across many formats ID could represent, from small auto‐increment numbers, to large 128‐bit random numbers, to base64 encoded values, or string values of a format like GUID.
GraphQL servers should coerce as appropriate given the ID formats they expect. When coercion is not possible they must raise a field error.
Input Coercion
When expected as an input type, any string (such as "4") or integer (such as 4) input value should be coerced to ID as appropriate for the ID formats a given GraphQL server expects. Any other input value, including float input values (such as 4.0), must raise a query error indicating an incorrect type.
It mentions that such field it is commonly used as a cache key (and that's the default cache key for the Apollo collection of GraphQL implementations) but it doesn't tell us anything about "consistency of the returned data".
Here's the link for the full specification document for GraphQL
Warning! Opinionated - My take on ID's
Of course all I am about to say has nothing to do with the GraphQL specification
Sometimes an ID is not enough of a piece of information to decide whether to cache something. Let's think about user searches:
If I have a FavouriteSearch entity that has an ID on my database and a field called textSearch. I'd commonly like to expose a property results: [Result!]! on my GraphQL specification referencing all the results that this specific text search yielded.
These results are very likely to be different from the moment I make the search or five minutes later when I revisit my favourite search. (Thinking about a text-search on a platform such as TikTok where users may massively upload content).
So based on this definition of the entity FavouriteSearch it makes sense that the caching behavior is rather unexpected.
If we think of the problem from a different angle we might want a SearchResults entity which could have an ID and a timestamp and have a join-table where we reference all those posts that were related to the initial text-search and in that case it would make sense to return a consistent content for the property results on our GraphQL schema.
Thing is that it depends on how we define our entities and it's ultimately not related to the GraphQL spec
A solution for your problem
You can specify how Apollo generates the key for later use as key on the cache as #Matt already pointed in the comments. You may want to tap into that and override that behavior for those entitites that have a __type equal to your masterVariant property type and return NO_KEY for all of them (or similar) in order to avoid caching from your ApolloClient on those specific fields.
I hope this was helpful!
If I have a patient ../Patient/f8d8477c-1ef4-4878-abed-51e514bfd91f,
and a claim ../Claim/<id> which has a reference to the above patient:
"patient": {
"reference": "f8d8477c-1ef4-4878-abed-51e514bfd91f",
"display": "John_Smith"
}
How do i query FHIR to get a bundle that has the Patient and its associated Claims ?
Do i need to add a # in the reference value ?
You could either search for the Patient and _revinclude the Claims, or search for the Claims and _include the Patient. I recommend the latter because it allows for pagination if there happen to be a large number of claims - you want the primary results to be what you're paging through, not the include/revinclude.
Patient?_id=f8d8477c-1ef4-4878-abed-51e514bfd91f&_revinclude=Claim:patient
Claim?patient=Patient/f8d8477c-1ef4-4878-abed-51e514bfd91f&_include=Claim:patient
I am talking about the functionality of the API that can be tested here: https://developers.google.com/+/web/api/rest/latest/people/search
I used to think it looks into all the public fields of a profile ("Specify a query string for full text search of public text in all profiles."), but it seems you can't search by email, telephone or some of the education and work information (even if the expected resulting profiles make this information public).
So my question is, what public data does this search use to retrieve its results? I can't find any documentation on this.
People: search
query string Specify a query string for full text search of public text in all profiles.
I found a random user. here I picked this guy because he had a lot of text in his profile.
Lets search on "gdesignart" This is part of his display name.
{
"kind": "plus#person",
"etag": "\"Sh4n9u6EtD24TM0RmWv7jTXojqc/W9DoYLbchkxsXWI_HhuWV6G7lJY\"",
"objectType": "person",
"id": "116044052555068441384",
"displayName": "Marcello Ghirardi (gdesignart)",
"url": "https://plus.google.com/116044052555068441384",
"image": {
"url": "https://lh3.googleusercontent.com/-IqYeJSv07cI/AAAAAAAAAAI/AAAAAAAAAPM/yw8nbO0Ho6g/photo.jpg?sz=50"
}
Works fine and I get a response.
Now lets try some text from his tagline or introduction arguably we could say this qualifies as public text on his profile.
I tried the following
G-Design®
è un brand
Pollutre of different world
None worked. If you look at the response the only thing in the response is the users display name. From my experience with other google APIs I can tell you that I don't think its going to let you search on any field that is not part of its response. So you are only going to be searching on DisplayName. For the fun of it I searched on his ID that didn't return anything either.
Answer: search is on display name only.
I would recommend adding this as a feature request if you link it here I will happily add my name to it. Google plus issue forum
When using the action breakdown to view the offsite conversions:
act_[ACT_NUM]/reportstats?date_preset=last_3_days&increment=1&data_columns=['campaign_group_id','campaign_group_name','actions']&actions_group_by=['action_type','action_target_id']&limit=1000
amongst the response will usually be something like:
...
{
"action_type": "offsite_conversion.lead",
"action_target_id": "[object_id_1]",
"value": 3
},
{
"action_type": "offsite_conversion.other",
"action_target_id": "[object_id_1]",
"value": 1
},
{
"action_type": "offsite_conversion.other",
"action_target_id": "[object_id_2]",
"value": 7
}
...
We've been using the action_target_id to link to conversion pixels by their id and this still mostly works. However the facebook report on conversion pixels seems to have added the action values for stats with the same tag as the conversion pixel but with different action_target_ids. For example the above referenced object_id_1 for the lead stat appears to link to a creative but its value has been added to the total conversions for one of the lead tagged conversion pixels attached to the account. Not sure if it's relevant but this seems to only be happening to multi product ads on the accounts I've looked at.
Anyone have an idea why this might be the case and whether or not it is possible to consistently link the response from the action breakdown in report stats to conversion pixels?