question

Tommy Li avatar image
Tommy Li asked

Azure Functions as CloudScript replacement is very unintuitive

I find it baffling that PlayFab wants to deprecate CloudScript this early when the Azure Function integration experience is so not up to par with what JS CloudScript offers.

Just compare to what I can write in TypeScript:

function foo(): { messageValue: string } {
        return { messageValue: `Hello ${currentPlayerId}`}
}

handlers.foo = foo;

And compare to this:

using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;

namespace K4PlayFabServerAzure
{
        public static class HttpExample
        {
                [FunctionName("HelloWorld")]
                public static async Task<dynamic> Run(
                     [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
                     ILogger log)
                {
                        FunctionExecutionContext<dynamic> context = JsonConvert.DeserializeObject<FunctionExecutionContext<dynamic>>(await req.ReadAsStringAsync());

                        return new { messageValue = $"Hello {context.CallerEntityProfile.Lineage.MasterPlayerAccountId}!" };
                }
        }
}

Notice that the C# version only has two lines of code that does the actual work -- the rest are just boilerplate. And it's funny that the C# code, that I modified slightly from the Quick Start page still uses a class that is still yet to be added to the C# SDK. Even though the documentation said they will add it in (which at the time of writing it is still not and is only provided as a source file for copy-paste), why not waiting for things to get ready before pushing this feature hard?? And this did not even include setting up Azure (account, dev env, etc) which is a whole different service from PlayFab right now.

Surely, we don't have a debugger for the JS stuff, but I have been using TypeScript, and with the provided d.ts typings I have rarely tripped myself when I do deploy for testing.

PS. The argument against JS CloudScript could also be that it is not scalable, that you really need Azure Functions for better performance. But Azure Functions have such a sharp learning curve hike that it give people harder time to get things up and running. Some of our project never need to actually utilize the power of Azure, and the simple solution would work just as fine (heck, the free grant of Azure Functions is so plenty that the exec volume of my production project is less than 1% of it according to PlayFab's estimation number when I contacted in private a while ago!), so why force everyone, big and small, to get onboard this new way of doing things when clearly it does not fit even the majority (seeing how many people still posting to ask for JS CloudScript to be enabled)? Why even consider taking the option away when there is nothing close to replace?

----

Update: After a night's sleep, I sat down and looked at the whole thing again with a fresh mind, and I still ended up with the same impression that doing Azure Functions is not easy at all.

It seems that moving CloudScript to Azure Functions effectively removed the CloudScript feature entirely. To call anything back on the Azure Functions side, I would have to set up authentication (Entity Token) before calling any server APIs, which is essentially no different than writing a custom server that runs on Azure, and PlayFab calling your server via a webhook. This is not a very significant step, but because JS CloudScript does the setup for you, the burden is shifted to the developer.

I assume that PlayFab has determined to transition, that further complaints very unlikely make them reconsider. My suggestion would be for PlayFab to provide a toolkit to ease the Azure Function development, like C# code generation to generate the Azure Function boilerplate automatically and make us focus on writing the actual server logic.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
Made Wang avatar image
Made Wang answered

Thanks for your suggestion.

If you have some detailed issues when developing with Azure Function Cloud Script, welcome to post a thread for them so we can try to solve it.

2 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Tommy Li avatar image Tommy Li commented ·

The first step that you all can do is to update the Quick Start guide. For instance, all of the Azure sample code and the template code created by developer tools for HTTP triggers would all return IActionResult, but in the PlayFab's quick start guide, the return type is "dynamic" and plain anonymous object is returned. If this is a specific PlayFab feature, please explain that in the documentation. Otherwise, I would expect the PlayFab sample code to be kept in sync with the latest Azure changes.

Also, in the quick start guide, there has to be a step-by-step configuration guide on the Azure side. PlayFab should also provide a recommended Function App configuration as a starting point. People who need to follow the quick start guide are also people who have no Azure experiences, and they certainly won't expect to be production-ready, so starting simple and minimal can help a lot.

0 Likes 0 ·
Made Wang avatar image Made Wang Tommy Li commented ·

Thanks for your suggestion.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.