Taken blob's http port + 1 as http port.

actix::web::Data has Arc inside it so we don't need another layer of indirection here

Not sure what others think, but now that comm-services-lib has a notion of actix, we may want to just re-export actix-web from comm-service-lib to avoid issues where differences in versions may be mutually incompatible. This does have the effect that bumping actix in comm-services-lib will need to handle version bumps across all down-stream crates.

e.g.

// comm-services-lib/src/lib.rs
#[cfg(feature = "http")]
pub mod http;
#[cfg(feature = "http")]
pub use actix-web

calling code:

use comm_services_lib::actix_web::{web, App, HttpServer};

Yeah I think this is a great idea! This would also solve aws-sdk-* inconsistencies if we had a crate feature database in lib and used its re-exports as a single source of truth for AWS SDKs.

But we'd need to sync about our services - me and @michal are doing lots of related stuff concurrently. I'd schedule this as a follow up right after we land our services.

Makes sense to me! If we decide to use cargo workspaces there's a builtin feature ("sharing dependencies") that would have a similar effect:

# [PROJECT_DIR]/Cargo.toml
[workspace]
members = ["bar"]

[workspace.dependencies]
rand = "0.8.5"

[package]
name = "bar"
version = "0.2.0"

[dependencies]
rand.workspace = true

That's impressive! Wondering about how to make rand.workspace = true optional and enabled only for a specific feature:

[dependencies]
rand.workspace = { optional = true }

[features]
some_feature = [ "dep:rand"]

You can do something like this:

[features]
f_anyhow = ["dep:anyhow"]

[dependencies]
anyhow = { workspace = true, optional = true }

Although I still think we should move to separate crates instead of features. Even with only two features in comm-services-lib (blob-client and http), it's cargo.toml is getting a little unwieldy 😅 (on the other hand, no orphan rules to worry about is nice).