Merge branch 'master' of github.com:kennethreitz/responder

This commit is contained in:
2018-10-12 05:25:08 -04:00
+3 -3
View File
@@ -1,4 +1,4 @@
# Responder: a familar HTTP Service Framework for Python
# Responder: a familiar HTTP Service Framework for Python
![](https://github.com/kennethreitz/responder/raw/master/ext/Artboard%201%402x.png)
@@ -99,7 +99,7 @@ The primary concept here is to bring the nicities that are brought forth from bo
- Automatic gzipped-responses (still working on that).
- In addition to Falcon's `on_get`, `on_post`, etc methods, Responder features an `on_request` method, which gets called on every type of request, much like Requests.
- WhiteNoise is built-in, for serving static files.
- Waitress built-in as a production web server. I would have chosen Gunicorn, but it doesn't run on Windows. Plus, Waitress serves well to protect against slowloris attacks, making nginx unneccessary in production.
- Waitress built-in as a production web server. I would have chosen Gunicorn, but it doesn't run on Windows. Plus, Waitress serves well to protect against slowloris attacks, making nginx unnecessary in production.
- GraphQL support, via Graphene. The goal here is to have any GraphQL query exposable at any route, magically.
@@ -112,7 +112,7 @@ The primary concept here is to bring the nicities that are brought forth from bo
## Future Ideas
- I want to be able to "mount" any WSGI app into a sub-route.
- Cooke-based sessions are currently an afterthrought, as this is an API framework, but websites are APIs too.
- Cooke-based sessions are currently an afterthought, as this is an API framework, but websites are APIs too.
- Potentially support ASGI instead of WSGI. Will the tradeoffs be worth it? This is a question to ask. Procedural code works well for 90% use cases.
- If frontend websites are supported, provide an official way to run webpack.