Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Promises for API calls #90

Open
403-Fruit opened this issue Dec 2, 2020 · 3 comments
Open

Support Promises for API calls #90

403-Fruit opened this issue Dec 2, 2020 · 3 comments

Comments

@403-Fruit
Copy link

I've been using both this SDK and the NodeJS SDK extensively for a few months now, and I've found that the SDKs are much easier to use when API calls are promise-based. I've been using a wrapper function that provides this functionality, which works fine but is not ideal. That looks something like this (shortened for brevity)

function playfabAPI(endpoint, requestObject) {
    return new Promise(function(resolve, reject) {
        PlayFabClientSDK[endpoint](requestObject, function(error, result) {
            if (error !== null) {
                // Request error
                return reject(new Error(error));
            }
            else if (result && result["code"] == 200) {
                // Request successful
                return resolve(result);
            }
            else {
                // Non-200 HTTP status
                return reject(new Error(result.status));
            }
        });
    });
}

This makes for cleaner code, adds useful functionality, and eliminates a lot of redundant error checking code. The current request functions are consistent enough for this to work in most cases so far but I'm a bit wary of using it in production. What I would propose is to implement this either alongside the current format, or as an additional SDK/script, for compatibility reasons.


Example of how this change could be implemented in a given function:

Current

exports.UpdateUserData = function (request, callback) {
    if (PlayFab._internalSettings.sessionTicket == null) {
        throw "Must be logged in to call this method";
    }
    PlayFab.MakeRequest(
        PlayFab.GetServerUrl() + "/Client/UpdateUserData",
        request,
        "X-Authorization",
        PlayFab._internalSettings.sessionTicket,
        function (error, result) {
            if (callback != null) {
                callback(error, result);
            }
        },
    );
};

Proposed

exports.UpdateUserData = function (request)
{
    return new Promise((resolve, reject) => {
        if (PlayFab._internalSettings.sessionTicket == null) {
            throw "Must be logged in to call this method";
        }
        PlayFab.MakeRequest(
            PlayFab.GetServerUrl() + "/Client/UpdateUserData",
            request,
            "X-Authorization",
            PlayFab._internalSettings.sessionTicket,
            (error, result) => {
                if (error !== null) {
                    return reject(new Error(error));
                }
                else if (result && result["code"] == 200) {
                    return resolve(result);
                }
                else {
                    return reject(new Error(result.status));
                }
            },
        );
    });
};

Example usage of current vs proposed usage:

Current

PlayFabClientSDK.UpdateUserData(requestParameters, function(error, result) {
    // Check for + handle errors... 
    // Handle result...
});

Proposed

PlayFabClientSDK.UpdateUserData(requestParameters).then((userDataResult) => {
    // Handle userDataResult...
}).catch((error) => {
    // Handle errors... 
});

This would also have the added benefit of allowing the use of async/await which can greatly simplify code structure, e.g. when chaining requests

(async function() {
    const userDataResult = await PlayFabClientSDK.UpdateUserData(requestParameters);
    // Handle userDataResult/make additional API requests
})();

Let me know what you guys think. Is this something that would be better served using the SDK generator with a custom config, or would it be feasible to get an official implementation?

@pabloes
Copy link

pabloes commented Jan 18, 2021

same in PlayFab/NodeSDK#108

Im also using wrapper functions

@Mounajidev
Copy link

Hello, i am stuck trying to implement PlayFab SDK in my react project since like 3 months. Finally i am getting it work, but still not able to deal with waitting the callback results to make another API call. and i was trying to implement the async/await method for calling them, but with my knowledge it is very dificult. I would like to try to do something similar as you explained there, is a way you can explain it better how i would implement it for begginer please ?.
i am trying to deal a RegisterPlayFabUser, then wait until the response is ok, and then execute AddOrUpdateContactEmail API call.

@pgilmorepf
Copy link
Contributor

I would like to thank everybody for their feedback and their interest in the PlayFab SDKs. I understand that the lack of this feature has been problematic for your development, and collectively you share an interest in making this feature a reality.

Many of PlayFab's SDKs are community supported, IE Microsoft reviews and quality controls the product, but in many cases, customers like you contribute to these projects for your own mutual benefit. Another important detail, as you may be aware, these SDKs are built using a code generator, which converts pseudo-swagger documents into JavaScript code. I would encourage you to integrate the change you propose into a Pull Request into the SdkGenerator. There are automated tests which operate on the JavaScript and Node outputs generated from this SdkGenerator. If those tests pass, then a human reviewer will verify the code and approve it.

I'm sorry that we can't currently implement this feature request for you, but I look forward to a pull request over there.

Thank you for your interest and time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants