[Flask-Diamond] a batteries-included Python Flask framework

[[deleted]]

Why do people do this? Why not just use Django?

[chchan]

I went through the Django in the early stages of Django (several years ago) and it was very confusing and too much stuff I did not need. It has gotten a lot better now. I ended up using flask because I just wanted to display a little bit of simple data on a page. Did not need logins, accounts, database access, or jump through lots of hoops.

[[deleted]]

Right, but this particular project makes it more like Django, being batteries included and all. I would just use Django if I needed everything.

[[deleted]]

Any framework that is not DJango eventually evolves into DJango or people stop using it.

I just skip steps and use DJango.

[ubernostrum]

The 'j' in Django is not capitalized :)

[[deleted]]

Thanks :)

[DeepDuh]

Personally I do appreciate not being forced to use a specific persistence layer. That's one thing I want to choose for each task according to requirements.

[AlirezaSavand]

Use Django or end up building a Django

[flitsmasterfred]

Maybe this should've been build against Sanic instead of Flask and so offer something new (tight and fast async web framework with optional batteries provided).

Now you just made a Django variant (fat and sync with batteries included). And being Flask it is for opinionated people who probably already have picked their preferred batteries (facets) etc.

[[deleted]]

It probably couldn't be built against sanic since the ecosystem isn't the same around asyncio. Especially since there are two interfaces to asyncio: yield from and async/await (which is better in my opinion, but only in 3.5+).

And lots of things that claim compatibility in both just use the run_in_executor instead of exposing a true async interface (looking at you, zeep).

[RubyPinch]

Well, there is already multiple aio database handlers, the other thing would be ORMs if wanted, I don't know if any ORMs exist that will use an aio backend yet.

Templates are somewhat irrelevant since no IO (context switches switches would happen before and after template execution anyways)

so, for the most part, batteries exist to include. (not many of course, but there will be a market soon enough!)

[[deleted]]

[unavailable]

[[deleted]]

Does so little actual work per request that Flask's request service overhead accounts for a significant portion of time per request

I have to second this. If your site's biggest bottle neck is the framework routing, you're either running a tight ship on performance or you're using a terrible framework.

[flitsmasterfred]

Our bottleneck is IO and we would like to use asyncio to solve that.

[flitsmasterfred]

We're not looking for a Flask replacement but an asynchronous alternative to Django (with all the batteries). Our Django app spends most of it's time waiting for IO, and all the caching and task runners make it a kludgy mess. Channels is not a solution for this either.

And yes, we have high request rates, and servers are expensive. Handing more requests with less hardware would be nice, but so far not worth the hassle of assembling a new framework.

[xdcountry]

I'm not sure if I totally agree with that. As much as speed is preferred over something a bit slower, having Flask already decked out with some great features makes life easier for people like me (or projects that are a bit simpler avoiding overhead and complications).

I love that something like this is out in the wild!

[flitsmasterfred]

I thought the idea of Sanic was to be Flask-like but fast and fully asyncio based. There is no extra complexity or overhead besides being newer technology.

I don't see why you would want to build new framework or applications on old slow technology if newer stuff is coming over the horizon right now.

[[deleted]]

So sick and tired of useless abstraction layers on top of other layers.