Abstracting common functionality for REST and CLI

Question

I have made an application that deals with collections of images. Currently it has a REST api to add/remove images, create/clear/delete collections and a worker that can automatically fetch images from sources.

I want to make a CLI application to execute some tasks. An example of a task would be to clear a collection, delete a collection etc but also to create/clear the database and also run the worker.

Since the REST api and the CLI have some common functionality, I am thinking to abstract the functionality in tasks (eg AddImageTask, ClearCollectionTask). The worker will also have a task, FetchImagesTask.

Now, the issue is logging. For debug stuff, I think it's ok to implement inside the task. But for some long running tasks like the worker task, I want some in between logging (search for images -> 'Found N images', download image -> 'downloading n/N images', etc). I don't find that appropriate to be used by the REST api.

The worker task would probably not be executed by the REST api but some other long running tasks maybe would.

My solution to this is to have the REST api call the tasks directly and the CLI to wrap the tasks using commands.

So, for a simple command like CreateCollectionCommand:

public void execute() {
    new CreateCollectionTask(...).execute();
    log("Created collection");
}

and for long running tasks like FetchImagesTask:

public void execute() {
    var task = new FetchImagesTask(...);
    task.onSearchResults(results -> print(...));
    task.onDownloadImage((index, total) -> print(...));
    task.execute();
    log("Added N new images to collection");
}

My questions are:

1. Is the command pattern appropriate for logging stuff? I read somewhere that it shouldn't change the state of the UI.
2. Some commands will require a database connection, where would be the correct place for the connection code? Inside the execute method? In some other init method? Or maybe as a constructor dependency? The last options seems the most complicated to me but also the most clean.
3. Could I just scrape all this and have the REST api and the CLI both just execute the tasks? Are some logging statements in the REST api a big deal?

I should say that I am aiming for as clean design as I can, as this probably will be a very big project and will take a long time. I don't want to have to refactor it much later but I am open to suggestions since this my first time making something this big and I intend to learn from it.

Answer 1

I am not sure I understood all the details of what you are trying to accomplish, but it seems dependency injection is pretty much the solution you are looking for:

• you sometimes need logging, sometimes not: so inject an abstract "logger" here (maybe a callback function, maybe an object), and let the tasks or commands call this logger wherever it could be useful. When you don't need any logging, inject a logger with empty implementations. If you need logging to the console or to a file, inject a logger which does exactly this. For example, in your REST context, an empty logger or file logger could be injected, in your CLI context, a command line logger could be injected, whatever serves you best.

• same for the database connection: if your REST api requires a DB connection, and your CLI a different one, inject a database context (through some abstract interface) from outside. For making a decision about where the connection should be initialized, one has to know your system better than me, but the tasks are most probably the wrong place for this. This can also be used for unit testing purposes, by providing a "mock" db context.