![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
i've never operated a high-traffic website so the following may be all wrong.
Google App Engine is awesome -- they'll supposedly take care of all the ops headaches if you scale, and they have an integrated deployment environment with logging, deployment, database connectivity, and an admin/debug console all set up for you. They also force you/teach you to code your database accesses in a scalable style. The downsides are:
If you can stand these caveats, then choose Google App Engine. Unless you are already experienced at this sort of thing, you may save a bunch of time not figuring how to set stuff up, and not worrying about keeping it up under load.
If you can't, then read on. My guess is that no business will want to host a primary product on Google App Engine for these reasons (again, see http://www-cs-students.stanford.edu/~silver/gae.html for more), unless the latency, uptime, and cost have improved since i last checked. However, for personal projects that you want to be slightly scalable just in case, for prototype products that you want to put up publically but that you're not sure that you want to actively improve unless they catch on, for internal sites, or for less important applications that you wouldn't spend time optimizing anyways, Google App Engine seems like an ideal choice. I'm not sure, but i don't think Google itself uses Google App Engine for any of its core product offerings, but i think it uses it for some internal sites and some low priority offerings (such as http://www.google.com/moderator/ ).
The only API-centric framework i found. i like it.
Minimalist Python framework. I like it.
Minimalist Ruby framework. I like it.
The most popular kitchen-sink framework (popular not in terms of numbers, that would be some PHP thing, but in terms of some sort of subjective 'mindshare').
Ember and Angular seem to be the popular ones right now. Also note Node.js for the server-side. Not sure which is best. Never used any of them.
Kitchen sink Python framework. I've never used it so i don't know whether to recommend it. My inclination is to say that if you want a kitchen-sink framework (and i think you do if you want a traditional, server-generated, dynamic website that spans many webpages), you should use Ruby on Rails instead.
I don't have enough experience to say when javascript.
I'd say if you are making a traditional, server-generated, dynamic website that spans many webpages, use Ruby and Ruby on Rails. If you are making an API, either one is good (Ruby's Grape is particularly nice). If you are making a small 'app', either Flask or Sinatra is good.
More programmers know Python than Ruby but more junior web developers seem to know Ruby. However Python is being taught in a bunch of schools and grad students use it, so that may change. Python is an easier language to learn or to read if you don't know it.
So i guess my advice regarding which language is a little conflicting. Sorry, i can't make up my mind.
If you chose Google App Engine, you use their database. That's the whole point, because the database stuff is (so i'm told) what is hardest to scale.
If you aren't too worried about scaling to high numbers of simultaneous writes, and you just want to use the standard thing, use Postgresql. The big caveat with SQL is that it's hard (but not impossible if you have a lot of money) to horizontally scale to very high numbers of simultaneous writes without sharding.
If you aren't too worried about scaling to high numbers of simultaneous writes, and you need transactions, use Postgresql.
If you aren't too worried about scaling to high numbers of simultaneous writes, and you want the database to enforce schema-based consistency conditions on data in the database, use Postgresql.
If you aren't too worried about scaling to high numbers of simultaneous writes, and you don't need transactions, and you want to use document-oriented database queries (see http://docs.mongodb.org/manual/applications/read/#find ) to make it easy to agilely change the schema as you develop, or because you want to use a lightweight implementation of map/reduce ( http://docs.mongodb.org/manual/applications/map-reduce/ ), use Mongo. Two caveats with Mongo are (a) no joins, (b) no transactions. There's probably others, i don't know much about it. Apparently there are some operational issues: https://www.google.com/search?client=ubuntu&channel=fs&q=mongodb++caveat
If you aren't too worried about scaling to a huge database, or you can shard, and you could use the useful and interesting operations that it provides (but only within each shard), use Redis. The big caveats with Redis are (a) the keys for your data set must fit into your server memory, (b) no joins.
If you are worried about scaling to a high number of simultaneous writes, and you don't need transactions, and you're willing to spend more time developing because you will be using a simple key/value store, use Cassandra. The main caveats are that (a) no joins, (b) no transactions and (c) less popular (so less libraries, and less tested) than the others listed here. In theory Cassandra could even be a little easier to handle operationally than SQL because you don't have to deal with setting up masters and slaves and failover, but the potential immaturity of the platform kinda cancels that out -- also you need to make sure that you have enough nodes in your Cassandra ring so that if one goes down during high traffic, you don't experience casscading failure due to the load shifting from the dead node to the other nodes, pushing them over the brink too.
It's said to be hard to switch data models after your application starts scaling. The 'safest' model in terms of horizontal scaling is one without joins (because it's hard to scale joins over multiple shards). If you know you will want to scale in this fashion eventually, you may want to make 'no joins' a rule from the beginning. Using Cassandra, Redis, or Mongo may help you to impose this discipline upon yourself or your team (or Google App Engine, but then that's hard to switch away from in any case).
