Client-Side and Server-Side

Hello Everyone
I’m just wondering What are the difference between Client-Side and Server-side.

I know what they both do, but I want to know what is something that the Client-Side will handle and what is something that the Server-Side will handle.

For example:
Animations is something that the Client-side will handle.
Maps is something that Server-SIde will handle.

4 Likes

Client side is mostly used for little things ever since Filtering Enabled came out. Lets say we put a local script inside of a text button.

script.Parent.MouseButton1Click:Connect(function()
  Instance.new('Part',workspace)
end)

This will put a part on the client, meaning only the person who clicked will see the part. Nobody else (the server) will see it. Client side normally use remote events to send client side things to the server. Mostly to get local player. It is best to use server scripts though, exploits are local-script based script executors. They execute scripts on the client. This means they can fire remote events.

If I am making a gun, I will use a local script to do this, and then send a request to a remote event to kill the player on the server and not just your screen (that is why most guns from the toolbox are broken, they were made before filtering enabled.) The local script will use plr:GetMouse() to detect when the player clicks or presses a button, and gets the local player with game:GetService('Players').LocalPlayer.

So, client side scripts are used to get local player & send a request to the server, or put something on one players screen. If you want something to happen on one player’s screen but using a server script, you use remote events to send a request to the client.

5 Likes

So is Client-side bad practice to use in most occasions

1 Like

Things that happen on the client do not replicate. Things that happen on the server replicate to everyone. If I create a part in a local script, only the local player will see that part. No one else will. If I create a part in a server script, everyone will see that part. There are exceptions and some things do replicate from client side. Sadly I don’t have a list.

That’s one part of the story. Another aspect is performance. There is no reason the server should handle visual effects or expensive code if the client can do that. In general you want to let the client do as much work as possible. You should only use the server for critical things such as game states, hit detection, etc.

Another aspect is security. Basically if you can’t trust the client, the server has to run the code. Think of websites, they don’t allow clients to authenticate themselves. Never trust the client.

3 Likes

Client side is not bad to use, you just won’t use it most of the time. If you use remote events to send a request on the server it can be exploited depending on what you’re doing.

game:GetService('ReplicatedStorage').RespawnAll.OnServerEvent:Connect(function()
  for index, plr in pairs(game:GetService('Players'):GetPlayers()) do
          plr.Character.Humanoid.Health = 0
    end
end)

This would be bad to use because an exploiter can use :FireServer() and oof the whole server. Using local scripts in general is not bad (exploiters can see local script’s source)

1 Like

So exploiters can’t see server scripts but they are able to see Local scripts

1 Like

Yes, I don’t know how but all I know is it is possible for them to view local-scripts.

This all depends on your game. Is your game a first person shooter? Let the server handle damage, cheat detection, shop interaction, etc.

The client in my opinion should handle things that only matter to the client. For instance the player (client) should handle everything that they’re only supposed to see. UI interaction, animation, tween service, etc.

Also you can create your own system on the client to help performance. Like level of detail, client sided custom StreamingEnabled. It could be as simple as removing assets that are out of view-range and then adding them back when needed.

2 Likes

can you give me an example of when you should use local scripts?

1 Like

They’re allowed to steal and view module and local scripts.

If the scripts are in ServerStorage or ServerScriptService, they can’t steal them. But anything visible/used on the client that isn’t a serverscript can be taken.

2 Likes

Shouldn’t animation be in server script since everyone is supposed to be able to see the animation?

1 Like

If I recall correctly, animations played on the client can be seen by everyone else. It’s like this so there isn’t any client animation replication lag.

If someone has a terrible internet connection and they press ‘E’ to punch, it won’t take 12 seconds to play the animation if it was played on the client.

so animations are a exception to the Client-Side?

1 Like

Let’s say that we want to send data from two games, but we don’t know how to get the player’s join data on the server?

local Tele = game:GetService('TeleportService')
local Players = game:GetService('Players')

Players.ChildAdded:Connect(function(plr)
local data = {game.PlaceId,"E"}
tele:Teleport(placeid,plr,data)
end)

and in the game we want to send data to:

local data = game:GetService('TeleportService'):GetLocalPlayerTeleportData()
print(data[1]) -- would print the game id teleported from
print(data[2]) -- would print "E"

But we want to send it to the server, we need to make a remote event.

local data = game:GetService('TeleportService'):GetLocalPlayerTeleportData()
print(data[1]) -- would print the game id teleported from
print(data[2]) -- would print "E"
game:GetService('ReplicatedStorage').RemoteEvent:FireServer(data) -- sends local script info to the server

Now, in our server script we do:

game:GetService('ReplicatedStorage').RemoteEvent.OnServerEvent:Connect(function(plr, data) -- plr is always the first argument so you can name it whatever you want.

print(plr.Name .. " has fired the remote!")
game['Teleport Service']:Teleport(data[1],plr) -- redirects back to the game teleported from
end)

(read my edit)

Edit2: I did not explain THAT well, so some things you can only access in local scripts. Sometimes you want to send something only a local script can access to the server.

1 Like

So will data be something that you only want a local script to access from the server?

1 Like

I don’t really understand what you mean. What I mean is some things can ONLY be accessed from the client and cannot be accessed from the server (literally, can’t) so you need to send data from a client script to the server. Example: game.Players.LocalPlayer

2 Likes

A simple rule of thumb is the client should only be accessing things that matter for themselves, while the server should handle everything else.

3 Likes

ooh okay I understand.
(And I did have a lot trouble wording that)

3 Likes