I will be at Code BEAM Berlin where I will do what I think is our first live episode of BEAM Radio. It will be a short and tight 30 minutes with .. oh you know .. Saša Jurić and José Valim.

The topic is about Fully Utilizing the BEAM and I hope to pick their respective brains for what they believe we in the community should be looking at to further take advantage of our rather unique runtime.

If you will be in Berlin, come up, say hi. I love to meet new people in the community.

Filling in Context

I've had the pleasure of talking to Zach Daniel of Ash Framework fame about what his framework is for and why he believes it is needed. And I fundamentally agree with the problem he is trying to solve. I am hopeful that his solution is good and if it is I think it will fill an important hole. This is something I want to explore. But since I've only scratched the surface of Ash. Let's speculate.

I really like Phoenix. If I could make some edits to it I might drop Views entirely, I feel like they are just a layer of indirection but then again they give an insertion point for utilities. So maybe they serve a purpose. I've seen argued for "fat" controllers to provide all the detail the developer needs in the controller. I've also seen it argued that the much-discussed concept of "contexts" just needs a bit more lovely layering to get things done right. I've covered this on the blog. And I believe we went into it when Saša was on BEAM Radio.

Anyway. Whether using Controllers, Channels or LiveViews as your external interface you typically use Ecto as your data layer. Between your external interface and this data layer you need to do a bunch of things. Validating inputs, triggering side-effects, constructing additional pylons, ordering food, wrangling data, probably some authorization and access control. Then finally you poke the data layer with a carefully constructed query.

This is the zone that contexts are supposed to cover. But they are modules with functions in them. There is no API, there is no opinion, there is no guidance. I kind of like that. I'm used to forging my own path but I also often make a bit of a mess in that process and then there is a bunch of after-the-fact rigor that needs to be introduced for maintainabilty. And this is what Zach argues that we should stop reinventing for every new code base. Your interface will always need authentication (authn) and authorization (authz). Multi-tenancy should not be an afterthought if you have customer data to keep separated.

Ash wraps up more than just the inbetween layer but it is with the purpose of filling out that middle. Deriving a JSON API, a GraphQL API and all that kind of sweetens the deal. I was hoping they had deriving of UI for admin and such. They don't quite. They have a generator for LiveView which is a very good start I imagine but not quite what I had hoped in that regard.

I think many developers will look at Ash and go "this is way too much stuff". And also, "this is way too much to learn". My early exploration says that it is DSL city. Just DSLs upon DSLs for different purposes to learn. The terms seem fairly well chosen. Resources, Actions and so on. As someone who likes writing Elixir this is all mostly modelling with do-blocks. But I've modelled many systems on paper and then sworn that I can't derive most of it from the Ecto schema. I've done Django. Getting stuff for free is incredibly convenient.

The thing is, even if feels too much it is probably about the right amount of stuff. Eventually all apps need a concept for how to apply access policy, all apps need some abstraction for how data is loaded. I've heard GraphQL optimization with DataLoader gets to be a bit nightmarish and supposedly Ash takes care of it for you.

If you've ever tried to teach inexperienced devs how to do Elixir and Phoenix, the space between the Controller and Ecto is the space where weird things happen and confusion strikes. There are no guard rails there. Even if Ash is a lot to take in I'm pretty sure it provides structure that eliminates a lot of confusion.

I think the framework has been accused of magic and Zach was very careful in our conversation to say that there is no magic. I would perhaps call it mystery. With DSLs and macros of this level there ends up being enough layers of indirection that it is non-trivial to peek under the hood. And I get how that makes people suspicious and hesitant. Ash does seem to try and be very explicit about what you are doing so that while things are abstracted away, they aren't quite so mysterious.

I am very curious to see if I feel like this can actually fill that space. If it is a path that will see increasing adoption in the ecosystem. Zach said it was fairly polarizing in that people either really like it or really don't and I can see why. It feels a bit daunting but I'm also quite excited to poke it more. I'm also curious to experiment with their DSL tooling and see how hard a DSL for simple UI would be. Of course I don't have time to truly do it. But I wanna.

I don't know what other options out there are trying to tackle this really. There are libraries for many different parts. There are frameworks for other paradigms, like commanded. But Ash seems to stay pretty vanilla Phoenix in this regard and I do think we'd benefit from people not needing to reinvent these patterns.

What is your perspective on Ash? Too many macros? Not enough magic? You can reply to this email or poke me on the fedi @lawik@fosstodon.org.

Thanks for reading. I appreciate your attention.