Remote event/function best practice?

I want some opinions. Is it better to use remote events or remote functions for requesting data for the client?

I know generally you use remote functions when you want data returned to the client. But you could also fire another remote event to the client to do the same thing and send data to the client. Just wondering if there are any…hidden… benefits to using one or the other, if it doesn’t matter that much, or if there’s an optimal “best” practice.

One difference I can think of is the script yielding when invoking a remote function until the data is returned to the client, while with remote events, the script will continue executing. So, remote functions create a latency delay. Isn’t it better to avoid latency whenever possible? Or does it depend on how often I plan on the remote being used?

Let me know your experiences with these.

3 Likes

Remote functions gives you less clutter, also makes things easier to manage, since you only have to deal with one instance instead of two. About the yielding, you can use coroutine, which would skip the delay that the function has when waiting for a response.

3 Likes
  1. Is the less clutter/easier to manage worth the latency that will degrade the experience of the game?
  2. Coroutines could technically work, but wouldn’t that be kind of messy? To be fair, I don’t use them or know much about them. At that point, using two remote events doesn’t seem so bad.

A separate question - is latency even that big of a problem these days? Worth jumping through hoops to avoid still? Not sure.

1 Like

I’m not sure what you mean by latency, is it the yielding delay of the remote function or is it actual latency that affects everything related to communication? I don’t believe there is a difference in actual latency between remote events and remote functions. I don’t think coroutines are messy at all, they’re quite simple to use.
This is what I use:

> coroutine.resume(coroutine.create(function()
> --do stuff
> end))

Or you could use spawn(function() end) instead, which is essentially the same as coroutines, but comes with a slight delay before actually executing, and is a bit less “messy”. I think having 2 remote events is more messy, since each of them needs their own trigger event, instance name, etc.
Think about it, if remote functions had a disadvantage and there is clearly a better alternative to what it does, why would roblox bother adding it?

2 Likes

By latency, I’m referring to the time it takes for remote function to return data back to the client.

Your coroutine code block looks cleaner than others I’ve seen. I’ll consider that if I want to desperately avoid the latency from remote functions. I guess it depends on the specific implementation details, like how often I plan on using them. Thanks!

1 Like

In that case, 2 separate remote events would have the same amount of latency. But yeah, other than that, remote functions do what it does best.

2 Likes

but how do you keep the data constantly updating with remote function?
its better to use remote events because you can send data to client when a change is made to the table which holds the player data something like .Changed function.

for example, when you call a function to change the player’s that like :Increment(player, “cash”, 50) you can use FireClient and you’ll receive the new changed data.

Remote functions are mainly used so that the server and client can BOTH exchange information consecutively, usually in the form of confirmations (Ex: a remote function that lets a player place a block, the server returns true if the block has been placed) or requests for information(Ex: a player wants to see their statistics of a game). If you just want to send information and forget about it, of course you would use remote events instead. You shouldn’t be using remote functions for rapid and constant changes, you only use them as a sort of signal or sending critical data all at once.

3 Likes

Wow that’s really great to know, thank you for replying and answering my question.

1 Like

Most of us don’t use RemoteFunctions. Anything you can do with a RemoteFunction you can do with a RemoteEvent, usually with less overall round-trip time, and no concerns about the call never returning. You can even make write your own RemoteFunction implementation, it’s nothing more than a wrapper around a RemoteEvent that fires the event from a coroutine that yields until it gets the return event.

Most top Roblox programmers agree that the best practice is not just not use RemoteFunctions.

7 Likes