A side project that I decided to take up during my free time and coded this in python. The core idea of this work was to allow me to set up a backend where games could connect to the database via web services. Thus, I decided to use my free time to study up on the different type of web services and study about RESTful API. Which led me to create a centralized Amiibo database for its NFC information as a mini project instead of a game, which also allows me to portray my first idea.
When making a game, usually I will just create a game and directly connect to the database to retrieve information that was required by the application. This was not truly desired since the application is distributed to multiple clients and direct interaction with the main database must cause unforeseen problems in the future.
Have the game applications retrieve information from web service and the web service retrieve it from the database. For example, a game application with a bestiary that players could look at the monster details. Instead of storing all the information into the application itself, which might consume lots of spaces depending on the amount of information that was required. The information could be stored in a central database, where the application communicates with the web service to retrieve and update new monster as they are added to the database.
The web services could break down to different microservices to manage different feature. From there, computation load could be reduced for the applications, thus allowing it to be run on smaller computation devices, e.g smartphones, low-end computer. Since web services allow multiple platforms to read the information, different applications could be made for different platforms using the same web service.
Not sure how much does the web service could handle before it gets too costly. What kind of heavy load can the service handle? Latency issues. Might be desired for a lightweight application, not heavy RPG where latency might be an issue.