Flask! It's Pythonic and good. Once you've done a couple of Flask projects, you can spin up a new microservice in a couple of hours. It's much lighter weight than Django, so it forces you to keep fewer moving parts in your head while hacking.
It's more lightweight than Django until you add packages for all of the components you need to build a production-grade app. To get what Django has out of the box requires a half-dozen packages, and even with that Flask-Admin is super primitive compared to what Django Admin provides. I try to like Flask, and I currently run my small personal site in it, but almost every project I start in Flask, I end up rewriting in Django.
As far as building APIs goes, Django Rest Framework provides so much. I find myself reinventing a lot when I use Flask vs Django + DRF. Just my 2¢.
I keep thinking I'll learn Django, but I hate Django, why would I want to build a skill that I'm then forced to use, as well as proliferating the market for Django products?
I work on Flask stuff on purpose, because it means in the future I'll have more Flask work...
Flask is much more pythonic than django.
In fact, go look at Django's website/documentation, they don't have a hello world or a quickstart, they have like a 10-page tutorial to build some frankenstein nonsense, Flask's homepage has a 5 line application! That's how Python is supposed to be.
The more flask in the world, the better.
edit: now I've read some other people here saying Django gets easier after you use it, or it's gotten simpler... Flask is easy the first time you use it, and it's always been simple. Pythonic. End rant.
You could write Hello World the same way in Django with nothing more than one route and one view. However, the Django tutorial is longer, I think 6 pages, because it provides so much more out of the box. The Flask tutorial would be the same length if it covered topics like a variety of views, templates, serialization, SQLAlchemy, migrations, model design, etc.
Flask actually has a tutorial just like this in the docs [1].
I think you should give Django a chance to be able to compare the two frameworks in these kinds of aspects.
I love Flask. I'm not a professional but for hobby projects I find it very easy to use. I have a template now and I can get a basic backend going in 30 mins.
For more serious projects, we use Flask for big commercial products and work and it's very good. Unlike some other tools, what I like about it is that it's very easy to look at the code in a Flask project and immediately understand what is going on.
I also use and love Flask for exactly these reasons. Additionally I've been playing around with Flask_Restful and have been very pleased with the results.
Hi Everyone. I'm actually working on a "starter" project that only focuses on the backend. It uses Flask and PostgresQL and includes fabric deployment scripts to get the app running on Debian. Please check it out and let me know what you think
When i have a new idea it takes me at max a hour to have to complete framework up and standing (Bootstrap/UI, User management, Databases, Deployment, ...) and i can start working on business logic.
I second Rails. Besides that it provides lot's of out of the box features, there are tons of useful gems. There is also really interesting new API-only mode.
Good solid base for quickly developing something quickly.
Iterating on a database schema has never been easier
since 1.7 the migration tools are built in and the ecosystem of plugins has lots of tools that make development of a prototype extremely easy. It just keeps on getting better, just the other day I found an plugin to automatically generate knockout.js powered AJAX forms without me having to write any of the JavaScript.
I guess I'm old school. For simple projects I still use Perl with CGI.pm and a flat file database that stores data in CGI.pm's "name=value" format in a text file.
If I need templates I'll add "HTML:Template", for email I'll add "Mail::Sendmail", et cetera, to my perl cgi script.
I too use Perl for most applications. These days I mostly use CGI::Application, which is great, although I've started to experiment with using Dancer (which is kinda like Ruby's sinatra framework) with success.
I'm old school as well, last time I had a "simple" project that didn't allow setting up a SQL RDMS I used flat files, and for system administration by users their presence in various directories and Windows' file manager back when it was simple, fast and good.
Normally, though, I like independent enforcement of data integrity, and PostgreSQL is free, easy to set up and maintain.
As a front-end developer I just can't warrant the time setting up a backend, setting up a database, defining routes, handling authentication and the other nonsense that seemingly takes a solid day to get working.
Firebase to me is the best choice for simple projects, I don't use anything else anymore.
As a mostly back-end developer, I'm still a fan of Firebase as well for the right projects. I haven't used it since they were acquired but the free tier still looks pretty generous.
The only downside I really see is once you leave the free tier you're at $25 / month minimum whereas I can run a small backend (or multiple small backends) on a $5 / month box. The difference really adds up if we're talking multiple small projects for multiple years.
Pyramid and Postgres on the backend, Mako templates w/bootstrap on the front.
When I'm prototyping, my data model is stored procs that return json structures to the templates. I use SQLAlchemy core to connect to the db and execute the procs.
A prototype like this is super fast to get running, it gives you a really clean app structure that you can hand off to pretty much anyone and have them work on features, if you're lucky enough to have a team. If not, it's pretty easy to keep it all in your head at once.
As things grow, you can replace components as you need to.
You start off rendering JSON anyway, so if you need a more advanced interface up front, you can use React or Angular or Ember to hook into the data model. Whatever you want, really.
If things get more complex on the backend first and you need more structure there, you can refactor the SQL (because it was probably really gross the first time you wrote those "dump everything" procs). If you end up with a really complicated data model, you may have to eat the performance hit and switch to Alchemy proper for maintainability. Either way, the choice is yours.
Sometimes the simple app is the one you need, and the biggest challenge is scaling quickly. That's easy too because the database handles transactions inside the procs. Run one instance of the app per core on your server and put them all behind nginx and repeat on as many machines as you need to cover your traffic needs behind HAProxy. Now you're maximizing multi-core performance per machine without having to write async/await code.
It's probably not for everyone, but I find it gives me an enormous amount of flexibility, scales well in every sense of the word, allows the app to develop organically, and has very few drawbacks.
You take an arbitrary Ring-compatbile HTTP server, write a handler, and glue together whatever you need to.
And you most likely don't need a routing library, you can just use an array-map for that. When it is time to deploy, you create a jar that contains your whole project and upload it to AWS.
Rollback is easy, too, as you don't overwrite your previous version. Funny enough, it means you can treat versions as immutable values of your application over time. I use yyyymmdd for versioning in most projects, that works great with this approach.
There are many discussions on virtues of Clojure's dynamic development environment, so I'll skip that.
The language you know the most would be best fit. Maybe Python/Rails/Go could be most optimal fit, if you know very good Java or PHP and don't want to waste time on learning something new - stay with that.
I'm familiar with Java Servlets and Express for the middle-layer. I've yet to set up a database from scratch, but I've worked with MySQL and Oracle SQL databases before. It'd be cool to learn more about setting up and scaling a database (though I doubt I'd need much scaling for my side-project for awhile).
Just PHP and MySQL.
I coded a simple back end for a web app 10 years ago with very simple templates. Runs fast as hell and I don't need any API documentation or dependencencies or whatever.
One practical reason is that I suspect most C developers aren't interested in building web applications. And most web application developers don't know C.
I think that's a terrible thing. I've been a web app developer for most of my career and I'm not super fluent in c anymore. But c is one of those foundational things every developer should know.
With GCC's ability to deploy to just about every architecture, most heavy-handed libraries using C themselves (hence a C FFI in higher languages), and access to the biggest and best GUI libs.
Usually when i write something i want people to use it. And i am far to lazy to bother with Windows or Mac specific code. Thats why it is web for me :)
Same here. Easy to setup projects. Quick to deploy. Focus on the app instead of administration. Go+AppEngine has a lot of my projects - no cost, no maintenance. Of course, if by any chance those projects grow, I'm still likely to run it there.
Small hope/suggestion: I wish there was a free tier on Cloud SQL.
ASP.NET deploying to Azure, if you're into the ecosystem it can't get much simpler than that (a web page up an running in minutes).
It's now cross-platform and there's an Azure free tier.
Of course, other people can get similar productivity within their own most familiar stacks :) (someone mentioned an hour for a similar setup with Rails)
AWS Lambda functions and some kind of database. Lately that has been graphene. AWS SWF, SQS, SNS added in the mix allow me to POC distributed apps quickly. Finally, I've worked with API Gateway recently when needing to support mobile devices.
As the framework, it's CodeIgniter or for ultra-simple projects Slim, templating engine is Mustache, and hosting platform is nginx reverse proxy + virutal machines with NAT on a dedicated box at OVH.
http://flask.pocoo.org/
Lately, I've been using Flask on the back-end, and React on the front-end.