Open devpanda0 opened 3 months ago
Hey, thanks for your suggestion. We are going to have an internal discussion on how to best implement this.
How would you distinguish events using early returns (so it wouldn't be an if statement xmas tree) from RPCs?
How would you distinguish events using early returns (so it wouldn't be an if statement xmas tree) from RPCs?
What do you mean exactly?
What do you mean exactly?
api.onClient("someRPCHandler", (player: api.Player, vehicleModel: string) => {
// how would the api know, if it supposed to return the value given here, or just stop the execution?
if (!auth.isPlayerAuthorized(player)) {
return;
}
// it's a bad coding practive, but in case the developer
// returns in the same line with a function call to an infobox, for example (or it returns something it really shouldn't, more sensitive stuff.)
if (!vehicleModel || !api.vehicleModels.includes(vehicleModel)) {
return infobox.send(player, "Invalid vehicle model", "error");
}
// obv success return
return true;
});
And there are probably more cases I didn't think about, that could cause problems.
What do you mean exactly?
api.onClient("someRPCHandler", (player: api.Player, vehicleModel: string) => { // how would the api know, if it supposed to return the value given here, or just stop the execution? if (!auth.isPlayerAuthorized(player)) { return; } // it's a bad coding practive, but in case the developer // returns in the same line with a function call to an infobox, for example (or it returns something it really shouldn't, more sensitive stuff.) if (!vehicleModel || !api.vehicleModels.includes(vehicleModel)) { return infobox.send(player, "Invalid vehicle model", "error"); } // obv success return return true; });
And there are probably more cases I didn't think about, that could cause problems.
I guess the return value will be undefined
in that case where there is no return value
yes
imo the receiver should still receive the null value so that it knows its null.
simply check whether a value is returned
ehh idunno, I still think there would be edge cases with this.. It's better to be more strict, especially if a client could reach these handlers.
if you program cleanly, you won't have any difficulties
Could you be more specific about what edge cases you mean?
yamp.onClient("name", (player: yamp.Player) => {
return true;
}, true);
Another possibility could be to set an optional third argument to true when it is an rpc
if you program cleanly, you won't have any difficulties
Right, but what if a less experienced dev doesn't know how what's the difference between the two, and do something stupid?
Could you be more specific about what edge cases you mean?
For example, the developer expects a handler to work as an RPC, but a (malicious) client triggers it as an event. (ik it's a dum example, but atm I couldn't think of any better)
I rather would do something like yamp.onRPC
, so the developer could just look at the function call, and see if it's an event or an RPC.
If we do the RPC it will for sure have different api from Events, it's way too confusing otherwise.
something like
events: emit, on rpc: call, register
What is the scope of the api ?
Propose an api design A clear and concise description of what you want to happen.
The idea is not to need an extra RPC function if the event system could do it.
I built it with RabbitMQ and I find it more relaxed this way
As soon as
return
is included in the.on*
function, it knows that it should be an "RPC".I have 2 examples here of what I mean:
Examples in JS/TS Example 1 (with answer):
Example 2 (no answer):