how to design a simple bot using the JSON-RPC mode?

[piramiday]

hello, as I have briefly explained in this sub-discussion, I would like to get some pointers from the community with respect to the way in which one can code the simplest possible bot that wraps the JSON-RPC signal-cli functionality.

the simplest possible bot that wraps the normal-mode (non-JSON, non-DBUS) signal-cli features might be, for example, a cronjob that periodically fetches new messages:

MSGFILE=messages-$(date +%s).log

# receive first, e.g.
signal-cli -u +$MYNUM receive > $MSGFILE

# parse and do stuff, e.g.
./my-signal-parser $MSGFILE

# such script could do something like
if [[ "$BODY" = "/date" ]]; then
    date | signal-cli -u +$MYNUM send +$YOURNUM
fi

# etc

with the new JSON-RPC mode, the architecture of this simple loop should change considerably.
having a single signal-cli process that ingests JSON data from a file/pipe and produces output to a file/pipe is relatively straightforward, but how to design the process that parses such data?

one of the benefits of the cronjob, for example, is that I can push a new version of the script (e.g. my-signal-parser above) and thus have an effortless continuous deployment without data loss.

this is not true anymore if I have a parser process that is continuously coupled to the receiver process, e.g.:

(while true; do nc -l -p 9182 <sigsocket; done) | signal-cli -u +$MYNUM jsonRpc | my-parser-script

I guess I could have something like an intermediate message wrapper, e.g.:

# continuous parsing: pipe to file
signal-cli -u +$MYNUM jsonRpc | while read LINE; do
    UNIX_TIME_MIN=$(( $(date +%s)/60 ))
    echo $LINE > messages-minute-$UNIX_TIME_MIN.log
done

#  usual cronjob: file to actions
for MSGFILE in messages-minute-*.log; do
    ./my-signal-parser $MSGFILE
done

in such an example, the continuous parser simply transfers the piped output into a different file that changes every minute, while the cronjob can execute every few minutes and simply ingest message files that are now static and act as necessary.
the continuous parser does not need lots of maintenance and can thus be spun up indefinitely, whereas the usual cronjob is executed anew as per schedule, as thus easily benefits from updated versions.

does this approach make sense?
how would the other folks here go about and structure a bot around the JSON-RPC mode?
I am aware of the go-based Docker REST API, but it's not what I would like to do at present.

it goes without saying that I would like to design something close enough to my original bot so that I could reuse most of my code.

PS: please take all of this as a pseudo-code exercise, I know these bash lines wouldn't pass shellcheck! 😉

[piramiday]

@AsamK do you have any suggestion with respect to this? thanks! 🙏