Best Practices & Tips

DataReplicator is a powerful tool. Following these best practices will help you get the most out of it while keeping your game secure, performant, and maintainable.

• Register All Keys Upfront

  Use :RegisterKey() on the server for all your potential data keys when the server starts or a player joins. This prevents race conditions and hardens your security by making the rate limiter aware of all valid keys from the beginning.

• Always Use Authorization

  Implement a comprehensive :SetAuthorizationCallback() on the server for any data that shouldn't be universally accessible. It's your most important line of defense for controlling data access. For maximum security, set REQUIRE_AUTHORIZATION_CALLBACK to true in the configuration.

• Don't Trust the Client!

  While DataReplicator secures the replication of data, it doesn't validate the source of data changes. If a client action can indirectly cause a data update (e.g., a remote event that tells the server to buy an item), your core server logic should always validate that action (e.g., does the player have enough money?).

• Leverage the options Table

  • Encrypt Sensitive Data: Always use { Encrypted = true } for data like player currency, stats, or private settings. There is a small performance cost, so only use it where confidentiality is necessary.

  • Use Delta Compression: For any large table that changes frequently (inventories, quest logs, skill trees), always enable { UseDeltaCompression = true }. The bandwidth savings are enormous.

  • Set Priorities: Think about what data is most critical for gameplay. Assign { Priority = "High" } to things like player health and position, and { Priority = "Low" } to things like background environmental data.

• Clean Up Listeners

  On the client, when a UI element is destroyed or a system no longer needs to track a piece of data, always call :StopListening() with the corresponding realKey. This frees up resources on both the client and the server.

• Use :WaitForData() Judiciously

  :WaitForData() is excellent for initial setup scripts that need to guarantee a piece of data exists before proceeding (e.g., loading a player's settings before creating the UI). For ongoing, real-time updates, however, it's always more efficient to rely on connecting to the event from :Listen().