Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate async web frameworks #11

Open
aecay opened this issue Jun 27, 2019 · 1 comment
Open

Investigate async web frameworks #11

aecay opened this issue Jun 27, 2019 · 1 comment
Labels
brainstorming conceptual issue, which may or may not need concrete code changes

Comments

@aecay
Copy link
Collaborator

aecay commented Jun 27, 2019

We need both an http server and an http client for mite. The client is needed for running the tests themselves; a server is needed for the prometheus exporter. If we do fancy things with javascript/client side testing, websockets, etc., we may eventually want a http/ws server in mite for that as well.

Desiderata:

  • support a wide variety of protocols (ssl, websockets, ...)
  • easy to maintain (3rd party > python only > C)
  • easy to extend (grokkable code, responsive upstream if applicable)
  • fast
  • similar implementation for server and client (ideally same library, at least same broad approach)

There are various existing implementations:

acurl

Pros Cons
the status quo requires C compilation
fast does not support websocket/etc without extension
gives us the timing info we need client only (as it stands)

aiohttp

Pros Cons
wide ecosystem of plugins (websockets etc) requires C compilation (but distribution question is solved)
client and server doesn't provide timing info as it stands

sanic

Pros Cons
apparently very fast server only (as it stands)
pure python(!) server only (again because it's a big deal)

There's a lot to consider, and I haven't formed any clear views yet. My current favorite idea though is to look to sanic for inspiration for writing a client library in pure python (and rely on sanic for serving). Sanic demonstrates that good performance is possible without C. A pure python implementation allows us to add whatever bells and whistles we want to (around timing etc.), while being easy to maintain. Ideally, we can duplicate the functionality of acurl with less code (and zero C). A second choice would be to use acurl as the basis for a server library.

@aecay aecay added the brainstorming conceptual issue, which may or may not need concrete code changes label Jul 9, 2019
@jb098
Copy link
Collaborator

jb098 commented Nov 13, 2019

I think I agree, I'd quite like to lean hard into the Async stuff, as much as I love Flask. Let's try and replace our Flask integrations with Sanic and see how we get on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
brainstorming conceptual issue, which may or may not need concrete code changes
Projects
None yet
Development

No branches or pull requests

2 participants