Multiplayer Cloud

Multiplayer Cloud


cloud native game development

Andreas specialized in Highly Scale Able System and Cloud Computing. Currently he is working for Microsoft in the Xbox Developer relations team to help game developers to solve their problems.

Share


Tags


Dependency Injection with the PlayFab SDK

As my work on PlayFabBuddy continues, I'm identifying more ways to better use the PlayFab SDK. One thing I started thinking about was how to use the PlayFab C# SDK and use it with Dependency Injection.

As my work on PlayFabBuddy continues, I'm identifying more ways to better use the PlayFab SDK. One thing I started thinking about was how to use the PlayFab C# SDK and use it with Dependency Injection. Doing this lead me to some realizations that are good to know if you are using Azure Functions (or any other server side Code) that need to work with PlayFab, for example authenticating a User with PlayFab before it can access your custom API.

PlayFab and Dependency Injection

In software development the practice of Dependency Injection is well known and documented. We use it to loosely couple dependencies and achieve the inversion of control in our code.

Now if you are Using the PlayFab SDK the documentation leads you to the Static Classes within PlayFab. Using these gets you static access to the PlayFab APIs without any control over the used HTTPClient.

PlayFabSettings.staticSettings.TitleId = TitleId;
PlayFabSettings.staticSettings.DeveloperSecretKey = DeveloperSecret;

var getTitleEntityTokenRequest = new GetEntityTokenRequest(); //Do not need to set Entity
var titleEntityResponse = await PlayFabAuthenticationAPI.GetEntityTokenAsync(getTitleEntityTokenRequest);
    //If Login was not Successfull
    if (titleEntityResponse.Result == null)
    {
        throw new PlayFabException(PlayFabExceptionCode.NotLoggedIn,
        "Can't authenticate with Developer Secret for titleId: " + TitleId);
    }

Doing this in your code is breaking with the principels of SOLID and therefore makes your code harder to read and maintain.

Why is this bad in the real world?

To make this more practical this is bad practice if you are using PlayFab within Azure Functions or any other managed environment. Because this will cause your managed environment to create a non-optimized version of HTTPClient that might cause too many outbound connections.

How you usually deal with these things in functions is that you are declaring the dependency outside of the scope so it will be reused by the instance.

Instance Classes to the rescue!

For every static class in the PlayFab C# SDK you are provided with an instantiated version of it. This is helpful because it allows you to use it for Dependency injection making your code cleaner and confirm with SOLID. Not just that it also solves the outbound connection in your function app.

Here is an example of how PlayFabBuddy uses this with the .NET Dependency Injection container:

services.AddSingleton<PlayFabMultiplayerInstanceAPI>();

Object Lifetime

Now in this container you have the option to declare different life cycles of your object. In this case Singleton was used to optimize for the HTTPClient being used in this to be only created once and therefore reuse open connections. Transient would create a new instance for every dependency which would be inefficient.

For a web context (ASP.NET Core) you might want to consider Scoped lifetime. As this would allow the Object to be reused within the same request cycle multiple times.

Some of the Instance APIs to require a context object that is specific to a user or admin entity to work. Even though this is sometimes required at creation time these context objects can be overwritten in any method!

PlayFabSettings.staticSettings.TitleId = TitleId;
PlayFabSettings.staticSettings.DeveloperSecretKey = DeveloperSecret;

var getTitleEntityTokenRequest = new GetEntityTokenRequest(); //Do not need to set Entity
var titleEntityResponse = await PlayFabAuthenticationAPI.GetEntityTokenAsync(getTitleEntityTokenRequest);
    //If Login was not Successfull
    if (titleEntityResponse.Result == null)
    {
        throw new PlayFabException(PlayFabExceptionCode.NotLoggedIn,
        "Can't authenticate with Developer Secret for titleId: " + TitleId);
    }
var adminEntityToken = titleEntityResponse.Result.EntityToken;
        
services.AddSingleton(new PlayFabAuthenticationContext { EntityToken = adminEntityToken });
services.AddSingleton<PlayFabMultiplayerInstanceAPI>();

public class MatchmakingAdapter : IMatchmakingAdapter
{
    private readonly PlayFabMultiplayerInstanceAPI _api;

    public MatchmakingAdapter(PlayFabMultiplayerInstanceAPI api)
    {
        _api = api;
    }

    public async Task CreateQueueAsync(QueueConfigEntity queueConfig)
    {
        var createQueueRequest = new SetMatchmakingQueueRequest
        {
            MatchmakingQueue = new MatchmakingQueueConfig
            {
                Name = queueConfig.Name,
                MinMatchSize = queueConfig.MinMatchSize,
                MaxMatchSize = queueConfig.MaxMatchSize
            }
        };

        var result = await _api.SetMatchmakingQueueAsync(createQueueRequest);

        if (result.Error != null)
        {
            throw new Exception(result.Error.ToString());
        }
    }
}

Conclusion

This helps you to get cleaner code and the power to work around missing configuration options in the SDK for HTTPClient we are using the object Lifecyle instead to finetune for our needs and performance.

Andreas specialized in Highly Scale Able System and Cloud Computing. Currently he is working for Microsoft in the Xbox Developer relations team to help game developers to solve their problems.

View Comments