If you’re reading this, you must be wondering if this is some sort of a click-bait. Why on earth would someone mix React, Redux, Go and Webassembly? Well, I’ll tell you!

Introduction

I’ve been using Redux for a few years on my React projects, and for a couple of years, I’ve been interested in event-sourcing and Domain Driven Design (DDD). While those two things appear to be unrelated, they’re actually quite similar.

I want to use the same functions to calculate state in both backend and frontend. Both systems are event-based and if I can handle those event the same way, I don’t have to contact the backend for validation.

What we’re building

Enough with TODO apps, and Hacker News clones. Let’s build a simple booking system.

Functional Requirements

We’re solving booking for the city’s top hair-stylist. Hairford Magnifico!

• Customer can book a service-slot
• Customer can not book a service-slot outside of opening hours (hardcoded)
• Customer can not book a service-slot if it is already booked
• Customer can not book a service-slot in the past

Preperation

Install Git, Node.js and Go.

Basics:

mkdir magnifico-booking
cd magnifico-booking
git init

Backend

Backend:

go mod init magnifico-booking/backend

Frontend

Frontend:

npm install -g create-react-app
create-react-app frontend

Get to the point already (MAYBE)

Redux frontends and Event-Sourced backends have a thing in common. Reducers.

A common pain-point in event-driven systems is that the read-model is eventually consistent. You can’t write, and then read the data right away without first knowing if the read-model has been updated.

If you’ve ever seen a checkbox get checked, and then unchecked after a few milliseconds, then you’ve seen a guess-work gone wrong. But, we don’t need to guess. We can compile our business-logic from Go to WASM and then use it as a reducer on the frontend.

That way, the chances of the post-operation data looking the same on the frontend and backend go up somewhat.