small medium large xlarge

10 Apr 2017, 06:16
John Shea (7 posts)

On page 3 we are introduced to architecture that is to be used:

“In Part One we’ll begin by building a stateful game server in pure Elixir. We won’t use a database to store the game state, and we’ll define our domain elements with native Elixir data structures instead of ORM models. We’ll maintain state with Elixir Agents, and we’ll wrap those agents up in a GenServer to provide a consistent interface to the game.”

My (newbie) question is - wont there be state that will need to be maintained (e.g. scores, game options, users) and wont this state be lost (given that its all in memory) between server restarts, deployments, redeployments, crashes? Or is there some way to re-initialise saved state (e.g. from S3) after crashing or redeploying? Thanks.

10 Apr 2017, 15:14
Lance Halvorsen (28 posts)

This is a good question.

Yes, we will talk about restoring state after a restart or a crash in Chapter 6. The big difference is that we will only use persistence for recovery, not for working application state.

10 Apr 2017, 23:35
John Shea (7 posts)

Excellent - I’m looking forward to it.

11 Apr 2017, 23:40
Matthew Potter (6 posts)

So while the book may handle this particular project’s recovery after a crash, there’s a lot of way to deal with persistence.

For deployments, there’s the code_change (blue/green style uptime is basically a feature built into the language):

You basically never need to take down a server when doing deployments, you simply upgrade the current state. This works through the @vsn attribute, which allows you to version your data over time. If the state fails to update, the whole deployment rolls back. It’s a pretty rad feature.

and if you want to look into handling genserver crashes, there’s the terminate callback, wherein you could handle state in a variety of ways. For example, pass off a crashed genserver’s state to a new process.

05 May 2017, 07:38
John T Baylor (1 post)

Lance, I love the book - rolling over concepts as I read it. And I just realized a misconception I had that was distracting me as I read it.

[disclaimer: I’m still looking at the first version so you may have addressed this already]

I couldn’t understand why you were designing “Coordinates” as your building blocks and not the standard board-game noun of “Squares”. It wasn’t until I skimmed forward and back that I found what I had missed. I missed your original decomposition of the problem. I would decompose it as: two players have two Boards and each board has NxN Squares. What I missed was that you had taken it one step farther to: … And each Square has a Coordinate that only knows where it is, whether it has trees, etc. There are probably good reasons to go to that level - but I’m missing them right now.

If you think others would have a similar misconception then consider a short, explicit statement of how you’re designing the overall building - and then build the Coordinates.

Looking forward to the rest, @JohnB

06 May 2017, 22:00
Lance Halvorsen (28 posts)

Hi John, glad you’re enjoying the book!

I’ll still call them coordinates in the new version, but I think the lead up to defining the domain entities will clarify what we’re talking about.

You must be logged in to comment