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.