Wanted to go ahead and kick off the book club for Ash Framework: Create Declarative Elixir Web Apps. I had hoped to get through more of it myself before starting, but … life. Rather than waiting for the ever-receding “good time to do it” I wanted to start talking about the book now at least in part because the Ash Weekly newsletter announced that there will be an AMA on DevTalk tomorrow and the next day with @zachdaniel and @sevenseacat. I also wanted to have the discussion going in case anyone is headed to CodeBeam for the Supercharge Your Elixir Apps with Ash training session on March 5 and wanted to get a head start.
Of course everyone is welcome and I hope more folks will participate.
I’m going to throw out some initial broad thoughts to maybe get the ball rolling a little bit. I have never attempted to use Ash before but have been intrigued by it since it was announced as a project. The online documentation and helpfulness of the developers across a variety of platforms have been really impressive. I would say the book is an extension of that ethos. One tip, if you see a call out in the book clearly marked as important with a bright orange exclamation point in 44 point bold font next to a header that begins with “Don’t forget…” you should pay attention to that information. Ask me how I know.
Welcome everyone, can’t wait to read your thoughts!
I hope everyone’s had a chance to get started on the book. My real life has been very hectic so I haven’t quite finished. I think this is a book most people could get through in 3 days if they had the time to commit to it. Alas, I think we’re all probably pretty busy.
Anyway, just thought I’d share some thoughts on the first chapter. The writing style is clear and personable. Because I so rarely have to do anything with postgres anytime I do a book like this the hardest part is the setup where I have relearn all the database stuff. Other than that the first chapter was pretty effortless.
I really feel like Igniter strikes a great balance of being magical but also printing everything to the terminal so you know what is actually happening. The messages and warnings are very explicit, which is so nice.
The book does a nice job of introducing the concepts of domains and resources, terms which for trained devs are probably obvious but for someone self-taught are a bit opaque. This is clearly wrong, but my intuitive model of Domain:Resources is something like Parent:Sibling classes. So the example Tunez app has a Music domain with resources of Album, Artist, and Track. Everything an instance of an Artist, Album, or Track shares comes from being in the Music domain. While Album, Artist, and Track clearly relate to one another, each also have independent functionality. I wonder if anyone has a more accurate interpretation.
My final takeaway from chapter 1 was just how easy Ash makes the initial setup for a project. It really does exactly as advertised. You get to concentrate on the logic and ideas behind your project while Ash handles a large portion of the implementation. Unlike an agentic tool, however, Ash is not a black box so you can always see how and why it did what it did for you.
Looking forward to hearing everyone else’s experience with the book and Ash in general.
I went through the book some days ago and jumped straight to a fairly big project I wanted to do for some time. I have the book constantly open and jump back to it every time I need to do something. It’s helping me a lot to retain the info together with the docs.
Ash has a ton of stuff and the book is great to get a fast overview of how things work together so you can get started. Now I dived into multi-tenancy which the book does not cover (and the docs are not super deep either). I found way more help for that on the forum here.
Overall it’s quite enjoyable to work with, I like the book a lot and I can’t wait for the new chapter.
The policies on the action by default only allow AshAuthentication to call them. If you want to allow signing in over the API, you’d need to add a policy allowing it.
GraphQL always responds with 200 (not something we can do anything about).
Sorry this thread hasn’t really taken off. I’m surprised because the volume of Ash-related threads and the general interest in this book seems high. Unfortunately my life is very hectic at the moment – my wife has COVID, my daughter has mental health issues, my dog is dying of kidney failure, and my real job responsibilities are growing exponentially. I’m afraid I probably won’t have as much time to devote to shepherding this thread as I had hoped for a while. I do think the book is fantastic and the folks behind Ash are incredibly generous with their time and expertise. Hopefully this thread will organically grow as people go through the book, though perhaps the lack of discussion is actually a testament to how well done it is. If everything in the book is self-explanatory not much room for discussion I guess.
No need to apologize! I’ve been skimming through the book more than reading it page by page so I feel guilty starting the discussions in this thread. I’ll try to revisit chapter 1 this week or next so maybe I can add a few talking points.
Appreciate you starting the effort to begin with! Life gets rough so hopefully this doesn’t add to the stress. The thread will always be here and I feel like multiple reads of a book are helpful so maybe we can do a few rounds of reading through the book
Just thought we’d mention that Rebecca Le will be presenting at the upcoming Elixir Sydney online meetup tomorrow about writing the book and there’s a special offer to attendees.
Sorry to hear you’re going through heck, @stevensonmt, hoping things ease up soon.
I finally bought this book today and went through chapter 1. I had already started developing an app in Ash and was already familiar with most of the concepts but it really helped solidify them as it’s explained a little better than in the docs. Or at least, in a better linear way than the docs. For instance, it really hit home how the :get_by option in code interfaces works. From the docs I understood that :read always works on collections. Adding the :get_by option seemed almost arbitrary and I was struggling to figure out the reasoning as to why this API was chosen. It was the book that described it as a filter which makes a ton of sense. I’m not sure the docs actually describe it this way but I’ll open a PR to add it if I can’t find it.
Another thing of note is that I love love love the AshPhoenix.Form API (well, except where you do to_form(form)… that is a little weird ). It’s of course following “describe your domain, derive the rest” but I specifically like how it even calls effectful functions for us with AshPhoenix.Form.submit.
One thing I don’t love is AshPhoenix.Extension, ie, form_to_. What I would prefer—and I feel like this was probably considered and abandon—is if AshPhoenix.Form.for_create and friends could also take a Domain + function combo as opposed to just Resource + action. I feel like this would make it more consistent with how forms are otherwise used and that for_create(Tunez.Music, :create_artist) is less confusing than a form_to_ prefixed function seemingly coming out of nowhere. But form_to_ isn’t terrible as it’s something you use so often that it would be hard to forget what it means.
I didn’t say it was strange, just not as clear as the resource version. I feel roughly the same about the can_ ones. But again, it’s by no means terrible and easy to get used to.
Ultimately what we’ve found in practice with really large applications is that it can become really hard to track down action invocations when they use the format SomeMod.some_fun(Resource, :action). Refactorability is pretty high on the priority list, so form_to_ was added to make sure that you could always track down where something was being used, including in forms. If you were to remove or rename the action and code interface, you’d get a compile warning for using an unknown function, whereas you’d have to hunt down atoms using AshPhoenix.Form.for_create(...). Doesn’t change the fact that it can feel kind of strange to do it but that is the original rationale for the addition.
Oh ya ok I see, that’s a very good reason, then! Again, I don’t really mind it… I dunno, I guess @FlyingNoodle was right, I am saying I found it strange It’s definitely strange having the domain layer send you a form struct but it all makes sense with how Ash is designed and just takes some (slight) getting used to.
). It’s of course following “describe your domain, derive the rest” but I specifically like how it even calls effectful functions for us with 
but that is the original rationale for the addition.
It’s definitely strange having the domain layer send you a form struct but it all makes sense with how Ash is designed and just takes some (slight) getting used to.
