文档

支持

Cloud Code

Open Unity Dashboard

Cloud Code

Best practices

Optimize your Cloud Code implementation with C# modules, in-memory caching, and server authority patterns.
阅读时间2 分钟最后更新于 18 天前
Get the most out of Cloud Code. This guidance can help you optimize your use of Cloud Code to best benefit your projects.

Choose C# over JavaScript

Cloud Code supports JavaScript and C#. Both languages handle high-scale traffic with low latency, but there are several benefits if you use C#.

Use C# modules

C# modules have the following benefits:
  • Modules support code reuse, which improves the maintainability of your project. Like any C# project, the classes and logic between endpoints in the same module can be shared.
  • Module endpoints deploy together, which allows your data models to always be in sync.
  • The Unity Editor can call modules in a type safe way, which helps to prevent errors with misspelled method names and incorrect data parameters.
  • Modules support an in-memory cache, which can speed up response times and reduce costs.

Use an in-memory cache with C# modules

You need a fast response time when a client makes a server call. While calling other UGS services in Cloud Code is fast, each request adds latency. For information that doesn’t change often, you can introduce a cache to speed up response times. For example, you can cache game configurations stored in Remote Config or Cloud Save. When a C# module runs on a worker, the worker shares memory between module endpoints. You can create an in-memory cache (Microsoft) to use between these endpoints. This allows your code to load some information from another service, such as Remote Config, into the in-memory cache and use that cache for the next request. This means your code doesn’t have to call out to Remote Config again until the cache expires.

Limitations of in-memory caching

There are some caveats to using an in-memory cache:
  • There's no guarantee that the module state persists between calls. The deployment of a module, a cold-start after inactivity, or routine maintenance can cause the module to load onto a different worker.
  • Workers can reload for multiple reasons, so don't depend on the data and don't store data that needs to persist long term.
  • Requests from the same user might go to different workers, so don't use in-memory caching to cache player data. This includes caching Remote Config with Game Overrides, unless the Game Override targets all players.
  • A worker has the limit of 128 Mb of memory, so the cache can’t hold large amounts of data.

Block writes from clients

To prevent unauthorised users or players from modifying player data directly, you can block clients from writing to Cloud Save, Leaderboards, Economy, or other UGS services, and only update them though Cloud Code. This concept is Server Authority. You can use Access Control in UGS to prevent unwanted client requests to UGS endpoints. Once you have access control in place, all of the updates to player and game state go through Cloud Code in a server authoritative manner. For more information on how to use Access Control with Cloud Code refer to the access control how to guide.