Is it weird that I don't use remote functions often?

Help and Feedback Scripting Support
#1

Just for some context, I use remote events all the time. I love them, but I’ve never had to or seen a need to send information from the client to the server and back aswell. Usually for almost everything I’ve done remote events have been the way to go.

And it’s not like I haven’t made complicated systems yet either.

I’ve been scripting for 9 months and I think there was only ONE time where I may’ve POSSIBLY needed to use a remote function, and I’m pretty sure I was able to switch to a remote event instead because I realised there was another way to do what I wanted.

1 Like
#3

Server → Client Remote functions aren’t used too often because of vulnerability (you can patch it, but the data can still be iffy)

Client → Server Remote functions are more widely used because they’re more secure and you can guarantee the data will likely be correct (since the server is returning it).

If you just need to trigger something to happen, then you won’t need to use RemoteFunctions, but when you need specific data held on the server to be transferred to the client, you’ll find them much more useful.

So no, it’s not weird.

#4

Definitely not, remote functions shouldn’t be needed very often, if at all. And since they can’t really transfer un replicated data, if it’s an instance you might as well yield using WaitForChild.

#5

But I don’t understand use-cases for remote functions at all, most can be simply replaced by a regular remote event.

Also can you please elaborate on how you can gaurantee the data will be accurate?

Usually you can check the accuracy of the data simply through a remote event sanity check:

-- Client
if player.leaderstats.XP.Value > 500 then
UpdateLevel:FireServer()
end

-- Server
UpdateLevel.OnServerEvent:Connect(function(player)
if player.leaderstats.XP.Value > 500 then
player.leaderstats.Level += 1
end
end)
#6

Another thing too, RemoteFunctions are asynchronous, yet they also are yielded, so it creates more complexity, Remote Events are also more secure depending on use.

#7

I don’t know if this is what you meant by this, but you can’t trust this data as you can’t trust anything the client provides.

#8

Think of this,

RemoteEvents - It’s like firing a gun, the person you fire it at, doesn’t come back (they are dead :skull:) (Hence FireServer/Client)

RemoteFunctions - You invoke, it’s like punching someone, you’re going to get a response. (Hence, InvokeServer/Client)

RemoteFunctions must be handled, they MUST return something. Remote Events do not.

1 Like
#9

The example you provided is something that works with RemoteEvents; you aren’t returning anything to the client or the server.

Think about loading a webpage: your client sends a request to the server for the webcontent and the server returns the information so the client can load and display it, that’s essentially what a RemoteFunction is

That’s what I was saying

1 Like
#10

I was talking about the information the server returns.

#11

Another thing,

Both Remote Functions and Remote Events are Asynchronous, because obviously you don’t want to halt the server.

However, RemoteFunctions are Asynchronous on the Server, but on the Client they are Synchronous in behavior, since the client will yield until a response is provided.

Ex:

--- Server Script

function RemoteHandler()
    task.wait(2)
    return "Hi"
end
--- Local Script
local RemoteFuncPromise = remoteFunc:InvokeServer()

-- RemoteFuncPromise -> returns Hi after two seconds

--- Server Script
function RemoteEventHandler()
    task.wait(2)
    print("Hi") -- Prints hi after 2 seconds
end
--- Local Script
RemoteEvent:FireServer()

-- Code continues executing, will not wait for the server.
#12

The info the server returns is more secure because the developer is the one managing what is returned from the server side (assuming you’re coding everything correctly), whereas InvokeClient isn’t secure because the client can be tampered with and return anything

#13

i havnot ever used remote functions i just use remote events

#14

That’s true, but nothing on the client can be trusted, so neither of them are secure.

#15

With this information, you may actually need to use a Remote Func, maybe because you want to ensure that the data/job/task or whatever your sending to the server is fully complete, this allows you to yield for the server and detect when it’s done something.

#16

I think this is the correct answer, also an annoying feature of remote functions is the yielding. It may be slightly more secure, but let’s say you want to do something whilst its yielding. Now you have to use task.spawn/coroutines which is really a problem (just a personal grudge)

A remote event sanity check should usually be enough, returning shouldn’t really be necessary imo.

Edit: I misunderstood, sorry.

#17

I’m confused, what do you mean? The server’s information is coming from the server. If you’re talking about how the client uses that information, that’s not exactly what I was talking about; I was talking about the info itself

#18

How is using task.spawn or coroutines an issue?

#19

It isn’t I just edited it because it sounded like I made it sound worse than it is, it’s just a personal grudge.

#20

I thought you meant that because the security of info on the client isn’t really important unless the server has to use it.

#21

Well I’d definitely tell your personal grudge to go away, because if you want to code stuff that’s performant, utilizing multi-threading is VITIAL