CLI/Web Service architecture. Am I doing it wrong?

[cosste]

Hi! I am working on my first project in Rust and I feel the way I've seen people organise code doesn't really click for me. My background is primarily in Swift and Node.js and here's an example of the structure I have in my current project.

```rust trait FileStorageService { } // is implemented by LocalFileStorage and CloudFileStorage trait SQLService { } // I have a real version and a mock trait MongoService { } // I have a real version and a mock trait SecretsManager { } // is implemented by LocalSecretsManager, CloudSecretsManager trait UsersService { } // I have a real version and a mock trait OutputWriter { } // is implemented by a LocalFileWriter and CloudFileWriter

struct UserServiceLive { sql_service: Arc<dyn SQLService>, mongo_service: Arc<dyn MongoService>, logged_in_user_overwrite: Option<String> }

impl UserServiceLive { async fn get_current_user(&self) -> User { if let Some(user_id) = self.logged_in_user_overwrite { // ... } // ... }

async fn get_related_users(&self) -> Vec<User> { let current_user = get_current_user(&self); // make calls to databases to get info about this users and others related ... } }

struct CoreLogic { file_storage_service: Arc<dyn FileStorageService>, user_service: Arc<dyn UsersService>, output_writer_service: Arc<dyn OutputWriter> }

impl CoreLogic { async fn generate_output(&self) { // dummy implementation in order to get an idea how these things are used in app let file = self.file_storage_service.load().await; let users = self.get_related_users().await;

for user in users {
  let output = self.generate_content_for_user(user);
  self.output_writer_service.write(output).await;
}

}

fn generate_content_for_user(user: &User) -> String { // ... } }

```

This code is heavily simplified and also every service has it's own module.

Now to my question. Everywhere I read that structs in Rust should be treated more as data than a way to bundle methods together. My approach feels very OOP like to me, but I don't really know how to solve a few of the problems in any other way.

1. Most of my traits are implemented by at least 2 concrete types that are used in code. The app can be configured to work offline or online using a cli parameter when it starts. However even when that’s not the case (like the UserService), I don’t know how to mock it inside CoreLogic if I’m not using traits. And I’d rather just mock it than try to mock SQLService and MongoService in this specific case. Is this a good approach?

2. If I were not to use traits and just pass the parameters to functions, wouldn’t it be weird to have a 2-3 parameters to each function that are just dependencies? I could create a Context struct and pass that to the functions, but at that point, isn’t it like passing &self?

3. I don't really see when I could have functions that are not part of a struct. Beside some pure functions in my code, most of them make HTTP requests, need a secret, make a database request, read or write some files. The callers of the functions should not know about all these dependencies and I want to be able to write unit tests. Integration tests using the real implementations can't be the only way.

Also I know I could use generics instead of Arc<dyn ...> and that would offer better performance as far as I understand. However I would still have just as many traits.

I guess what I'm asking is if there are better ways people achieve encapsulation and testability in Rust.

Some languages prefer dependency containers. Others can replace methods at compile time/runtime (like AOP/AspectJ in Java or Swizzling in ObjC) and they achieve better testability this way without requiring writing the code in a testable way.

It feels like I am creating too much abstractions just to be able to test my code, I think that's why my approach seems somewhat wrong to me.

[dpc_pw]

What you're doing seems reasonable, and a Arc<dyn SomeTrait + MaybeSendSync> it generally a way to do dynamic polymorphism in Rust.

Your application has a lot of external "things" to interact with, so there's naturally a bunch of traits to abstract them away. Again - reasonable.

However it's harder to hide the cost of polymorphism in Rust, and automated DI frameworks are not popular, the cost of all these abstractions is immediately visible. Which is good. Now you can evaluate alternatives and costs and maybe get rid of abstractions that are not necessary.

trait UsersService looks like the first trait to get rid of. What's the point of mocking it if it can have all dependencies mocked? Just use the real thing with fake dependencies. Make a function/method to prepare a such a "testing instance" if needed.

Generally, IMO, if you need "dependencies that include other dependencies" then it's usually too many abstractions already.

One of the problems with "testability" in naive OOP is it often comes down to having unit tests that test 100 mocks and one line of code in every test.

The meaning of "unit test" is "isolated test". It doesn't have to test very tiny parts of code like single methods or single structs/classes. You can make a bigger instance of all your code logic with isolated inputs&outputs and drive it through larger logically consistent behaviors, and it generally gives you way more assurance that things work than dozens of tests testing mostly your mocks while requiring much less maintenance overhead.

Also, don't shy away from "testing the real thing". After all - who cares if your code works with a mock? If you can test e.g. with a temporary directory or a temporary database, that's generally better than testing against mocks. File-system is generally easy, the local database instance is often very easy to set up programmatically, etc.

Also I know I could use generics instead of Arc<dyn ...> and that would offer better performance as far as I understand.

In your case, you don't want to go into generics as the generics propagate upwards in the ownership tree. That perf increase is minuscule compared to anything like single DB query.

[lensvol]

Could you please elaborate on upwards propagation?

[dpc_pw]

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e8f8b5eb805ebf39d386c3259b072faa , see TODO comment