sparckles / robyn Goto Github PK

Try to create a way to mount directory

Now we need to integrate actix router to parse the routes correctly.

Add "HTTP server" around the docs a bit more? Just referring to it as "a framework" or "backend" isn't very descriptive

From here: https://www.reddit.com/user/tunisia3507/

Robyn will follow the PEP guidelines required to confirm to ASGI specifications.

What this means is that the user/developer will still have the ability to use their preference of ASGI server in front of the framework.

Having said that, most *sgis are written in CPython and they are theoretically slower than their rust counterpart. Robyn will focus on speed and that's why Robyn will also ship with a server implementation. This server will also act as an ASGI but being coupled with Robyn will prioritise Robyn and hence is not being shipped as another ASGI written in rust.

If I ever feel that I am maintaining two projects(SGI and a framework) instead of one(just robyn) we would create two separate projects. Otherwise, if there comes another SGI in the future that is written in Rust or faster than my implementation, we will kill the SGI in Robyn.

TL;DR

• Robyn will be an ASGI compliant and the dev can use an external ASGI if they want to. Although, the inbuilt SGI will be good enough maybe even better 👀

Integrate a github action for

• Creating releases on github
• Generating changelog
• issue templates
• pr templates
• travis testing pipeline

Add better docs
and code the homepage that you(Sanskar) have in mind.

Instead of depending on two docker compose services, start the other Python services using fixtures.

Make a new release with the updated docs and add #64 before making a release!

Try to modularise code.

The current code is smelling a bit and is giving off monkey patch vibes.

Try splitting it into a more organised file structure. Considering the inclusion of tests.

I have been using the --dev=true flag a lot more than the prod build.

It makes sense in my opinion to enable the reload mode by default and have the developer disable it while deploying.

I can trace back to this issue: 08dbb14

Use better pre built libraries instead of manually checking for GET, POST, etc.

Make the readme prettier

https://docs.rs/reqwest/0.11.4/reqwest/

Async requests in python are very verbose. (3-4 lines for a single await)

Make a way to add easier requests in robyn!

Need to fix the following

• several un-needed dependencies (hyper, serde, serde_json, async-trait, log, async-channel)

• The use of both async-std and tokio doesn't really make sense, combined with another thread pool the setup seems in-efficient.

• Remove the use of blocking sockets

• The server only accepts another connection after the previously accepted connection has been read from, this will cause SIGNIFICANT performance issues especially if a client is slow at sending data.

• Server doesn't actually support multiple requests on the same connection, which breaks any use in the real world because 1 connection can send many requests.

• Server assumes that all content returned from the framework will be a string, which in reality should be Bytes because there is no guarantee in the HTTP world that the response must be UTF-8. || Add support for JSON and other types

• Server only reads 1024 bytes of data from the socket when you first accept it, at least from what I can see. This means that if the request size is greater than 1024 the next request to go through that connection will be invalid in all likely hood.

• The server doesn't check if the actual HTTP request itself is valid, it just assumes that if it contains GET, POST, etc... That it's valid meaning you could have a POST request contain GET in the body and the server would treat it like a GET.

• No HTTP header handling, you simply assume the response from python will only be the body, which creates issues if you want to set any kind of headers or some other status code.

• If the client disconnects from the connection early, Python call fails, or and conversion fails the server will panic, and depending on where that happens it can cause the entire server to just shut down.

We should experiment with ways to speed this up

Add a flag that allows hot reloading of web server.

https://docs.rs/notify/4.0.10/notify/#default-debounced-api

Discussed in #50

https://rust-lang.github.io/async-book/09_example/02_handling_connections_concurrently.html

Under the Contributor guideline section, the link for architecture redirects to raw content. It should redirect to
https://github.com/sansyrox/robyn/blob/main/docs/architecture.md

Issue section:
https://github.com/sansyrox/robyn#contributor-guidelines

#20 (comment)

Read discussion above

And see if introducing a threadpool will impact asgi compliance(most probably not) but still check again.

Right now body can only be added to POST in robyn.

Add the feature to add the support for the other two as well.

Return a request object instead of just a body.

The object will contain , body/data, headers , etc.

Most of the functions are without any doc strings.
Add verbosity!

Issue:

At present, our application does not include MIME types in the HTTP responses. The lack of MIME types can potentially lead to certain issues such as client applications not being able to correctly interpret the content received from our server. This could affect the overall user experience and could even result in security vulnerabilities if not properly addressed.

Expected Behavior:

When our server sends out a response, it should include the correct MIME type in the Content-Type header field. This way, the client applications will know how to interpret the received data.

Maybe this version will be called version 1.x.x, but it doesn't really matter at the moment.

I would want to focus on web socket integration after HTTP 1.1 integration.

I will be reading more about it and try to implement that.

The link in the attached screenshot points here rather than here!

PS: Awesome work with the project :)

Using the hello world example from README.md, and benchmark it with oha

1st round

❯ oha -n 10000 http://localhost:5000
Summary:
  Success rate:	0.8308
  Total:	1.2192 secs
  Slowest:	0.1544 secs
  Fastest:	0.0028 secs
  Average:	0.0073 secs
  Requests/sec:	8202.1065

  Total data:	105.47 KiB
  Size/request:	13 B
  Size/sec:	86.51 KiB

Response time histogram:
  0.002 [68]   |
  0.003 [4340] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.005 [2943] |■■■■■■■■■■■■■■■■■■■■■
  0.007 [754]  |■■■■■
  0.009 [149]  |■
  0.010 [4]    |
  0.012 [0]    |
  0.014 [0]    |
  0.016 [0]    |
  0.017 [0]    |
  0.019 [50]   |

Latency distribution:
  10% in 0.0051 secs
  25% in 0.0055 secs
  50% in 0.0062 secs
  75% in 0.0071 secs
  90% in 0.0082 secs
  95% in 0.0089 secs
  99% in 0.0106 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0035 secs, 0.0002 secs, 0.1505 secs
  DNS-lookup:	0.0000 secs, 0.0000 secs, 0.0002 secs

Status code distribution:
  [200] 8308 responses

Error distribution:
  [1600] connection closed before message completed
  [92] operation was canceled: connection closed

2nd round

❯ oha -n 10000 http://localhost:5000
Summary:
  Success rate:	0.8167
  Total:	7.3648 secs
  Slowest:	0.1063 secs
  Fastest:	0.0006 secs
  Average:	0.0070 secs
  Requests/sec:	1327.3908

  Total data:	101.36 KiB
  Size/request:	13 B
  Size/sec:	13.76 KiB

Response time histogram:
  0.002 [29]   |
  0.004 [47]   |
  0.006 [3783] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.007 [3249] |■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.009 [771]  |■■■■■■
  0.011 [52]   |
  0.013 [5]    |
  0.015 [0]    |
  0.017 [0]    |
  0.018 [0]    |
  0.020 [48]   |

Latency distribution:
  10% in 0.0050 secs
  25% in 0.0055 secs
  50% in 0.0062 secs
  75% in 0.0071 secs
  90% in 0.0081 secs
  95% in 0.0087 secs
  99% in 0.0102 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0034 secs, 0.0002 secs, 0.1020 secs
  DNS-lookup:	0.0000 secs, 0.0000 secs, 0.0001 secs

Status code distribution:
  [200] 7984 responses

Error distribution:
  [1719] connection closed before message completed
  [73] operation was canceled: connection closed

3rd round

❯ oha -n 10000 http://localhost:5000
Summary:
  Success rate:	0.8108
  Total:	8.9002 secs
  Slowest:	0.0075 secs
  Fastest:	0.0009 secs
  Average:	0.0047 secs
  Requests/sec:	8.3144

  Total data:	780 B
  Size/request:	13 B
  Size/sec:	87 B

Response time histogram:
  0.001 [3]  |■■■■■■■
  0.001 [7]  |■■■■■■■■■■■■■■■■■
  0.002 [4]  |■■■■■■■■■
  0.002 [1]  |■■
  0.003 [10] |■■■■■■■■■■■■■■■■■■■■■■■■
  0.004 [4]  |■■■■■■■■■
  0.004 [2]  |■■■■
  0.005 [2]  |■■■■
  0.005 [6]  |■■■■■■■■■■■■■■
  0.006 [13] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.007 [8]  |■■■■■■■■■■■■■■■■■■■

Latency distribution:
  10% in 0.0019 secs
  25% in 0.0034 secs
  50% in 0.0049 secs
  75% in 0.0065 secs
  90% in 0.0070 secs
  95% in 0.0071 secs
  99% in 0.0075 secs

Details (average, fastest, slowest):
  DNS+dialup:	0.0022 secs, 0.0002 secs, 0.0040 secs
  DNS-lookup:	0.0000 secs, 0.0000 secs, 0.0002 secs

Status code distribution:
  [200] 60 responses

Error distribution:
  [13] connection closed before message completed
  [1] operation was canceled: connection closed

• Improve the docs!
• Add Python Tests!!!
• Modularise code
• Add a performance comparison with other frameworks
• Reveal the logo
• (Maybe) add docs for plugin creation. (Push to 0.8)
• Integrate actix router (Push to 0.8)
• Create the homepage
• Make request object accessible across all the routes
• Make headers accessible in every route
• Integrate circle ci testing
• Add rust tests
• Make the server ready for HTTP 1.1
• Add the option of 0.0.0.0
• Add python tests

Right now we can serve static files but now we should add the ability to serve static folders/directories.

This way we can add support to build folders of famous front end frameworks.

Integrate support for the Pytest files.

I think I may know a way to do that.

Explore the possibility to do that.

I wonder if we should off an option for a constant response which won't change, this would allow us to never touch python for ultra fast path solutions.

Once we decide the kind of router we want to use, we should also consider adding caching to it.

Error while running test.py. Did you forget adding files ?
Note: already cloned the repo, and also did pip install robyn

Replace 127.0.0.1 with 0.0.0.0 in the server file.

Add this ability in the app.start() method.

This will create an issue with the release of OSX versions.

Need to fix this.

Consider looking at the implementation of https://docs.rs/route-recognizer/0.3.0/route_recognizer/

They have a very good implementation of handling routes.

Try reading the documentation of this : https://crates.io/crates/httparse

Improve the router. Add the ability to have variable parameters in the routes.

• Consider if we need to use a regex based router | as ripgrep is very fast
• Or we need to use a vanilla stack based router
• Or we need to go all fancy and implement a radix tree (or something similar) ourselves!

• Head
• Delete
• Connect
• Options
• Trace

The app is not responding on lossy utf. Fix it!

Github builds are failing. Maybe the latest version will fix this.

No tests atm. Add tests for Python and Rust.