A toy project in a non-toy framework. Observe my journey as a Phoenix veteran trying out Ash for the first time

Looking forward to seeing how this goes! It will be a win win for Ash no matter what your results end up being, since we’ll have the context and areas to improve!

To be fair, @zachdaniel has always been amenable to collaboration and we’ve discussed it before. I took an action to drive the next step and then real life got in the way. I hope now the timing is better for all concerned.

I actually do like declarative stuff and I’m big on DDD and Ash has always looked good to me (I’ve read through a lot of the docs) but I still haven’t tried it. I watched the talk last night and it got me a bit more excited again, especially when I saw code that looked my code that I’m generally really happy with and was told it could still be better

With some reflection there are few reasons I still haven’t tried it:

• I started a greenfield project at new job and it’s a bit stressful so I didn’t want to dive into anything new.
• Sunk Cost Fallacy: I really started hitting my stride with Phoenix last year developing a style I’m really happy with and barely had any time to revel in that sweet feeling of confidence when I learned about Ash
• A possible/probable unfounded fear of being too far removed from the concepts I’ve grown to love, mainly learning another query abstraction on top of Ecto.

In any event, I look forward to this, and the workout focus of this could do me some good too

Btw, I love your presentation style @zachdaniel! I can’t put my finger on it but you held my attention the entire talk.

This could be double interesting if OP makes sure to have some sort of milestones – e.g. GitHub releases – with traceable steps and not a huge number of commits / diffs in-between, so any onlookers can retrace his steps and see the meaningful changes step by step.

(Or, as a good CTO already knows – – to make sure commits/PRs are more or less atomic.)

I have been tempted by Ash for at least a year but health and real life are constantly in the way so this would be a very welcome opportunity to observe passively every now and then.

So – good luck! Interested in the journey.

Part 2!

I rounded off with how weird it was to start with mix new and a supervisor tree. Apparently that feeling of weirdness was correct, because the guides for AshPhoenix says to start with a mix phx.new indeed I thought it was a bit weird that Ash hid and abstracted that much. This guide: Get Started with Ash and Phoenix — ash_phoenix v2.3.23 for those who are curious.

So: I have now done more due dilligence and read more than just the core Ash and Auth0 guides. The guide for AshPhoenix feels a lot more at home to me since I know Phoenix very well. I do wonder why Ash has such a hangup on using uuids. I am not a big fan of using uuids. If you need something opaque for the end user that isn’t a digit (like you don’t want to show your fancy new customer you just sold your software to that his company has a PK of 3) I have had great success with using ints internally and just displaying them externally with a HashedInt (hashids | Hex). Uuids has their place, like if you have needs where PKs needs to be generated outside your app and still come in with somewhat collision free guarantees etc but the downsides of uuids in postgres are pretty big imo. Clunky to work with when writing queries and it takes away some benefits of stable sorting etc. See running list of questions at the end.

The liveview usage segment intrigues me a bit, I do find typing out all the changeset blabla boilerplate in my service modules (context modules for you who like that nomenclature) to be a bit tedious, so I like that that is all taken care of. Including all the form helper stuff from lv 0.18+.

I am ready and I upgrade phoenix installer to the newest, do a mix phx.new growth (perfect name for a muscle building app) and immediately go in to sort the deps alphabetically before adding the ash ones. Gotta have the house in order, right???

I wondered why ash wants me to use their create repo command but realize now that it is so the extension installer can run. Not sure I am a big fan of that. It should just be emitted by the migration generators. It’s not like I’ll be running ash create against a prod instance anyways, so now I have to manually remember to fix that before I deploy this.

Also, the formatter documentation is out of date (told Zach on slack) as a default mix phx.new includes the html formatter plugin now and the example at Get Started with Ash and Phoenix — ash_phoenix v2.3.23 does not show it. Some newbs might be missing out on the awesomeness due to this, so beware (Ok before I had time to mix deps.get and set up my Repo file, zach has already pushed a fix for this that will be include in next release, not bad!)

Repo is now set up and I am ready to start specifying my domain. One of the very few things I dislike (a lot) about the phoenix generators is that I think the Context design they produce is promoting sloppy modules. I think it is many orders of magnitude better than when noobs put all their business logic in the controller, but if you generate a couple of schemas you end up with a 800 loc context that is hard to navigate. I have been mandating a pattern of FooSchema (preferably anemic, no code that is not around validation, and no external module calls) coupled with a FooService. FooService deals only with Foo, or in some special cases maybe FooCloseRelative. Think User and UserRole. Any cross-domain communication should be done with a service talking to a service.

Ash resources are anything but anemic, but each section of the resource promotes a clean and anemic-style definition set. It also means that a Registry stays very terse and you never end up with the gazillion-LOC contexts that a generator based phoenix app gives you.

I set the default config required and map up a Growth.Workout registry. I start to map my first entity and I hit the first uuid-snag. I don’t want an uuid, I want an integer. I think the docs here should either showcase both side-by-side or at least have a documentation link directly to the attributes. I had to go hunting in the docs to find how to specify an integer. The doc search shows no results on “primary_key” (I would expect it to at least show the already existing “uuid_primary_key”, but no). I did find “integer_primary_key” by searching for the uuid one and clicking through. Ash is an elixir library after all, so as expected the docs are clear and informative when I just find the right spot

It is time for me to run mix ash_postgres.create to see what all the fuzz is about! … aaand drumroll wut?

image714×136 24 KB

Anyways, at this point I realize that I should probably put in place the user system before I start mapping up too much of the programs and stuff because almost everything I want to model up is tied to the user. So I have now pushed up an initial commit at GitHub - omt-tech/growth · GitHub including my first api + resource and I plan to swap over to the User work to be able to log in with Auth0 tomorrow or the day after.

If my text seems jumbled it’s because I have been writing it on and off throughout the day, my lil six month old girl Ellinor does not find coding as exciting as I do apparently.

Questions (for @zachdaniel or whomever else wants to chip in):

1. Why so much uuid defaulting?
2. Are my assumptions about why to use ash create wrong? Did I find a bug around the extensions?

Great stuff!

UUIDs

UUID is mostly just a sane starting point, but you can use your own primary keys as well:

attribute :foo, YourType do
  primary_key? true
end

EDIT: one thing to keep in mind is that generated belongs_to attributes default to :uuid. You will get a warning at compile time if you try to do something like have a belongs_to relationship from a :uuid type to an :integer type, but basically for compilation-related reasons, we can’t magically assume the type of a belongs_to relationships source attribute to be the type of the field it refers to. So we just default to :uuid. You can configure the default here:

config :ash, :default_belongs_to_type, :integer

and read more about it here: Relationships — ash v3.29.3

ash_postgres.create

mix ash_postgres.create is a thin wrapper around mix ecto.create that finds the repos to use by looking at all the repos in use by your app. The migration generation happens when you do mix ash_postgres.generate_migrations.

With that said, we’ve got the work done and will be pushing some new mix tasks across the documentation, that automatically pick up what extensions you have and run any corresponding tasks. They are like built-in aliases with extra features.

In the context of ash_postgres (the only one who has implemented the hooks for these new tasks) you have:
mix ash.setup - creates your db
mix ash.codegen - generates migrations
mix ash.migrate - runs migrations
mix ash.tear_down - drops your db

Nice, I subscribed to the repo’s PRs and releases. Also left you a comment on the 2nd commit.

this is great stuff - have had a keen eye on Ash for ages - but pragmatism/lack of time/risk aversion always end up postponing the dive in..

You cant introspect the primary key of the remote schema at compile time?

We can, but not in such a way that we can modify the current module (without inducing compile time dependencies that could result in deadlocks). So instead we check at compile time and validate using a compiler step that happens after modules have been compiled (after_verify).

Even if we could, if you were do do something like this (don’t):

belongs_to :foo, Foo
belongs_to :bar, Bar do
  source_attribute :foo_id
  define_attribute? false
end

where the attribute on Foo is a string and the attribute on Bar is a uuid. This is valid in some cases (pretty sure not with postgres, though).