dcchuck

Thank you for the clarification

I agree!

I picked up [RetroPie](https://retropie.org.uk/) again during the pandemic. I'm sure many did the same haha.

That's when I learned [N64 emulation is difficult](https://retropie.org.uk/docs/Optimization-for-Nintendo-64/).

Well done.

Looking forward to reading this, thanks for putting it on my radar.

I really enjoyed Masters of Doom - which has been discussed here plenty on HN - https://hn.algolia.com/?q=masters+of+doom

Simplest terms - your app needs several different services or instances of a service to agree upon a value. There are a lot of reasons you can't use things like the system clock to agree upon when something happened for example - this is where RAFT steps in.

You'll see "fault-tolerant" and "replicated state machines" often alongside them. Let's break those down in this context.

For "fault-tolerance" - think production environments where I need to plan for hardware failure. If one of my services goes down, I want to be able to continue operating - so we run a few copies of the app, and when one goes down, another operating instance will step up.

In that case - how do we pick what's in charge? How do all copies agree on things while everything is working smoothly? Raft.

For "replicated state machines" - let's stay in this world of fault-tolerance, where we have multiple instances of our app running. In each service, could reside a state machine. The state machine promises to take any ordered series of events, and always arrive at the same value. Meaning - if all of our instances get the same events in the same order, they will all have the same state. Determinism.

This is where it all comes together, and why I think the jargon becomes tightly coupled to an "easy to understand" definition.

You will reach for replicated state machines when you need deterministic state across multiple service instances. But the replicated state machines need a way to agree on order and messages received. That's the contract - if you give everything all the messages in the same order, everything will be in the same state.

But how do we agree on order? How do we agree on what messages were actually received? Just because "Client A" sends a messages "1", and "2', in a specific order does not guaranteed it is delivered at all, let alone in that order.

Raft creates "consensus" around these values. It allows the copies to settle on which messages were actually received and when.

So, you could use other approaches to manage "all your service copies getting along" but a replicated state machine is a nice approach. That replicated state machine architecture needs some way to agree on order, and Raft is a great choice for that.

It is interesting to see things that were part of your youth be revised - I say this to offer no firm opinion, just express curiosity.

Does anyone know of a place on the web documenting these changes? Or how I can best tell when the video I'm watching was last modified?

Thanks for sharing

React Router moved to contexts some number of versions ago...as I look into libraries for React, I see most leveraging Contexts. I've had success with it over the past year and appreciate your affirmation

Other poster here -

Success with MobX on a project. I worked as lead picking up an existing code base - none of us had any MobX experience so came in fresh.

My employer was kind enough to offer up FrontendMasters subscriptions - I watched a MobX course there over a couple of nights - link: https://frontendmasters.com/courses/redux-mobx/

I enjoyed it! Got the job done, no scaling issues

This looks great, I am excited to take it for a spin.

I really enjoyed your "Why the Book is Free" section.

Perusing with the same feelings

Funny how the prices haven't changed much (seeing a "new computer" for $1,995), given the change in computing power and purchasing power (of the dollar)

Thank you for sharing.

My guess for #8 - The dog wants you to put on your shoes and take him for a walk.