What do you need to know to write a game server backend?

Question

Python

As a hobby, I am developing games, I know a little junior c # (I mainly use it in writing game logic in Unity3d) and java (I use it to work with libgdx). I have basic knowledge in javascript, html and css. There is a strong desire to get acquainted in python.
So, I somehow wondered about creating my own game server (or some service located on a remote machine that processes a request from a client and issues a data set in response), but I still don’t know which way to approach this issue. In this regard, a number of questions arose:

1. In which direction to start digging, i.e. what should be read from the theory to create backends?
   
2. What PL and framework is suitable for writing this kind of backend? Is java + spring or python + django or JavaScript + node.js suitable? If yes, which is preferable?
   

Z.Y. so far I started with the fact that I decided to read about REST and RESTful services.
In general, we need a golden pendel that would set the motion vector in the right direction :), otherwise there is a lot of information on the Internet, but I don’t know what to take to achieve what I want :(
Approximately what I want to implement as a seed:
There is a minimum task some kind of game application in which the player can create an account to store a certain set of data in the cloud (on the server), for example: personal achievements and the ability to save the process of passing the game (since it is assumed that the game will be both for the desktop and for the Android-based smartphone) In general, this is the minimum task.On this task, I want to understand how the server part of the game is written, what you need to know for this.

Answer 1

Alexander Alexandrov is unfortunately forced to join Sergey in that you don't know what you need from the server.
You see, all these architectural patterns are "backends" in the web understanding, RESTs are all good and convenient, but the standard web approaches are not always about games and real-time applications.
You have to make many different decisions before doing anything.
> there is a server that the game application accesses to write or retrieve certain player data
This "certain data" is the whole point. It is possible to distribute logic between the client and the server in different ways, but often, especially in games where resistance to cheating is needed, most of the game logic is located on the server. This is much more than "extract player data". If the game logic is located on the server, then the requirements for the data exchange process are appropriate - there is not much sense in REST, because you still have to introduce the concept of "session" or "connection" with the server, and store its state. And your main task will not be in easy scalability to an unknown number of clients, but on the contrary, in maintaining the most comfortable gameplay for existing players, and scaling will be in second place and will be achieved by slightly different architectural solutions.
Many large game projects with a large share of logic on the server use their exchange protocols (usually binary ones) over a regular TCP connection. Many people use different languages ​​for describing such protocols to make it easier to manage development and make changes to the protocol (for example, part of the server and client code can be automatically generated from such descriptions). For example, Blizzes, as far as I know, use Protocol Buffers for Diablo 3.
On the other hand, if your game is essentially a single-player game (like mahjong of some kind) and you only need to save statistics, without special trust requirements (ie. i.e. just for the convenience of the player), then a simple REST service is perfect for you.
you need to decide what level of trust this data has. This will largely determine the architecture. If your project is of a competitive nature, and the substitution of data on achievements or the manipulation of the results of individual games or matches can put an end to the entire project, then the client cannot be a trusted party, and the critical logic should be on the server.

Answer 2

Unfortunately, I cannot help with the first point, but with the second - I can advise: What you know well, write a server on that. You can even write a server in C#, Java, Python or JS...

Answer 3

A good example of REST API implementation in PHP.