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

Replace actix-web with a simpler stack and fewer dependencies #189

Closed
timbru opened this issue Jan 28, 2020 · 6 comments
Closed

Replace actix-web with a simpler stack and fewer dependencies #189

timbru opened this issue Jan 28, 2020 · 6 comments

Comments

@timbru
Copy link
Contributor

timbru commented Jan 28, 2020

We can use code from one of Martin's projects for this. Since we do not need all the features from a full fledged http server we can make do with something simpler and in the process have fewer dependencies.

@ghost
Copy link

ghost commented Feb 28, 2020

there is https://hyper.rs/ ; not a tremendous amount of deps: https://github.com/hyperium/hyper/blob/master/Cargo.toml#L22

@timbru
Copy link
Contributor Author

timbru commented Mar 2, 2020

Yes, I know. Actually, I started working on this last week.

Hyper is quite nice to use, and if you look at the code that my colleague Martin is using in a personal project then it looks like we could make this do all we need with very little boilerplate.

However... I have been trying to get the hyper server to work with https and this proves to be quite challenging. What examples existed before, don't work with the recent versions of hyper, tokio and/or native_tls. Working it out from the code is not easy.

Dropping https as some people suggest (e.g. reddit) and just leaving this to a proxy is not an option. I understand and partially agree with the reasoning (e.g. nginx is just better at this, intergrates better with letsencrypt etc), this would be a regression that will not be acceptable to our user base.

I looked into using warp earlier, which is based around hyper, and which does https. But I found its routing to become complicated for our cases, and it seemed hard / impossible to make the rejection system work like we needed for our api. So, while this could work (and looks like a promising framework in general), it seemed that warp complicated, rather than simplified our code base. Still, I will have a look at how Warp manages to run a hyper server with TLS, and see what I can borrow from that.

So, there is a bit more work to do on this one.

@ghost
Copy link

ghost commented Mar 2, 2020

Not sure if you have noticed this: hyperium/hyper#985

@timbru
Copy link
Contributor Author

timbru commented Mar 15, 2020

As a result of all this, lots and lots of stuff had to become asynchronous. This is a good thing in itself, but proved to be a lot of work. By now, the tests are green again, but there is some work remaining before this can be merged:

  • Serve the static files again - so lagosta can be used here
  • Clean up the test util modules - merge them into one
  • Clean up: move the code in 'endpoints.rs' into 'http/server.rs'

@timbru
Copy link
Contributor Author

timbru commented Mar 15, 2020

Not sure if you have noticed this: hyperium/hyper#985

I got things working by looking at, and adapting, how this is done in Warp.

@timbru
Copy link
Contributor Author

timbru commented Mar 16, 2020

merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant