From cd48bb0789af99943744ede4bf32db68aaa90b0b Mon Sep 17 00:00:00 2001 From: Kenneth Reitz Date: Sat, 13 Oct 2018 07:50:09 -0400 Subject: [PATCH] update readme --- README.md | 7 +++---- docs/source/index.rst | 18 +++++++++--------- 2 files changed, 12 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index c91e13e..9221f60 100644 --- a/README.md +++ b/README.md @@ -144,20 +144,19 @@ The primary concept here is to bring the niceties that are brought forth from bo ## Ideas -- Flask-style route expression, with new capabilities -- primarily, the ability to cast a parameter to integers as well as other types that are missing from Flask, all while using Python 3.6+'s new f-string syntax. +- Flask-style route expression, with new capabilities -- all while using Python 3.6+'s new f-string syntax. - I love Falcon's "every request and response is passed into to each view and mutated" methodology, especially `response.media`, and have used it here. In addition to supporting JSON, I have decided to support YAML as well, as Kubernetes is slowly taking over the world, and it uses YAML for all the things. Content-negotiation and all that. - **A built in testing client that uses the actual Requests you know and love**. - The ability to mount other WSGI apps easily. - Automatic gzipped-responses. - 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 unnecessary in production. +- A production static file server is built-in. +- Uvicorn built-in as a production web server. I would have chosen Gunicorn, but it doesn't run on Windows. Plus, Uvicorn 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. ## Future Ideas - Cookie-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. # The Goal diff --git a/docs/source/index.rst b/docs/source/index.rst index da3c544..5d0e72f 100644 --- a/docs/source/index.rst +++ b/docs/source/index.rst @@ -172,22 +172,22 @@ The Basic Idea The primary concept here is to bring the nicities that are brought forth from both Flask and Falcon and unify them into a single framework, along with some new ideas I have. I also wanted to take some of the API primitives that are instilled in the Requests library and put them into a web framework. So, you'll find a lot of parallels here with Requests. -- Setting `resp.text` sends back unicode, while setting `resp.content` sends back bytes. -- Setting `resp.media` sends back JSON/YAML (`.text`/`.content` override this). -- Case-insensitive `req.headers` dict (from Requests directly). -- `resp.status_code`, `req.method`, `req.url`, and other familiar friends. +- Setting ``resp.text`` sends back unicode, while setting ``resp.content`` sends back bytes. +- Setting `resp.media` sends back JSON/YAML (``.text``/``.content`` override this). +- Case-insensitive ``req.headers`` dict (from Requests directly). +- ``resp.status_code``, ``req.method``, ``req.url``, and other familiar friends. Ideas ----- -- Flask-style route expression, with new capabilities -- primarily, the ability to cast a parameter to integers as well as other types that are missing from Flask, all while using Python 3.6+'s new f-string syntax. -- I love Falcon's "every request and response is passed into to each view and mutated" methodology, especially `response.media`, and have used it here. In addition to supporting JSON, I have decided to support YAML as well, as Kubernetes is slowly taking over the world, and it uses YAML for all the things. Content-negotiation and all that. +- Flask-style route expression, with new capabilities -- all while using Python 3.6+'s new f-string syntax. +- I love Falcon's "every request and response is passed into to each view and mutated" methodology, especially ``response.media``, and have used it here. In addition to supporting JSON, I have decided to support YAML as well, as Kubernetes is slowly taking over the world, and it uses YAML for all the things. Content-negotiation and all that. - **A built in testing client that uses the actual Requests you know and love**. - The ability to mount other WSGI apps easily. - Automatic gzipped-responses. -- 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. +- 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. +- A production static files server is built-in. +- Uvicorn built-in as a production web server. I would have chosen Gunicorn, but it doesn't run on Windows. Plus, Uvicorn serves well to protect against slowloris attacks, making nginx unneccessary in production. - GraphQL support, via Graphene. The goal here is to have any GraphQL query exposable at any route, magically.