Best practices
Optimize your Cloud Code implementation with C# modules, in-memory caching, and server authority patterns.
Read time 2 minutesLast updated 18 hours ago
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.