Versions Compared

Version Old Version 4 New Version Current
Changes made by

Vadim Reutskiy

Egor Ivkov

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Page Properties
label


Status

Status
colour

Yellow

Green
title

In progress

DECIDED

Stakeholders

武宮誠 Vadim Reutskiy Nikita Puzankov

OutcomeCustom web server library will be implemented with the use of the 3 suggested helper libraries
Due date
19
Owner
Egor Ivkov 


Background

...

  1. Async I/O - as Iroha2 is heavily async and relies on executors for low-level thread management.
  2. A relatively small number of new dependencies - as new dependencies introduce potential security risks.
  3. Library rather than framework - as Iroha2 has already a rather specific structure and should not change its style to fit the framework.
  4. It should be possible to upgrade HTTP connection from HTTP library with WebSocket
  5. Free open license
  6. HTTP 1.1 support - as Substrate offchain workers do not support HTTP 2

Proposed Libraries

The proposed libraries are the following:

ProtocolLibraryDescription
HTTPhttphttparseA general-purpose library of common HTTP types. This means that it will be needed to implement our own HTTP server with the use of this librarypush parser for the HTTP 1.x protocol. Avoids allocations. No copy. Fast.

route-recognizerRecognizes URL patterns with support for dynamic and glob segments. Can be easily replaced with our custom solution later. Used to speed up the development process. Also doesn't have any dependencies.
Web Socketasync-tungsteniteAsynchronous WebSockets for async-std, tokio, gio and any std Futures runtime. Based on tungstenite crate.

The usage of these libraries would, in general, mean that we will implement our own web server based on TCP streams, but the messages will be parsed with the help of HTTP library. When the upgrade request for web socket will be received, then the connection manager will be passed to async-tangstenite tungstenite library.

Alternatives

AlternativeDescriptionWhy not chosen
tiny_http as HTTP server libraryLow-level HTTP server libraryNo async support
http as HTTP type helper libraryA general-purpose library of common HTTP types.Does not support parsing from streams or raw bytes, which is a functionality that we might spend a lot of time writing if it is not supported out of the box.
async_h1 as HTTP server libraryAsynchronous HTTP/1.1 parser.Does not support WebSocket upgrade.
hyper as HTTP server libraryA fast and correct HTTP implementation for Rust. Actually the fastest HTTP server library according to techempower.
  1. Has many dependencies and one of them is tokio which is not optional.
  2. No information on whether it will work with async-std as it is built with the use of tokio.
  3. Not possible to upgrade the HTTP connection with web socket
https://github.com/carllerche/h2Http 2.0 is not supported by the substratehttps://crates.io/crates/http-servicehttps://github.com/http-rs/tide
  1. .
h2 as HTTP server libraryA Tokio aware, HTTP/2.0 client & server implementation for Rust.
  1. It is not possible to use http 2.0 currently - see requirements.
  2. Depends on tokio - same concerns as with hyper.
http-service as HTTP server interface libraryThe crate http-service provides the necessary types and traits to implement your own HTTP Server.The crate mainly provides the interface for the servers to implement the same methods, it might be good for architecture in general, but it is an additional dependency and our priority is to only add absolutely necessary ones.
tide as http serverA modular web framework built around async/await.
  1. It is a framework, though less opinionated as others, it still imposes some limitations
  2. No WebSocket protocol upgrade is supported at the moment. But this feature seems to be under development.

In general it might have been a good choice if they had finished web socket support by now.

actix / warp / rocket as web frameworkPopular web frameworks with both warp and rocket being built on the hyper library,
  1. They are Web Frameworks and it is preferable to use a library.
  2. They have many dependencies, where most of them are not needed for our purposes.
Custom http and web socket librariesIt is possible to implement a fully custom solution.

There are already existing solutions which correctly implement the standards and are widely used.

The team will be able to focus on our unique functionality.

...