Thanks @jaimeiniesta! Glad you’re enjoying the book. 
We will cover data persistence for disaster recovery, but we haven’t quite gotten there yet. Stay tuned. 
I would also add that you can hold a surprising number of processes in memory on the BEAM. At work we routinely and comfortably run 800,000 processes on a single node.
Awesome! On a single node with how much memory? It’s not the number of processes that worries me, but the total memory used 
- but well of course this depends on how much data you put into each process, results will vary a lot.
Each process is .5kb
Yes, but then you have to add the memory used for the data held within each process. In the case of the app in that book, it would be the data for each Islands game.
But then let’s say you implement a Blog server where every user, post, comment, is held into memory at once - how much data is this going to need? Can we afford it or should we implement a way to unload selectively processes from memory?
I’ve expressed this in the context of my own app in this other thread, but it would apply to any real-world example. For example, this forum, can we hold all of its topics, comments, users, etc., entirely in RAM?
It’s an AWS instance with 30 gigs of ram. If ram usage is a concern - and depending entirely on your use case - you might want to investigate the optional hibernate and/or terminate elements for :gen_server return tuples. We currently don’t use either, but if ram usage becomes an issue, we will.
A quick note to tell beta 5 is out now 
Just wanted to say thanks this thread got me to finally buy some Elixir books, so cheers and keep up the good work
Thanks! And best of luck. I hope you have a great experience with Elixir and all the books you’ve bought!
Im really liking how this book is structured. It gave me a different view on how to approach an elixir/phoenix project. It has been a great read so far!
Thanks! Glad you’re enjoying the book. <3 <3 <3
I’d forgotten I bought this already 
had an email saying it’s been updated:
Changes in This Release
Added “Process Supervision For Recovery”
Addressed errata
Does anyone know if Ecto or persistence is going to be covered in the book?
Just read “Mapping Our Route” looks great! Glad to see so much literature regarding elixir is well written and not so dry and boring as what I am more accustomed to (specifically java/c++ books). Thanks for the hard work, will definitely be purchasing a copy.
We don’t cover Ecto, but we do talk about techniques for persisting state - and getting it back again after a crash.
Thank you! We’re almost there!
First off, thank you Lance, you did a great job!
Your book really expanded my understanding of how to use OTP behaviors such as gen_server and also Phoenix channels and presence.
After reading the book, I have a question. Does the design used for the Islands game lend itself to apps that focus mostly on CRUD operations? I think I could model the actions of creating, viewing, updating, and deleting database records with a functional state machine, but using a channel to send messages back and forth when there is only one client seems like overkill. Perhaps CRUD is the killer app for the stateless HTTP protocol?
Does Lance’s design really only make sense (in the context of a CRUD app) if you need to have multiple clients simultaneously updating data, e.g. a pair-programming text editor?
Hi Jason,
Glad you liked the book!
I’m not sure that CRUD vs non-CRUD is the most interesting distinction here. It seems to me that stateful vs. stateless will get us farther. We can assume that stateless means we’ll be writing working state to the database and then retrieving it for each request.
Most applications of any size or complexity have a number of elements that might lend themselves to either a stateful or a stateless approach.
We can certainly mix and match these different approaches within the same application, using each where it seems most natural. We can mix and match MVC style components and Channels in the same application as well, depending on the need.
With that in mind, the more interesting exercise to me is examining the domain and determining which approaches to use where. A twist to this is to think about why we might choose the stateless approach in a given situation. Is statelessness inherent to the domain element, or are we choosing it based on our previous experience and familiarity?
I don’t know that there are general answers for these questions. So much depends on circumstance and the particulars of the domain.
The fun part is that Elixir, OTP, and Phoenix give us the tools to experiment more easily with the statefull approach so we can learn more about how and when to use it.
For those who have gone through the book, I took the React frontend example code and rewrote it in Vue. I didn’t have any experience with Vue before starting, so I’m sure there are many areas it could be improved. However, here is a link to the assets folder on Github if anyone is interested.
The book is awesome for anyone who is thinking about purchasing it!
Once again, awesome book! Best book out right now IMHO on web development with elixir and phoenix!
© Copyright Elixir Forum | Terms | Privacy & Cookies
