zerotier/ratpack
0
0
Fork 0
mirror of https://github.com/zerotier/ratpack.git synced 2026-05-22 16:27:23 -07:00
Code Issues Packages Projects Releases Wiki Activity

correct a technical nit

Browse Source 
Signed-off-by: Erik Hollensbe <linux@hollensbe.org>
This commit is contained in:
Erik Hollensbe
2022-01-22 16:35:14 -08:00
parent 0317eff3a8
commit de97fc0c5e
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+1 -1
View File
@@ -7,7 +7,7 @@
## What ratpack is not
- Complicated: `ratpack` is not especially designed for services with a large web of routes or complicated interactions with the HTTP protocol, such as SSE or Websockets (at this time, at least). `ratpack` is very focused on somewhat typical request/response cycles.
- Verbose: `ratpack` tries very hard to make both its internals and your interaction with it _the simplest thing that could possibly work_. This means that your requests are functions you pass to a macro called `compose_handler!` which you pass to routing calls, and that likely, you won't be spending your time implementing complicated, extremely verbose traits or even need complicated understandings of how futures and `async` work.
- Verbose: `ratpack` tries very hard to make both its internals and your interaction with it _the simplest thing that could possibly work_. This means that your request handlers are functions you pass to a macro called `compose_handler!` which you pass to routing calls, and that likely, you won't be spending your time implementing complicated, extremely verbose traits or even need complicated understandings of how futures and `async` work.
- Focused on one platform: while at this time we only directly support `tokio`, nothing is keeping us from moving into `smol` and `async-std`'s territory. The majority of `ratpack`'s use of `async` are futures that `tokio` ends up leveraging from a very high level.
## Example