![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
Difference between revision 6 and current revision
No diff available.JS ES6 is currently popular. Typescript is growing.
React is currently popular, and Redux.
Mocha and Jasmine are popular testing frameworks.
SASS/SCSS are popular CSS overlays.
Webpack and Gulp are popular build tools.
As far as cross-platform mobile frameworks, things are unclear. Contenders include Cordova, PhoneGap?, React Native. See http://stateofjs.com/2016/mobile/
as of 2016: everything below is very out of date
---
see also [notes-computer-programming-webDevelopmentFramework]
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).
random notes:
" That being said, what have I learned about how to organize a Flask application to comfortably grow?
Firstly, fbone and flask-bones are great first approximations. If you're struggling to figure out how to structure your flask application have a look at those and consider using either one as a template that you can evolve to your needs. Also, I have to mention cookiecutter as a tool for templating the structure of python applications in general. In terms of the web application itself you might also consider using Flask-Classy to build out your views.
Beyond that I hestitate to dictate anything else.
...
Think about deployment. How is it getting to the server? egg, wheel, rpm? Will there be continuous integration? Are you using salt or puppet? How you deploy your application will determine what kind of structure you need and what kind of supporting utilites you may or may not have to write. Think about app initialization. Where is the entry point? How are components initialized and shared? If my user module needs a database connection how do I ensure that it always gets an initialized database connection? Do I use singletons? lazy loading? dependency injection? It depends, and you should always be willing to revisit this decision. Also think about how you'd do a deploy to a completely uninitailized environment. How do you initialize the database(s)? Is the app configured by environment variables or cfg files? How are those being shared and deployed? Think about resource lifetimes. Make sure you understand how your database connections and other resources should be managed within a Flask application. Typically you should initialize a resource when a request comes in and tear it down before the response goes out. SQLAlchemy explicitly covers integration with web frameworks in its documentation. ... testing...Organize your tests along the same lines as your modules ... logging...initialize a logger at the top of each .py file ... build your application so that arbitrary third-party dependencies (databases, web frameworks, etc.) could be swapped out with minimal impact. ... " -- https://etscrivner.github.io/posts/2014/10/building-large-flask-apps-in-the-real-world/
mwhite 19 hours ago
You could try using Flask-Restless with Backbone-Relational and then integrate with something like React using something like https://github.com/magalhas/backbone-react-component
https://flask-restless.readthedocs.org/en/stable/
http://backbonerelational.org/
reply
itajaja 18 hours ago
Shamelss plug: We are using flask-resty [1] for our microservices and it's awesome. it uses sqlalchemy and marshmallow and the resulting code is very terse and declarative.
[1] https://github.com/4Catalyzer/flask-resty
reply
jperras 19 hours ago
Typically, one uses an application server container such as uWSGI for a production deployment of a Flask application.
uWSGI allows for brokering requests across multiple application processes and/or threads, and also allows for more interesting and complex scenarios such as zero-downtime deploys, "automatic" scaling of processes/threads based on load characteristics, to name a few.
zenogais 17 hours ago
Original post author here. On the single server level I've mostly used Flask behind uWSGI for load balancing, My experience with this has been overall positive (but uwsgi can be a bit of a pain to script deployments for, maybe it's better now though, not sure).
Then there's the further load balancing you can do behind something like an ELB instance in AWS to control load across multiple servers.
reply
viperscape 19 hours ago
I don't know current status, but in the post you would use gevent or similar to async. Also you would put nginx and likely gunicorn in front of the app.
https://www.digitalocean.com/community/tutorials/how-to-serv...
reply
fuhrysteve 19 hours ago
You typically use something like uwsgi or gunicorn to serve requests, and it's uwsgi & gunicorn that decide how many processes or threads to start. These typically sit behind a load balancer and / or a reverse proxy.
In terms of async Tornado / etc, it serves a different need. Like all wsgi servers, it is best to optimize Flask such that you serve a small number of concurrent requests that are fast to prevent a long queue waiting to serve web requests. With Tornado you have more flexibility in that particular area, but also another layer of complexity. Different tools for different use cases.
reply
akoumjian 15 hours ago
This was a good general list of things to consider for scaling any web applications. What I've noticed though is that all my flask apps, after adding in all of the standard components, eventually converge on a Django-esque setup anyway. So now I just use Django, and if I don't want to use a particular component (ie: orm, templates, whatever) I don't, or I swap it out. On the other hand, if I do want to use those components, they are right there.
reply
derefr 15 hours ago
Do you ever write "apps" that only expose an API, without rendering any HTML? I find Flask (or Ruby's Sinatra) to be ideal for that case.
Given hexagonal architecture (i.e. your model + business rules existing as a "service component" library project, that your webapp consumes as a dependency), if all you need is to expose that service with an API, Flask and/or Sinatra lets you do so with nothing more than a flat file of 3–6-line controller stanzas. It's really quite lovely; gets to the core of what it means for something to be a "microservice."
reply
akoumjian 14 hours ago
I suppose if you already have an existing service component that encapsulates authentication, authorization, business logic, notifications, and all that other jazz, then use flask is an excellent way to wrap that to produce an http api.
reply
TLDR:
Bottle and Flask are great for finding your feet in web development without being forced to learn too many concepts all at the same time.
Django or Pyramid or something full featured for web application development
Falcon for REST API development
If you are willing to take on the cognitive load of going straight to your destination, I would recommend beginners start with Django or Pyramid or Falcon. If (and this is entirely reasonable) you need to get going in Python web development without being overwhelmed by the concepts, go to Bottle or Flask but move on as soon as you can.
If you love Flask and have the skills and competence to craft your own architecture and carefully selected from a menu of addons that suit you and know how to whittle out unneeded functionality, then Flask is the right choice for you.
reply
matthewowen 19 hours ago
If your plan is to use Flask and use all the various add-ons to get Django-like levels of functionality out of the box, I think that's a mistake.
I worked on a pretty big Flask codebase (certainly bigger than the one mentioned in the article, though obviously it depends on how you define it, how you structure your codebase, etc). We didn't really use much in terms of third party add-ons, but we did fork and add various useful features, conveniences, etc. I don't personally think the lack of (eg) sessions is very painful, because it's trivial to implement, and there's something to be said for having a code path that you understand. Yes, we spent some time building some pretty generic stuff... but it was a tiny fraction of overall development time, and we gained wins from the fact that we understood our codebase very well thanks to it.
Definitely a balance to be struck, but I really appreciate that the surface area of Flask is small enough that provided you accept the basic conceptual model (request per thread, entry point is a function, etc), you have a lot of freedom to do what you will, and there's very little bias in the system pulling you away from that. Whereas if you don't want to do something the Django way... well, there's some cost to that choice, usually.
reply
wowzer 20 hours ago
This is the first I've heard of Falcon. Have you used it for a "real" project? It'd be interesting to know the tradeoffs when considering it against something like Django Rest Framework. Looking at the benchmark figures on the Falcon site, it's sad that Python 3 underperforms Python 2. I wish Python 3 had the slightest performance win, it'd be an easier sell. Hate to shift the topic to Python 2/3 talks, but I've wanted to switch for a while now, and it's still not the simplest sell.
reply
andrewstuart 20 hours ago
Yes I have used Falcon extensively and I like it alot.
Lies, damn lies and benchmarks - I'm not saying the benchmarks are made up but you know - the benchmark thing.
Falcon for REST API development. Django/Pyramid for full featured web application development.
And regarding speed, well how does its Python 3 performance compare to the Python 2 performance of other Python web servers? And any does speed matter that much? In many cases "fast enough is good enough" and the bottle necks are more likely to be other parts of your system and if speed matter that much then you should be horizontally scaling.
And if I may raise the ugly topic - who cares about Python 2 under any circumstances? For me - and I know many people do not think this way - Python 2 is dead so who gives a rats arse anything about it. Python 3 is the future and I'm not looking back for any gripes or grumbles about it.
Don't get me wrong, I think ruby-rails-slow is a bad thing, but Falcon fast should be good enough.
And if speed really matters to you then you shouldn't be using Python for web application development.
reply
aidos 20 hours ago
I looked into Falcon a while back - looked interesting but it wasn't immediately obvious what I would get over Flask (if nothing else, there's a tonne of Flask docs out there these days).
In all my research over the years Pyramid is the framework that looks the most interesting. The docs are amazing (I more or less read them cover to cover, even though I haven't tried the framework) and the whole thing seems very well thought out.
I'd love any insights from people who have worked with it.
reply
goo 19 hours ago
I've worked on one project with Pyramid extensively, and I've been relatively pleased. It gives you a lot of flexibility, which can be good and bad. There is useful code that helps you unit test your app, and it is not a particularly opinionated framework. That being said, the number of options that pyramids allows can be a little overwhelming -- it gets a grade 'C-" when held up to the zen of python's line: "There should be one-- and preferably only one --obvious way to do it." When held up to "Although practicality beats purity.", as well as most of the rest of the pythonic ideals, Pyramids gets a solid A.
Personally, I'm excited to explore flask more, since it seems to put the ball entirely in your court. I like the concept behind flask a lot -- for some projects I'm willing to sacrifice additional framework features in exchange for a more careful understanding of everything I am adding to my app.
reply
mmerickel 19 hours ago
Yeah I mean it's hard to digest comments like "it's not a particularly opinionated framework" against things like "put the ball entirely in your court". They seem to be saying the same thing except you have a different perception of each when you say it.
The problem as I see it is that Pyramid has a lot of extra interfaces and support for things in the core by default (and some concepts that are completely missing from most frameworks like context). So much is there that it's easy to lose sight of how little is actually required. Fundamentally you can write Pyramid apps in 10 lines of code exactly as you would with Flask but that's less interesting for bigger apps and so the docs focus on all the extra features.
I mean if you take the example at the top of http://docs.pylonsproject.org/projects/pyramid/en/latest/ and add in the pyramid_jinja2 library via config.include('pyramid_jinja2') then you basically have views and jinja2 rendering fully baked.
As in the previous example if you get right down to it Pyramid doesn't even have a templating engine! Flask comes with jinja2 built-in! So scaling DOWN to APIs where this is not necessary is an interesting thing..
reply
goo 18 hours ago
It's a matter of conceptual load, not about the actual capabilities. By "putting the ball in your court" I mean to say that flask adds an insignificant amount of conceptual load, and the overall difficulty to read and understand your app will be based on what you decide to add beyond flask.
By saying "it's not a particularly opinionated framework", I mean to say that it allows you to add, easily, whatever you want to it. However, there is a fair amount of conceptual load in doing so. The difference between a flask app and a pyramid app with pyramid jinja2 built in is that one of them takes about 20 seconds to understand.
Don't get me wrong -- I think pyramid is fantastic. But it it is disingenuous to suggest that there are not differences in complexity between the two frameworks.
reply
mayhew 16 hours ago
You could always just use Werkzeug directly if you're just building an API.
reply
mmerickel 14 hours ago
"just building an API" does not mean you need something more lightweight. It means you have different requirements from a standard full stack web application. You are not dealing with cookies, forms or template rendering but you are still dealing with lots of other problems including authentication, authorization, headers, etc. Pyramid is the ONLY framework I've ever seen that comes with builtin support for dispatching to a view function based on more than just a request method (GET vs POST). In Pyramid GET vs POST is equivalent to any other request property including accept headers, cookies, query strings, etc. Any of these can dictate a different callable. See http://blog.delaguardia.com.mx/pyramid-view-configuration-le... for some examples.
reply
---
pyre 14 hours ago
> `import logging ; logging.info("hello world")`
I don't think that this is doing what you think it is doing (assuming that 'import logging' is importing the Python logging package, and not relying on broken Python 2 package name resolution quirks to import a local module).
The `logging.{LEVEL}` functions always log in the root logger. The loggers that you initialize have a tree structure. There is a nice package for inspecting that here:
https://pypi.python.org/pypi/logging_tree
Several different 3rd party libraries that you might be using will all have their own loggers that are initialized at their level. By separating things out like this, you can set different log levels for different loggers. For example, you might not want Component A logging at DEBUG level, while you want Component B logging at DEBUG level. This is why one would initialize things per package like this:
import logging logger = logging.getLogger(__name__)
That logger's log level inherits from it's parent, and the structure mirrors the structure of your package/module hierarchy, so you can set the log level for an entire package, or just an individual module. Granted, you may not require such granularity, but doing this as a standard practice does give you the flexibility.
reply
---
http://awesome-python.com/#web-frameworks
http://awesome-python.com/#restful-api
http://awesome-python.com/#authentication
---
"the usual Django, Flask, Pyramid and Bottle suspects."
https://www.airpair.com/python/posts/django-flask-pyramid
http://www.fullstackpython.com/other-web-frameworks.html
---
"I was very in favor of tastypie until i tried django-rest-framework." -- https://www.quora.com/What-is-a-good-Python-framework-for-building-a-RESTful-API
"DRF has displaced TastyPie? as the go-to framework for creating REST APIs" -- https://www.reddit.com/r/Python/comments/38osar/flask_or_django_for_restful_api/crwm03w
"If you do go with Django, I'd recommend DRF (Django REST framework) for building your APIs, its docs are very well explained and DRF itself is highly configurable." -- https://www.reddit.com/r/Python/comments/38osar/flask_or_django_for_restful_api/crxfdpx
---
"In PayPlug? Labs we use Flask and Bootle for our REST-API projets....I don't already try falcon in production environment because it was so young when I choise framework for our API but now if you need to chose a good API framework I advise you to make 2 POCs : one with Bootle and one with Falcon." -- https://www.quora.com/What-is-a-good-Python-framework-for-building-a-RESTful-API
"But if you need to manage lot of asset (javascript, css files, ...) you need too asset manager tools. In this case you can use Flask who have good implementation of webasset or you can implemente directly webasset in your application" -- https://www.quora.com/What-is-a-good-Python-framework-for-building-a-RESTful-API
---
frameworks for fast pages:
links:
---
"Most web frameworks are garbage when it comes to performance. If your framework isn't in the top half of the Techempower benchmarks, (or higher for performance-critical applications) it's probably going to be better for performance to write your own code if you understand what you're doing" [1]
my note: if using the 'composite score' on techempower 'round 20', this would pretty much rule out all of the frameworks i would consider (eg. django, rails, laravel, phoenix, express), except for gin and spring and asp.net core. Note: some of the items there have a little T in a diamond next to them, the page explains "Frameworks flagged with a T icon are part of the TechEmpower? Performance Rating (TPR) measurement for hardware environments. The TPR rating for a hardware environment is visible on the Composite scores tab, if available. ". These include most of the well-known frameworks, and all of the ones i listed in the first sentence of this paragraph. Note: actix (Rust) does well.
---
a friend tells me that actually most ppl using ASP.NET (which is pronounced Ay Ess Pee dot net, not Asp, btw) are probably doing so as ASP.NET Core, on Docker on Linux servers. So i don't have to be afraid of that. So i guess i could use that.
So that might be the best choice for me.
however Heroku doesn't support it! what the heroku equiv for asp.net core?
---
---
