AstonJ
Functional Web Development with Elixir, OTP, and Phoenix (Pragprog)
by Lance Halvorsen
Elixir and Phoenix are generating tremendous excitement as an unbeatable platform for building modern web applications. Make the most of them as you build a stateful web app with Elixir and OTP. Model domain entities without an ORM or a database. Manage server state and keep your code clean with OTP Behaviours. Layer on a Phoenix web interface without coupling it to the business logic. Open doors to powerful new techniques that will get you thinking about web development in fundamentally new ways.
Don’t forget you can get 35% off the ebook using the code ‘devtalk.com’ ![]()
Can’t wait ![]()
Most Liked
redrapids
This is a very good post. This is why I love the Elixir community.
Lance and I are working with some great reviewers to make sure we address this feedback. We’re going to shift the approach for the two chapters in question, the chapter on modeling and the chapter on wrapping the result in OTP.
As a popular book in the community, we want to make sure that the guidance we give is sound.
Thanks again for a great post.
lance
Thanks for the hat-tip! I’m beyond excited for the beta launch. ![]()
mjadczak
I grabbed the book and had a (virtual) leaf through, and I would have two main comments:
First, perhaps I didn’t read the book page properly, but I had the impression going in that this was going to be much more advanced than it was. The PragProg page shows the skill level as “intermediate to expert”, and while I agree that it is not a beginner book, I would not call it expert-level either. By “have previous experience with Phoenix and Elixir” I took “have built complete, if maybe simple, applications with them” rather than “know how the syntax works and how a Phoenix interface is structured”. I think clarifying exactly the target audience of the book may be beneficial.
Second, I take issue with the way that the entire game state is represented in a bunch of processes referring to each other by holding PIDs. I think the best way to say what I mean is to simply refer to this great article by Saša Jurić. The way this is implemented in the book smells really strongly of trying to make Agents behave like objects, which is a common mistake for those moving over from OOP, but should in fact be explicitly called out in a book like this, instead of impliedly encouraged.
I think at a certain point you mentioned that “trying to store the whole game state in a functional tree structure is a recipe for bugs because coordinates can belong to both islands and board and we’d have to update them in both places”. The answer to that problem is to normalise the way you’re storing the coordinate data, so you’re only storing it once. It’s certainly not to make each little piece of your state be a separate process!
As has been discussed many times over on this forum, separate processes should be used when a separate concern, either separate in time or separate in failure domain, is present.
Further, what happens when these processes die? They are all linked it seems, so one failure will take down the entire system. If you insist on using them to model the state, perhaps it is at least an opportune time to put them into a custom Supervisor and use Registry to register them with the coordinate/board they represent?
I’m sure it is not the intention of the book to do so, but while I applaud the decoupled, “Phoenix is not your app” approach, I feel it either itself falls or encourages people to fall into common traps when structuring Elixir apps and modelling their domains therein.
I don’t mean to be too negative—I think the concept of the book is great, and a practical walkthrough of how to build something fun but useful is a great way to convey the concepts, but I also think it’s crucial that the approaches set by the book are 100% defensible (to avoid saying “right”) and push people towards actually using the great many tools Elixir gives us in the way they were designed to be used.
Popular in Books
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









