2 ms·

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

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 http://www.spinframework.org [1] http://initd.org/psycopg/docs/advanced.html#async-support http://initd.org/psycopg/docs/advanced.html#async-support vs https://github.com/chtd/psycopg2cffi https://github.com/chtd/psycopg2cffi

jagger27 11y ago
Since spin is conflicting, may I suggest spyn? Gets that nice little Python 'py' in there.
- hasenj 11y ago
  Can also be read as "spine".
alexchamberlain 11y ago
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.
- sandGorgon 11y ago
  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 http://initd.org/psycopg/docs/advanced.html#async-support
michaelmcmillan 11y ago
> 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-architecture.html https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arc...
- sandGorgon 11y ago
  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".

jagger27 11y ago

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

hasenj 11y ago
Can also be read as "spine".

alexchamberlain 11y ago

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.

sandGorgon 11y ago
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 http://initd.org/psycopg/docs/advanced.html#async-support

michaelmcmillan 11y ago

> 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-architecture.html https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-arc...

sandGorgon 11y ago
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".