tobilg/facebook-events-by-location

.

Opened this issue Β· 23 comments

I didn't change anything, so it must be FB itself. Did you check the FB changelog?

zeeke commented

It seems that Facebook search requests don't have the pagination section anymore. I didn't find anything about it on the API changelog.

I use this tool too, and at this moment, I get lot less events too. For me it's a big problem because this tool here help me a lot to maintain my website "populated" with local/my city events. Now, my idea is search places and pages that generate events in my city and then use AJAX to get the events with https://graph.facebook.com/PAGE_ID/events (but it's not the best solution of course).

The changelog contains nothing regarding this: https://developers.facebook.com/docs/apps/changelog That mustn't mean that FB didn't actually change something. Please keep in mind that this project is a workaround for functionality FB deprecated long ago, so there's no guarantee that this will work forever.

Also, the method it uses is outlined at https://github.com/tobilg/facebook-events-by-location#basics which is actually what @plusownented suggested.

Maybe FB does this cause of it's own "Events" application !

Facebook has started to return paged results when using "/search?type=place" and is giving exactly 100 places per page. Read how this works here: https://developers.facebook.com/docs/graph-api/using-graph-api

@BigFoppa oh that's why wherever i search there is this result ?
"metadata":{"venues":100,"venuesWithEvents":9,"events":139}}
venues:100 or less... but never more !

@tobilg are you planing on updating the core to get more venues (aka pages) ?

PRs are very welcome @kwstasna @BigFoppa... I don't think that I can do this in short term.

Also, please keep in mind that this will lead to a significantly higher complexity and runtime of the queries, if we have to iterate over the pages results...

@tobilg I can't see any other solution about this issue. Since we get only 100 venues.

Maybe... But this will lead to the case that one query could lead to response times from several seconds. So you need to make sure to cache the results locally.

Before FB paginate the places in 100 results, the limit was 1000 ?

I am on a vacation with my family and I am not used to PRs on github (I know I am an oldie, I will have to learn :-) Anyway this recursive function is my solution:

  function pageGet(url) {
    var results;
    var temp;

    function testGet(first, url, after) {
      var tempurl;
      if (after !== "") {
        tempurl = url + "&after=" + after;
      } else {
        tempurl = url;
      }
      return rp.get(tempurl).then(function success(responseBody) {
        temp = JSON.parse(responseBody);
        if (first) {
          results = temp;
        } else {
          temp.data.forEach(function (item, index, arr) {
            results.data.push(item);
          })
        }
        if (temp.paging && temp.paging.cursors && temp.paging.cursors.after) {
          return testGet(false, url, temp.paging.cursors.after);
        } else {
          return results;
        }
      })
    };
    return testGet(true, url, "");
  };

In the file eventSearch.js on line 134 replace this line:

rp.get(placeUrl).then(function(responseBody) {

with

pageGet(placeUrl).then(function(responseBody) {

Note that JSON.parse is already done on responseBody, so line 138 needs to be changed to:

data = responseBody.data;

@tobilg I hope you have use for my solution.

If you are interested in what I am doing with this have a look at eventmap4u.com.

/Big

@tobilg i confirm that the approach of @BigFoppa works like a charm and with a slight delay than before. But i get more than 700 venues and almost 500 events in New York.. Very nice!

@kwstasna glad to help. /Big

@kwstasna and @BigFoppa thanks a lot for your help with the code and the testing. I just published 0.6.0 on npm, including the upstream changes.

Please check it out and let me know it this works better now.

i think @vrgomes is right about it.Events in New York are almost 208. Which is not normal.

@vrgomes @kwstasna So if you're using the raw calls to the FB Graph API, the numbers are equally low? I'm also not aware of any official changes, but history shows that this must not mean that there aren't any...

I checked today, and for the sample URL http://localhost:3000/events?lat=40.710803&lng=-73.964040&distance=100&sort=venue&accessToken= I see the following:

{"venues":179,"venuesWithEvents":4,"events":36}

which seems reasonable. @vrgomes and @kwstasna, do you have some samples which actually show less events? I tested it with different Graph API versions, and all show the same number of results...

In new york
http://localhost/events?lat=40.730610&lng=-73.935242&distance=9000&sort=venue&accessToken=

{"venues":698,"venuesWithEvents":35,"events":203}}

I don't think that this is normal !
normally i get more than 400

Not good news! Facebook have been doing stuff to limit the search api for places.

They are giving less places per search now.
You get more places with an user-access-token than an app-access-token. But only in places where you have been (Facebook magic!) otherwise it’s pretty much the same.
The search has a new (or lower) custom rate limit on number of calls that locks the access-token for a number of hours. And each page in the paged result counts as a call. I think the limit is 100 calls per 600 sec (10 min).

I notice that you guys use very large distances. That will not give you more results.
Try with smaller distance. In a city area you miss a lot of places going over 300-500 meters. But if you do a lot of small searches then you will be rate limited (error 613).

//Big

Thanks @BigFoppa for the update... Is this documented somewhere? Sad that FB continues to artificially cripple it's API.

@tobilg As usual nothing is in the changelog about changes to the search endpoint.
However, found some bug reports here that are interesting. There are some accepted bugs around search. Distance being ignored is something I can also see now.

https://developers.facebook.com/bugs/?tag_ids=236352339738642

Lets hope this problem goes away as with some other previous problems.
//Big