Hacker News Reader

Comment by sandGorgon | Hacker News Reader

You totally should. I think people are hungry for a next gen async web framework... And if it leverages Python 3, then so much the better. Flask cannot go here even if it wants because its core philosophy is to be WSGI compliant. You don't necessarily have to adhere to that.

Just one point, please make sure you have designed DB access as a core part of your framework (e.g. [1]). Too many frameworks discount database interaction until it's too late.

Oh and please please choose your name so that it doesn't conflict on Google search. http://www.spinframework.org

[1] http://initd.org/psycopg/docs/advanced.html#async-support vs https://github.com/chtd/psycopg2cffi

View on HN

Since spin is conflicting, may I suggest spyn? Gets that nice little Python 'py' in there.

Can also be read as "spine".

> Just one point, please make sure you have designed DB access as a core part of your framework (e.g. [1]). Too many frameworks discount database interaction until it's too late.

I strongly advise against this. One of the reasons Flask is so attractive is the fact that it does not enforce any database on you.

Thanks to its decoupled design you can use it purely as a routing library, which is great! Letting the framework decide something important as the database is a bad idea. [1]

[1] https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arc...

that is ok - but there is a representative library that works. Loosely decoupled but definitively working is beautiful... and this is why I use Flask in my startup.

what frequently happens is a web framework without a thought for any kind of DB interaction (or as you put it... a routing library). In things like an async web framework, that could leave users hanging. For example, psycopg vs psycopg2 vs psycogreen vs psycopg2-cffi . Tell me which one to use and benchmark it.

I agree, its a fine line. And we can keep going back and forth whether a framework should "recommend" or not recommend. But in case like this - I think there will NOT be a lot of libraries that will be compliant with the async usecase. I would hope that this framework will recommend... but not ship "batteries included".

If such a framework was built around asyncio, do we really need yet another database layer? 1 of the best things about Flask is it doesn't reinvent the wheel.

It's not so much as another dB layer, but some async compatible dB layer.

Most database libraries don't play very well with non blocking code. In fact nodejs dB libraries were specifically designed for this.

Building async frameworks is not trivial - http://initd.org/psycopg/docs/advanced.html#async-support

Reply on news.ycombinator.com