bbernhard
commented
2 years ago You are right, there's definitely room for improvement here.
But I think no matter what we do, there's always a (small) risk of losing data. e.g the message broker could be down, we could run out of disk space to store messages, the docker container could crash, etc. So I guess the only thing we can probably do is to make the whole thing as robust as possible and try to minimize the chance of data loss.
Another idea that's in my head for a while now, is to add a possibility to register custom user scripts via pre-/post command hooks. That way you could e.g write yourself a small javascript/luascript which is then invoked every time a message is received. In that script you could e.g write the received data to the disk.
jrmgx
This is rather supposed to be a discussion than a specific feature request.
I have not specifically tested signal-cli-rest-api in edge cases yet but looking at the code it seems like message could easily be lost if the WebSocket connection in daemon for some reason is not operational. Thinking about this issue I got several ideas how to fix that.
1. WebSocket with ACKs and retry
This approach would be closest to what we currently have. Incoming messages would require either an explicit ACK or a library which handles a reliable WebSocket connection.
2. Webhook via POST request
This would generally be a huge benefit for microservice architectures and easier to implement than WebSockets especially in PHP where long running operation are generally difficult. In my opinion it would be cleaner than a complicated WebSocket.
3. Message Broker
While both 1. and 2. would require signal-cli-rest-api to temporary store messages, using a message broker and treating it as "reliable" would be kind of a cheat but most likely acceptable for my use case.