1 of 61

Event Driven Frontends

WHAT, WHY & HOW

(not necessarily in that order)

Matthew Cox

Software Engineer with

linkedin.com/in/matthewcoxlondon�

@matt-matters.bsky.social

Welcome to my talk – Event Driven Frontends. I’m Matthew Cox and I’ve titled this talk Event Driven Frontends; What, Why and How. Just to be annoying, I’m going to be reordering things slightly, starting with the Why

Hi I'm Matt Cox. I'm a software engineer with Guestline, which is part of The Access Group. Guestline are a company that make Property Management software, so that's software used mostly by hotels to manage their business, to manage the day to day running of their hotel.

I work mostly on the frontend and our team have been playing around with a pattern that we're calling Event Driven Frontends. We think it's an interesting idea and we're finding some real benefits in it, and we thought it would be worth sharing what we're doing and what we've found.

So my talk is Event Driven Frontends, What, Why and How

...although not necessarily in that order!

2 of 61

First… some caveats

Fits within an Event Driven Architecture

Not browser events (click, mouseover etc) but business events (Eg Reservation Created)

Pushes the browser hard (sometimes close to breaking point)
Not applicable everywhere. Most suited for returning / invested users
We’re still experimenting!

This is a pattern where we bring raw events from an event driven system right into the browser. What do I mean by Event Driven...?

It’s heavy, it asks a lot of the browser. It pushes against the limits of what the browser can do.

This pattern is unlikely to be applicable to most web apps, even those that exist within an event driven architecture. Frankly, it requires a degree of patience and tolerance from the end users. I might be wrong, but I doubt this would be applicable to a general, public facing website where milliseconds really matter, internet connections are slow and flaky, and some people are still using Internet Explorer.

It is something that we have been experimenting with, and are still experimenting with. I will be extolling the benefits that we have found using this pattern because my time is brief and I want to speak with conviction, but there are pain points. It might not even end up being something we stick with, but it’s been really interesting learning and playing with this idea.

3 of 61

The Why

4 of 61

Example�Reporting in a Property Management System (PMS)

PMS

Customer A�THE GRAND HOTEL

Customer B�COMFORT STAY HOTEL

Customer C�LAKESIDE INN

5 of 61

Example�Reporting in a Property Management System (PMS)

PMS

Customer A�THE GRAND HOTEL

Customer B�COMFORT STAY HOTEL

Customer C�LAKESIDE INN

Revenue Manager

6 of 61

Why

7 of 61

Why

8 of 61

Why

9 of 61

Why

10 of 61

Why

Problems to solve

High cost of infrastructure

11 of 61

Why

12 of 61

Why

Backend team

Frontend team

13 of 61

Why

The workflow might look like this… where we (as the frontend team) want to create that new report. We’ll need to ask the backend team to do some development so we’ll need to first scope out our idea so that we know what to ask of the backend team. They’ll need to scope out the work… fit it into their sprints, and find the time build, test and refine before passing it back to us. We will test it and may find we need some changes so we pass it back to them. Once we’re happy we can get on with the build and then release where we would hope to get some feedback from our users that we can then iterate on and the process starts all over again. It’s quite arduous… I might have slightly exaggerated the pain of that here but you get my point that when you’re working across codebases and especially across teams the process is less than perfectly agile. What we really want is…

14 of 61

Why

Problems to solve

High cost of infrastructure
Painful development cycles

15 of 61

The How

16 of 61

How

17 of 61

How

calcOccupancyForecast {}

JS

18 of 61

How

19 of 61

How

Problems to solve

High cost of infrastructure
Painful development cycles

20 of 61

How

Problems to solve

High cost of infrastructure
Painful development cycles

21 of 61

How

Problems to solve

High cost of infrastructure
Painful development cycles

22 of 61

How

Problems to solve

High cost of infrastructure
Painful development cycles

Offline / Local First

23 of 61

The What

24 of 61

Event Driven Microservices Architecture

25 of 61

Event Driven Microservices Architecture

26 of 61

Event Driven Microservices Architecture

27 of 61

Event Driven Microservices Architecture�Event Sourcing

28 of 61

Event Driven Microservices Architecture�Event Sourcing

I’m going to go through this idea in a little more detail as it’s very relevant to bringing the events into the frontend. So you can see here our log file where logs are being continuously appended as they come in. They are all from the same stream – perhaps a reservations event stream – and we can see three different entities – reservations. Let’s look at the blue one.. there’s a create event and then 3 update events. Perhaps this one they decide they want a bigger room, they add breakfast, etc. Nb the yellow reservation is deleted (or cancelled). But we mustn’t remove events from the log – remember the events in the log are immutable – instead we simply record the cancel event like any other event.

Think of this a bit like an accounting ledger. For each transaction a new line is added to the ledger. If a mistake is made, the line item is not altered, instead a new line item is added that corrects the mistake. Nothing is ever added or removed, the ledger is only added to. Same with the event log.

You know you have an event sourced system when… you have your service that is accepting events and updating it’s state… if you were to blow up that state

29 of 61

Event Driven Microservices Architecture�Event Sourcing

30 of 61

Event Driven Microservices Architecture�Event Sourcing – Key Benefits

Historic state

Debugging

Memory image

31 of 61

What. Events…

32 of 61

What? Events… in the browser

Write JS to create whatever state you like. Interrogate it to create your models on-the-fly.

33 of 61

What

This is obviously potentially huge!

34 of 61

What�Customer Partitioned Event Sourcing

35 of 61

What�Customer Partitioned Event Sourcing

Reservation events log file for Customer A

36 of 61

What�Snapshotting

Reservations event log for Customer A

Beginning of time

37 of 61

What�Snapshotting

38 of 61

What�Snapshotting

Event-Carried State Transfer

39 of 61

What�Snapshotting

Event-Carried State Transfer

40 of 61

What�Snapshotting

41 of 61

What�Snapshotting

Then on Wednesday morning, we’ll take Tuesday’s snapshot and combine it with Tuesday’s events to produce Wednesday’s snapshot. See again how there is only one of each colour.

Over time, the snapshot will become large – and will only ever grow – but it will be much smaller than the entirety of the whole event log. You can choose whatever schedule is most appropriate – here we’re doing it on a daily regimen, but it could be hourly, weekly, yearly, whatever.

This is not a new idea of course, think of our accounting ledger again. At the end of the year we produce an end-of-year statement, a snapshot, which is the culmination of the ledger up until that point. The end of year statement can be used to describe the picture of your accounts. Similarly, our snapshots are a picture of whatever our events describe up until that point.

So… we do daily snapshots and that means…

42 of 61

What�Snapshotting

43 of 61

What

44 of 61

What

45 of 61

What

46 of 61

What

Default VFS

SyncAccessHandle Pool

47 of 61

What

Default VFS

SyncAccessHandle Pool

48 of 61

What

Two big advantages to using OPFS

Persistence

49 of 61

What

Two big advantages to using OPFS

Persistence

50 of 61

What

Two big advantages to using OPFS

Persistence

51 of 61

What

Two big advantages to using OPFS

Persistence
Memory

52 of 61

What

Two big advantages to using OPFS

Persistence
Memory

53 of 61

What

Two big advantages to using OPFS

Persistence
Memory

OPFS is really only limited by the amount of space available on disk and if there isn’t enough space, an exception is thrown that can be caught. We now just need to make sure that we don’t accidently load too much data from the db into memory so we just need to query our data sensibly, paging the results if necessary.

Unfortunately, it’s not quite as nice as that – it’s true that the write into opfs shouldn’t fail if there is enough space on disk but the browser/os will evict data under certain circumstances, including running low on space. That’s a whole other topic but suffice to say that in general, memory concerns are much reduced.

The last general advice to give you is probably a very obvious one. We’ll potentially be doing a lot of processing and we should be doing that off the main thread. And that means…

54 of 61

What

Two big advantages to using OPFS

Persistence
Memory

OPFS is really only limited by the amount of space available on disk and if there isn’t enough space, an exception is thrown that can be caught. We now just need to make sure that we don’t accidently load too much data from the db into memory so we just need to query our data sensibly, paging the results if necessary.

Unfortunately, it’s not quite as nice as that – it’s true that the write into opfs shouldn’t fail if there is enough space on disk but the browser/os will evict data under certain circumstances, including running low on space. That’s a whole other topic but suffice to say that in general, memory concerns are much reduced.

The last general advice to give you is probably a very obvious one. We’ll potentially be doing a lot of processing and we should be doing that off the main thread. And that means…

55 of 61

What

Two big advantages to using OPFS

Persistence
Memory

OPFS is really only limited by the amount of space available on disk and if there isn’t enough space, an exception is thrown that can be caught. We now just need to make sure that we don’t accidently load too much data from the db into memory so we just need to query our data sensibly, paging the results if necessary.

Unfortunately, it’s not quite as nice as that – it’s true that the write into opfs shouldn’t fail if there is enough space on disk but the browser/os will evict data under certain circumstances, including running low on space. That’s a whole other topic but suffice to say that in general, memory concerns are much reduced.

The last general advice to give you is probably a very obvious one. We’ll potentially be doing a lot of processing and we should be doing that off the main thread. And that means…

56 of 61

What

Do fetching and processing inside web workers

57 of 61

What

Do fetching and processing inside web workers

58 of 61

What

Do fetching and processing inside web workers

59 of 61

Final thoughts

Poor experience for some users
Security concerns
Mobile networks and devices

60 of 61

Final thoughts

Very efficient use of resources
Empowers frontend devs to do more
Huge benefit to explorative development leading to better products

61 of 61

Event Driven Frontends

WHAT, WHY & HOW

Matthew Cox

Software Engineer with

linkedin.com/in/matthewcoxlondon�

@matt-matters.bsky.social