Coming from a bash scripting background, Rust’s syntax is mind boggling. The code from HttpServer...
to await?
is a single object. Trying to figure out how it works is going to be my first task.
I will return later with results in the replies.
// Create Http server with websocket support
let settings_bind = settings.clone();
HttpServer::new(move || {
let context = LemmyContext::create(
pool.clone(),
chat_server.to_owned(),
client.clone(),
activity_queue.to_owned(),
settings.to_owned(),
secret.to_owned(),
);
let rate_limiter = rate_limiter.clone();
App::new()
.wrap(middleware::Logger::default())
.app_data(Data::new(context))
// The routes
.configure(|cfg| api_routes::config(cfg, &rate_limiter))
.configure(|cfg| lemmy_apub::http::routes::config(cfg, &settings))
.configure(feeds::config)
.configure(|cfg| images::config(cfg, &rate_limiter))
.configure(nodeinfo::config)
.configure(|cfg| webfinger::config(cfg, &settings))
})
.bind((settings_bind.bind, settings_bind.port))?
.run()
.await?;
Initial observations
HttpServer::new(move || { [1] }).bind[2].run().await?;
is the basic structure. [1] consists of two parts,context
andrate_limiter
variablesApp:new()
We see
context
being loaded as.app_data
inApp::new()
, andrate_limiter
being loaded into the config.Then routes are added.
Part of what is unusual to me is defining variables within the server setup. But this may have something to do with the way Rust deals with variables. Since
context
has no meaning outside of this setup, better to use it here and throw it away once we’re done setting up theHttpServer
?Whereas
App::new()
dealt with Lemmy specific app configuration and behavior,.bind
appears to involve more genericHttpServer
configuration stuff [2], including the port to bind to.Then the whole thing
.run()
s, and then.await?
s for multithreading.