notes-computer-webDevelopmentFramework

see also [notes-computer-programming-webDevelopmentFramework]

The typology of web frameworks:

• "convention over configuration" vs "no magic": does the web framework try to provide reasonable defaults to make your life easier, or does it try to have a clean, understandable implementation so that if you need to do something unusual it doesn't take too long for you to figure out how to do it
• big vs small: does the web framework try to provide a lot of functionality, or only the basics?
• integrated database vs not: does the web framework provide functionality that integrates with the backing database, or does it free you to choose whatever database you want even a simple key-value store?
• focus is on server-side vs on client-side: does the web framework focus on doing things on the server or on the client?

examples:

• Rails: convention over configuration, big, integrated db, server-side
• Sinatra: ?, small, ?, server-side
• Django: no magic, big, integrated db, server-side
• Flask: no magic, small, no integrated db, server-side
• angular: ?, big, no integrated db, client-side

(the ?s tend to mean that i don't know enough about something, not that there is no answer)

woah this is really out of date! todo

A web development framework is a tool for programming dynamic websites. This page collects some of my thoughts on some existing web development frameworks. I've never operated a high-traffic website so the following may be all wrong.

summary

My first choice for a new project would be to use Ruby on Rails on Amazon with Elastic Beanstalk. The database would be either Amazon DynamoDB? or Amazon RDS. DynamoDB? isn't described below but it's like Cassandra without secondary indices. I'd choose DynamoDB? if transactions and indices were unneeded and if huge write throughput may potentially be needed later, and I'd choose RDS otherwise.

If DynamoDB? was chosen and if the project turned into a big successful company later on, then i'd switch to Cassandra (DynamoDB? and Cassandra are not API-compatible but their architecture is so similar that it seems that it would be easy to port from DynamoDB? to Cassandra, unless you were using DynamoDB?'s conditional write functionality).

AWS (Amazon Web Services)

Today this is the standard for IaaS? (infrastructure-as-a-service) cloud services that need to scale horizontally (for example, to provide high availability). 'IaaS?' means that AWS gives you (virtual) servers and you can install whatever you want on them and administer them yourself (as opposed to PaaS? offerings like Google App Engine (see below), where you only program a module that is called by Google's framework); 'scale horizontally' means that you can increase capacity by renting more servers, instead of by renting bigger servers; 'high availability' means that you have automated redundancy so that when one of your servers fails for whatever reason, another one quickly takes its place.

Here's a great (very) introductory guide to AWS: https://www.airpair.com/aws/posts/building-a-scalable-web-app-on-amazon-web-services-p1?wed

Some further notes:

• "You can have a $ limit. Use a CloudWatch? alarm that shuts down your instances if the billing metric exceeds the growth rate you specify for the period you specify." -- https://news.ycombinator.com/item?id=8927711
• Create a Billing Alarm to Notify You If Your Usage Exceeds the Free Tier
• "I might suggest a emphasising a few things such as not having keys on login accounts(they negate multi-factor auth if leaked), and to ALWAYS pick or create a new IAM role if you aren't sure an existing one fits for the EC2 instances." -- https://news.ycombinator.com/item?id=8927805

(Python or Java) Google App Engine

Google App Engine (or Appengine, or GAE) 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:

• due to the latency and expense, it isn't practical to run jobs over a large fraction of the database, especially not if you want to extract all data from the database and run the job elsewhere. https://groups.google.com/forum/?fromgroups=#!topic/google-appengine/-FqljlTruK4 http://www.moneytoolkit.com/2012/08/the-problem-with-google-app-engine/ . It would be nice if there were a cheap way to mutate a large proportion of the entire dataset as a batch job.
• it's a little slow, unreliable, and expensive (see http://www-cs-students.stanford.edu/~silver/gae.html . My guess is that the slowness is a consequence of the usage of the 'Megastore' database, which is a No-SQL style database whose defining feature is a limited form of transaction -- the possibility of doing transactions may come with a substantial speed hit. I wish they would get the latency down and the uptime up. I haven't looked at it for awhile, so perhaps they have.
• not total control -- you're stuck in their environment, and if you need to do something weird they didn't think of (for us, it was allow us to support a simple custom protocol for large XML file uploads from a client) then you're out of luck. If you need a non-pure-python library that they haven't ported to their platform, you're out of luck. As time marches on the list of things they haven't thought of is growing smaller, however.
• Google has a nasty habit of unpredictably abandoning products, and unpredictably raising prices on products. In the csae of Appengine, at least they promise to give you 3 years of warning before killing it. It's clear that Amazon's AWS is a huge success and won't be killed for longer than 3 years -- that's not clear with GAE. I wish they would promise to keep it around for a decade, or six years at the very least.
• you're stuck in their environment -- if you need to get a bunch of data out for analysis or to migrate, it can be painful (see http://www-cs-students.stanford.edu/~silver/gae.html ). Hopefully they've addressed that since then but i dont know how to be sure (actually, apparently they have, unofficially: http://gbayer.com/big-data/app-engine-datastore-how-to-efficiently-export-your-data/ ).
• you can't trust their self-reported uptime measures (see http://www-cs-students.stanford.edu/~silver/gae.html ), because sometimes various services go down without the whole thing going down, and they don't always report that. I wish they were better about reporting these, hopefully they have gotten better since i last looked.
• you'll be pretty tightly wedded to them, requiring a significant rewrite to migrate off later if you want to do that. I wish AppScale?