enhancement: handle paging/cursors

[saturdaywalkers]

Suggestion: Have an option to handle facebook's paging internally. e.g: $fb->get( $url, { handle_paging=>1, limit=>10000} );

It might be complex for the nested calls, which seem to have nested cursors e.g. get albums/photos/likes

Thanks Andrew

[oklahomer]

Thanks for suggestion, @saturdaywalkers.

And yes, I also thought about this paging feature in the past, but decided NOT to include. Let me explain why.

Unintended impact on synchronous page load

Sometimes, on users' web page access, developers proxy requests to Graph API and fetch required objects. When client module internally takes care of paging, developers tend to forget how many HTTP requests are made with one method call. As a result, this single method call takes significant amount of time and server resource exhausts. I have seen this several times so this is one reason I refrain from implementing this.

However, this MAY be prevented by designing this kind of method so that developers MUST pass configuration explicitly to utilize automated paging. So this is not a good enough reason.

Complexity of paging

In the course of application optimization, many developers choose to use Batch Request and Field Expansion. With Field Expansion, paging becomes pretty difficult by its nature. For example, a developer loads /me object with its first 10 photos and first 10 videos. Now what and how do we page? It is totally up to the developer how she optimizes.

Goal of this module

With that said, let us talk about what this module is responsible for and how this is designed. The description reads...

This module is inspired by Facebook::Graph, but mainly focuses on simplicity and customizability because we must be able to keep up with frequently changing API specification.

This module does NOT provide ways to set and validate parameters for each API endpoint like Facebook::Graph does with Any::Moose. Instead it provides some basic methods for HTTP request. It also provides some handy methods that wrap request() for you to easily utilize most of Graph API's functionalities including:

So the simplicity is the core. This paging future may add some complexity while is not profitable for all of us since it may not help those who use Batch Request and Field Expansion for customized request. My suggestion is to create a wrapper method by yourself that takes care of paging where it is required. e.g. Non synchronous batch process.

How does it sound?

[saturdaywalkers]

Fair enough. I thought it might be more complex than it looked at first

Thanks for the detailed and thoughtful response.