PlayFab

Developer writes CloudScript or Azure Functions

Server-side validation is implemented by writing CloudScript (legacy JavaScript) or Azure Functions. Each API call can trigger custom server logic, but there is no built-in deterministic execution.

Separate codebases (client vs CloudScript)

Client code (C#, C++, etc.) and server code (CloudScript JS or Azure Functions C#) are maintained as separate projects. Logic duplication or REST-based validation is required.

Collection of independent Azure microservices

Each feature (player data, leaderboards, economy, matchmaking) is a separate Azure-hosted service accessed via independent REST APIs. Cross-feature workflows require orchestration.

Client SDKs only; server and dashboard closed

Client SDKs are open source on GitHub, but the server runtime, CloudScript engine, and Game Manager dashboard are closed-source Microsoft services.

Key-value title data stored as strings

Game configuration is stored as string key-value pairs in Title Data. No built-in typing, schema validation, or binary compilation — parsing and validation is handled client-side.

Fixed SaaS dashboard (Game Manager)

Game Manager provides a web UI for player lookup, economy management, and analytics. The dashboard is not extensible — custom tooling requires the REST API.

Managed only (Microsoft Azure)

PlayFab runs exclusively on Microsoft Azure infrastructure. There is no self-hosting option — all data and compute stays within Azure’s multi-tenant environment.

Azure-managed horizontal scaling

Scaling is handled automatically by Azure infrastructure. PlayFab abstracts away capacity planning, but developers have limited visibility into scaling behavior or resource allocation.

Cloud-only; no local backend server

All backend logic runs in the cloud. There is no local development server — testing CloudScript or Azure Functions requires deploying to PlayFab’s cloud environment.