Facebook - api suggestion - bulk fetch

[Rob Blair]

I have found it useful for speed reasons to issue bulk requests to facebook, and have created a variant of FacebookTemplate that takes a map of ids:

public <T> Map<String, T> fetchObjects(Collection<String> objectIds, 
        Class<T> type, MultiValueMap<String, String> queryParameters) {
    String ids = join(objectIds, ",");
    URIBuilder uriBuilder = URIBuilder.fromUri(GRAPH_API_URL + "?ids=" + ids);
    ...

This can be used to fetch a large number of homogenous objects by id from facebook, rather than one by one.
Examples: retrieving the Event details of several events, getting the FacebookProfile of multiple friends at once.

Likewise, multiple ids can be used on a connection, such as retrieving checkin information from multiple friends at once:

public <T> Map<String,List<T>> fetchMultiConnections(Collection<String> objectIds, 
        String connectionType, Class<T> type, MultiValueMap<String, String> queryParameters) {
    String connectionPath = connectionType != null && connectionType.length() > 0 ? connectionType : "";
    String ids = join(objectIds, ",");
    URIBuilder uriBuilder = URIBuilder.fromUri(GRAPH_API_URL + connectionPath + "?ids=" + ids);
    ...

Is there any utility in bringing those into the core library?

I've implemented those functions, but have not added multi-id variants to all the XYZOperations implementations, since it would double the number of functions.

Thanks,
rbb

[habuma]

I can definitely see the usefulness of the lower-level fetchObjects() and fetchMultiConnections() methods. Like you, however, I do have some reservation about using these in the higher-level methods, because as you said it would double the number of methods (not exactly, but it would certainly introduce quite a few variants).

I'm willing to consider it. Do this: Submit a pull request for FacebookTemplate with the methods you describe above. Then, after that is merged in, we can toss around what to do with the higher-level methods.

[Rob Blair]

I'm new to the Git world, and not sure if my corporate masters are OK with me giving code away. They can be a bit fussy.

And yes, I do completely understand not wanting to double the number of end points. Even as is, there are many call variants that are missing. Some of the calls fetching Post subclass would require special deserialization handling in the fetchMultiConnections world too.

[habuma]

That's unfortunate, but also completely understood. I created https://jira.springsource.org/browse/SOCIALFB-70 to track this and will try to get to it myself at some point. Even if you can't contribute code, it is a good suggestion--thanks for suggesting it!

[Rob Blair]

Thanks habuma!

One other thing I needed to add - a public deserializer to turn the JSON Status posts into Post sub-classes, in FeedOperations:

/**
 * Turns a generic list of jsonNodes that represent post data into actual Post objects
 * Useful if you want to issue a custom fetch on feeds or new that are not directly
 * in the FeedOperations interface
 * @param jsonNode posts retrieved directly through a fetchConnections call. 
 * @return
 */
List<Post> deserializePostList(List<JsonNode> jsonNodes);

or the function <T> T deserializePost(String postType, Class<T> type, ObjectNode node) made public.