Hacker News Reader

Comment by da02 | Hacker News Reader

So let's say an event is emitted, does this happen?

* "payment processing" handles it -> changes state -> another event emitted -> "restaurant approval" processes it -> changes state -> another event emitted -> "delivery assignment" processes it

Or does this happen?

* event emitted -> "payment processing" and "restaurant approval" handles event asynchronously, -> state changes -> event emitted -> "delivery assignment" handles event.

View on HN

So instead of clear code to handle the error you have a dozen logic components watching for some events and modyfing state again triggering events and modifying state. Yeah, i absolutely can see how this approach will NOT increase maintainability because now you have 84 logic functions watching for some graphql events, and they may never be down for a microsecond because they would miss a (critical) state change: graphql subscriptions are not like persistent queues

That is why events must be persisted and reliably delivered. And in the frontend, you must subscribe to the state of the world and not necessarily each state change. This way if frontend goes down and comes back up you can show the new state instantly.

Exactly. We created our own even store on top of a SQL database. It's quite simple to do, and it is blazing fast because it is custom built for our use case. It's an append log of every event, their time, their type, and some other info about them (account, user, etc.). The event itself is stored as json, and we can just use Json functions of SQL Server to query those for diagnosis if need be. We've also got failure reporting built in, and strict referential integrity for various other tables to link into the main event storage table.

It was actually a pretty fun weekend project.

Right. But, what if the client (eg browser) would ask the system if the message has been fully processed? Then the client can re-send the message if the Server lost the original message? For example:

  client: "Hey, buddy! Did you process that message I sent you? Here is the ID."
  Server: "No. Send it again."
  client: "Ok. Here is the message again."
  [Server processes it, completes processing it, sends back response.]

If done this way, wouldn't you be able to reduce the need for persistence of the original message and events from the client? (Not that persistence of the original event on the Server would be a bad thing.)

We can do this via the store's aforementioned failure reporting. I guess it could be better? I prefer to have a log of all messages since forever, as in Event Sourcing.

Seems like that is more trouble than it's worth to try to make everything happen purely on a message bus, though the mechanism for letting the system know a new event arrived is a message bus, it just includes the message id, for us.

In this particular case, I meant the former. But you might have workflows where the same event is delivered to multiple serverless compute things simultaneously.

Oh. I see now. Thank you for posting this.

Reply on news.ycombinator.com