Does it make sense to use Firestore Realtime as a way to interact with functions?

Question

I have a good old fashioned piece of code that takes some inputs, runs some code and produces outputs for a variety of tasks. This code runs in a function, and it should be triggered by a UI action. It is relevant to store a history of these runs per user, to list them in a specific view of the UI, and, on returning users, put them back where they left.

Since the Firestore documentation and videos strongly encourage us to default to it for data exchange with the backend, I of course decided to entertain the idea before just moving on to simply implementing a callable.

First, it made sense to me to model the data as follows:

/users
  id

  /taskRuns
    id
    inputs
    outputs

    /history
      id
      date
      ...outputs

and make the data flow as follows:

1. The UI writes to the inputs field and it listens to the document.
2. The unction is triggered. It runs happily and it writes to outputs.
   • A second function listening to /assets puts copies over the inputs and outputs onto its corresponding /history subcollection.
3. The UI reacts to the change.

At this point, a couple of red flags are raised on my mind:

• Since the UI has to both read and write /assets, a malicious user could technically trigger infinite loops here. I'm aware that the same thing is possible with a callable, but it somehow seems even easier in this scenario.
• I lose the ability to do timeout and error handling the way one would with a simple API call.

However, I also understand that:

• My function needs to write to the database anyway to store the outputs even if it was returning it à la API.
• Logic for who's responsible for what has somewhat been broken down into pieces.

So - Am I looking at it wrong? Is there a world in which this approach would make sense over the callable?