What is the simplest back-end setup for a web application?

Question

As a total beginner, I would like to concentrate on polishing the front-end of the web-game I am trying to build. But the game will have about 5000-10000 different pieces of text that I need to match to the player's attributes. I need to somehow emit these snippets in JSON form to the browser. How to keep it short and simple?

FYI, it's a card game, so turn based and read-only. This means very small load on the server. Just the html/js/css and the JSON string a couple of times a minute per player. I considered CouchDB upon hearing that I can use Javascript for its views and such, but before investing any more time into it, I'd like to learn about other options. I'd rather be playing the game already than spend weeks learning back-end programming.

EDIT: The text snippets all have certain requirements. The player's data is kept in the session data. If the player is weak or axeless, there can be no smashing.

{ 'action':'You smash you opponents head!',
  'player1': {
      'equipment': 'axe',
      'strength': 3
}

So, in addition to storing, I then need to also sieve out all the actions that fit the requirements and then choose one at random that will be sent to the client.

Answer 1

I'd go for ASP.Net - I'm not sure whether it should be considered "the simplest", but it seems like a sensible recommendation:

• Its at least as good as any other back end
• There are plenty of tutorials, articles and other help to be found on the web
• There is a free IDE in the form of Visual Studio Express that eliminates the complexity of choosing an IDE.

Also, if you ever do become more involved and interested in "back end" web development ASP.Net is a popular choice and will still serve you well.

Answer 2

Use a freely available and open, widely used scripting language with a simple common syntax. That suggests PHP or ruby, to me.

Answer 3

If your focus is on the front-end and you just need to serve up 1 out of 10000 text snippets, I would not use CouchDB or any involved backend.

Even though my own favorite backend is Ruby on Rails, as a start I would choose PHP and put all your text snippets in a single MySQL table or if they are static, why not in a csv file. Most web frameworks including PHP can make json for you very easy.

Answer 4

We need to know more about your requirments to get a real feel for your needs. That being said, if your backend is really simple, any technology will do. Almost all modern technologies will let you do simple things simply, all will be able to output JSON. So pick the one you are familiar with. Some that come to mind :

• PHP
• Java / JEE
• C# / .Net
• Ruby / RoR
• Python / Django
• Scala / Lift
• Even C / C++ could be a solution (...)

Edit : Given your requirements, the answer above still holds. Any techno will work for you, and for simple requirements all should be relatively easy to use.

Answer 5

Are these pieces of text static? As in does that 5000-10000 cover them all?

In that case why not just serve them all as a single static file. To further minimize server load and speed up the app, set a far future Expires header for it.

Super simple setup, built in caching and compression, no security vulnerabilities, minimized HTTP request overhead.

Answer 6

If you have not developed much, I recommend you PHP and jQuery to handle client side (JavaScript)

I would recommend first taking a small lightning course in how to code in php. After reading this please feel free to experiment and read the documentation for PHP, it's very good!

To save the data I would use MySQL if you want a very cheap solution. But I really recommend using SQL Server 2005 or 2008.

After you have created an SQL data model. Then you can start creating the game, on this page you will find a lot of tips that were examples in the php and for many other languages

Good luck!

Answer 7

I can recommend Python and a Sqlite database, which I use effectively for an SMS application (similar in that I look up and return small amounts of text). The performance is amazing (the DB can be held in memory), and using the Pylons @jsonify decorator makes returning JSON trivial. Django also has simple ways to handle JSON (serialization, simplejson).

Granted, this is probably not the absolute simplest, but you can have it up an running in an hour or two, and all the pieces are there for future features and scale.

Edit: Upon further research, webpy looks like the simplest. You can use Mako templates (or none at all), SQLite and SqlAlchemy for an ORM (or no database at all), and installing is as easy as "pip web.py".

Answer 8

How many of these strings would a player typically need per session? There is a big extra overhead for each request to the server, so if you expect long sessions sending the lot in the first place may be the lightest task.

As for the data, if size is an issue, skip JSON and stack it yourself, in your example you have got more overhead than data. All the keys in your example looks like stuff that can be left out if only you keep your data in the correct order.

Update:
You answer less than a hundred, I think that would be around the limit where both approaches cost around the same. However, sending the lot may provide more fluid gameplay, especially on high-latency connections, though that at the cost of a longer initial loading time.

Fiddling with packing data on the lowest level may in the eyes of most developers be a dead discipline (it's quite saying that I just failed to find a guide to the subject, for posting here), but the fact is, for every byte you can cut from the data of a single string, you can cut 5 to 10 kB from the total collection, and there is a lot of bytes that won't take a lot of work to remove.

In order to cut most of the fat without making the implementation a big job I would recommend something like this:

Put all the data in one array, for every string use two string entries in the array, one for the text string, followed by one for all the metadata encoded as a single string. You may for instance write each requirement as two characters, the first signifying the type of requirement, the second it's value, so if you limit yourself to use only numbers and letters you can have up to 62 types of requirements, each with one of 62 possible values, and they will only cost 2 bytes a piece.