About offloading work to the client
I have been working on an open source Discord client
for a while, it uses the official REST API and tries to reproduce the
features of the original electron client. When I got to the point where I
could actually chat, one of the first things I tried, was sending emojis.
Well, didn't quite work out. When I entered emoji-sequences like
:sunglasses:, all I got back was plaintext.
But why is that, if the original client converts all those sequences into
actual Unicode characters? This is simply due to the fact, that in order to
implement this feature, Discord uses client-sided business logic. So before
sending the message to the server, for example:
What a great day :sunglasses:
It converts the message into this:
What a great day 😎
This feature works on the desktop-client, the web-client and the mobile-client. However, my client couldn't do it, since the server doesn't do this thing, even though the behaviour is supposed to be the same across all devices (clients).
There are other scenarios though, where even the official Discord clients
differ in their behaviour. Take a look at the commands that the client suggests
you when you type a
/. The desktop-client and the web-client will
show you a list of available commands and allows you to chose one of them.
However, the mobile client does nothing at all, since it doesn't support a
single of those commands. Not even simple ones like
simply inserts a shrugging kaomoji into the message. But hey, who needs
consistency, am I right
So what if the Discord team decides that they want to write an additional client at some point? Maybe a native desktop client that doesn't use electron. Well, they'll have to replicate all client-sided behaviour in their new client, which means additional time consumption and therefore additional cost. On top of that it increases the margin for error. If you write the same code twice in different languages, maybe even with different testing and whatnot, you might end up introducing errors in one version of the code, but not in the other. On top of that, maintaining the code becomes harder, since changing the behaviour on the client means having to change it twice.
Most likely they have a reason to not implement such behaviour on the server-side though. One of the most obvious reasons would be lowering the workloads on the server and therefore reducing the amount of money needed in order to run the backend infrastructure. Even though such a simple feature sounds trivial and like it wouldn't cost much performance, think about how many active users Discord has that send messages every second. Eventually for a big service like Discord it might just pay off.
The next time you implement business logic, you might want to ask yourself the following question:
Does it technically matter where I implement the behaviour? Iff not, what are the benefits for each decision and how much weight do those benefits have to me personally?
My own approach is usually to avoid writing business logic more than once, since it usually just introduces more work in the long-run. As it shouldn't be a problem as long as you don't have scaling problems, whether due to money restrictions or hardware restrictions.