Hacker News new | past | comments | ask | show | jobs | submit login

Don't be fooled by the "micro-framework" line. My experience of building SaaS on top of Flask is that you are going to have to reinvent the wheels for a lot of things.

Flask is plagued with abandoned plugins from a cesspool of weekend contributors which you rely on for basic things such as authentication and ORM. Tough enough as it is with all the outdated documentation for each of the plugins you need.

So my recommendation based on 2 years of working with Flask is don't fucking do it, unless your product doesn't extend beyond couple of HTTP endpoints served over uwsgi + nginx for your internal applications.

I really wish I'd spent all that time I spent on Flask on Node.js, python was the wrong medium to distance myself from PHP frameworks.

All in all, 4 years have passed since my search of alternatives to LAMP. And finally, it wasn't some open source framework or asynchronous javascript to save the day, it was Amazon Lambda + API Gateway.

Gone are the need to spin up Vagrant, docker, mysql/postgresql. I just upload the specific script I want and bam. Npm modules and pip modules too.

I've in the process of migrating to AWS and leaving Flask. Great initiative, ruined by abandonware plugins and modules, certainly not attractive to entice developers to build their own wheels.

The biggest mistake you could do is basing speed and agility as basis for going with Flask. It is the complete opposite. I think using Laravel or even CodeIgniter will significantly cut development time.

Regardless, I'm done with the whole server/client frameworks and have migrated to AWS without any servers to maintain or setup. There's even frameworks for "Serverless" architecture now which makes me shake my head.




Why not try Django? It's documentation is top notch, plenty of maintained plugins for everything you could need.

Jumping on the lambda bandwagon seems pretty risky, and in any case how does it protect you against abandonware? To me it's a bit like saying "I don't like outdated python packages, so I'll switch to nginx instead of Apache!".


> Why not try Django?

They blame Python for issues they perceived with Flask, I doubt they're going to be too open to Django.


that wasn't what I meant, I meant specifically the microframework nature of Flask means you have to fill in a lot of what other framework gives you fro free.

I really did wish I was using django and it's a great framework, however, I would still choose a php based framework over django, my whole point of using Flask was buying into the "microframework" experience, it hasn't been stellar nor worth the extra effort.

I do have to say that I rather liked doing things in Flask until it came time to do the less fun plumbing code that Flask conveniently leaves out for you to implement and rely on other Flask plugin contributors....it's literally npm world but far far fewer in volume....I really did not expect using Flask would become a minefield

About Lambda, yes there is a platform risk, but I don't think it's a huge one because the code you write on Lambda are largely self sufficient on their own. At most if AWS Lambda shut down, you'd moving them to a queue based architecture with EC2 workers chewing away at the queue.

All in all I don't think AWS Lambda is a hugely different than any other webhosting...I'm more worried that digitalocean is going to sell out and I'm stuck with dozen of snapshot images that won't work anywhere else.


With Typescript, node is a decent choice as long as you aren't doing anything fancy on the server. I do a lot of data science stuff and I would literally rather bang my head against a wall violently than use javascript for that.


If thats pretty much all your server does then you can use whatever you like - most of the time I'd want the "hard crunching" stuff tucked away way in another service to call.


Unless your hard crunching needs to be distributed to complete in a timely manner, it is much easier to scale up by having a load balancer distribute users across multiple instances of an app.


I feel like Flask can be ok if your application is simple enough that you can process each request independent of all other requests.

If your requirements are more involved than that, Flask is an obstacle. The way it gives each request its own context makes it hard to have any kind of communication between them, without some kind of "spawn a gevent to wait for a signal" hackery.

Also, Flask comes with Jinja but they should totally be separate. Why should a network protocol layer come with a frontend templating system?


They are separate, Jinja is just a dep of Flask.


The official Flask tutorial includes Jinja2 as an integral part of flask and assumes the user will be using it for all their templating needs.

http://flask.pocoo.org/docs/0.10/tutorial/templates/


> I really wish I'd spent all that time I spent on Flask on Node.js, python was the wrong medium to distance myself from PHP frameworks.

What Node frameworks are you using?


Express makes Flask look like a heavyweight framework in comparison, and that's by far the most common 0_0




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: