# Workers should just perform API calls

* Status: Accepted
* Deciders: Marino, Zorica, Stefanija, Davide, Tomasz, Maciej
* Date: 08/09/2021



## Context and Problem Statement

Currently in the project we still use multiple different approaches for doing background work. As we are
trying to settle on using Android Worker, we want to define the particular use case in which we are gonna
need to rely on said Worker. It's easy to abuse the Worker component if we are calling it from different places
and for different usages, so we needed to be specific on when and why we should use it.

## Decision Outcome

* Android Worker should only perform API calls (no business logic, no local data handling)
* Worker should only be called from Repositories
* They can be called as a "fire and forget" in some cases (eg. star message, since a failure is very
unlikely and even if verified the consequences would be light).
* When we need the UI to be able to react to API failures, we should have the repo returning a flow
(first "optimistically" just after saving to DB and then once we get the API response)

### Exceptions

Some special cases call for a different use of Worker. So we agreed on some exceptions where workers
will contain more:
* Case of "send message": we need all of the business logic to be in a worker as killing the app right
after hitting send is a valid use case
* Case of "add lots of labels to a message": we need to dispatch this through a worker because of
"performances constraints" (the operation is started from an action view model which won't live long
enough for the action to complete, but even if it wasn't the case the action is very slow and resource
intensive so it would block the UI if performed in the VM)
