Application Architecture Question
(Pardon my shitty drawing)
Essentially App 1 (you can think of it as a .NET or other application) passes Json messages via a MQ to a rendering app. I'm using a MQ because I want the messages to be received in order.
We want to build up the rendered environment in the renderer progressively using json generated by user input from App 1.
My question is, is this architecture 'correct' or does it make sense for this use case?
Is there a better way to do this?
What kind of timeout makes sense to wipe the queue so that the renderer (subscriber) doesn't accidentally access messages from a previous run/activity?
9 Replies
I'm assuming app1 and renderer aren't the same application. Otherwise, it's a fairly simple architecture. So yeah there's no real problem. Many queuing platforms suffer from "at least once delivery" so you should always be prepared to handle duplicates, either via idempotency, our duplication detection.
Some messaging systems support an "invisibility" period where when you receive the message it will be invisible to further operations for some time to allow you to process and more formally delete/acknowledge the message.
are you literally sending objects to render via json in a queue? 🤔
I tend not to judge these things and take them at face value.
i know, but asking doesn't hurt, i'm kinda curious
IMHO we won't hear back, usually these types of questions are just abandoned by the OP.
I don't like to spend a lot of effort until they show up with either more questions or more elaboration.
can confirm
It's just the way of things
Sorry, I was working on other stuff the whole day yesterday
Yes, basically json files
First message in the queue would define how the grid is
Row: int
Column: int
All subsequent messages would be what location to edit, and what item to change
Location: int[2]
Value: int
These are good keywords- thanks for the heads up
I mean there's nothing exciting here
Can you do it, sure
where do you want to host the messaging system?