How is persistence managed by browser games?

Question

I was wondering,

when you play browser games you never seem to witness a page refresh, even if there is data being stored on the server. So how are databases handled by browser games.

In my opinion there are several possible scenarios:

1. Data is being modified during your absence. Let's say in FarmVille your plants will grow while you are not using the application. So is this data being constantly updated on the server or does the application calculate everything that might have happened in a fast forward when you launch it?
2. Let's say you are currently playing in the browser and you completed a mission and get a coin reward or something. Is this data-update instantly written to a database or is it somehow stored in some kind of session tracker (cookies?) and stored on the server once you leave the application?

If it is written to the server instantly how is this done without a page refresh? I mean if there is some kind of client/server communication there must be a page refresh right?

If the data is send to the server once you leave the application, how to handle a case where the user simply kills the browser process by simply closing it? Can this scenario be catched by code so the data can still be written?

I read about several options to use JavaScript for database communication but I guess this is not an option, security, right? Wikipedia says that this kind of games do rely on server-side code but how exactly is this accomplished?

In case this matters, my approach for a browser game would be a JavaScript application with a minimum of client/server communication.

Answer 1

You can store the players progress either on the server or on the client.

When you are developing a single-player game where cheaters are only destroying their own game experience and not that of other players, storing the whole gamestate in JavaScript localstorage is a perfectly valid approach. Anything you store in localstorage is stored by the web browser, which means the application can retrieve it without having to contact the server at all. Caveats are that you can not share the game progress between browsers that way and that the game state is on the users machine, so they can hack it when they want to.

On a multiplayer game you likely want to store the users game state on the server to prevent the player from tampering with it. The communication between browser and client can be implemented by having the client call a webservice with XmlHttpRequest or by using web sockets. Nether technique requires a page refresh. When the user kills the browser window, you can not make sure that you get any further updates from it, so you should send state changes to the server as soon as possible.

Regarding storing the game states in a server-sided database: Usually you have the web browser communicate with a server-sided application and that server-sided application communicate with the backend database. Letting the users web browser access the database directly is dangerous because most database systems do not have permission handling systems which are flexible enough to prevent users from tampering with data they are not supposed to tamper with. The technology options for implementing such a server-sided application are manifold: Node.js, PHP, ASP, JSP, Ruby on Rails... just to name a few of the many options.

Answer 2

Your actions result in information being sent to their servers. This data is persisted on their servers in a database (probably).