Ash Community Updates

Ash Forum Ash News
,
1

Hello everyone!

We’ve got two big updates on the Ash community today :tada:

Discord Support Forum → Elixir Forum

The Ash community is growing (faster every day) and ultimately we’ve decided that our discord support forum is too closed off. It’s not searchable online, and ultimately is just not very accessible to people for various different reasons. We evaluated our options for a while, and have landed on ElixirForum as the (perhaps obvious) answer to those issues. It took us a while to make this choice because we wanted to make sure that it was in the best interest to our community.

So what does this mean? The Ash discord will remain, and will be a place for socialization and for getting help. What we currently do is that, when a question seems to clearly be an “I need help” type question, we route people to our support forum on discord. In the next few days, that discord channel will be archived (but not deleted), and we will instead direct users to make posts here. We will likely set up a bot monitoring for new posts and posting to discord as well, so users who prefer to hang out there, but want to know when new Ash posts happen here will be able to do so.

Additionally, we are evaluating options around importing our discord’s support forum history into elixir forum. We already have that data as we’ve been synhchronizing it to the website, so it should not be too difficult to do. However, we are going to try it out on a clean copy of discourse locally and see if we can actually make it legible and ultimately make it worth doing. If not, we’ll find another way to put that history up on the internet somewhere it won’t be lost.

AshHq → HexDocs

I intend to do some more writing about this in the future. We learned a lot in the process of building https://ash-hq.org as effectively a mirror of all of the various hex packages in the Ash ecosystem. Ultimately, we’ve decided that certain aspects of it are doing more harm than good. The cross-package search can be very useful, but it’s not always intuitive, and users are already very familiar with HexDocs. To that end, we’re reworking the way that AshHq works. Our guides will remain available on the site, as they are good introductory material for those first encountering Ash. However, our cross package search will instead route you to HexDocs for everything other than the guides. We’ve done a first pass at cleaning up the HexDocs for each package, and part of this involved finding a good way to document DSLs in hex. Ultimately we’e landed on something that we think is good enough to make the switch, but we will be iterating on it over time. Here is an example: DSL: Ash.Api.Dsl — ash v2.21.5

Better Together

Ultimately, our community has been relatively closed off from the rest of the community in some ways. This was not intentional, merely a byproduct of us wanting to make sure that our users had the best experience possible. It is our hope that both of these steps will make Ash more accessible in general and allow a greater audience to participate, and also let our current user base benefit from not being quite so tucked away in our own little corner.

I’m happy to answer any questions or address any concerns, please let me know if you have any!

62 Likes
2

While I totally can understand the point of maximizing DX, I also learned over the decades that the seamless integration of new approaches into existing landscapes will make or break it. There are breakout successes, true, but by and large the seamless interop/integration story is more important than the actual thing itself, just my 2c.

And definitely a huge thumbs-up for you going a few steps towards that path - once I can frictionless try this out for a few parts of my existing phoenix platforms without too much wiring or moving parts that stand out in odd ways, I’d definitely give it a shot!

1 Like
3

One of the things with Ash is that you can just start using it for any of your application resources on a progressive basis and seamlessly coexist with all your existing non ash code.

The Ash approach to surfacing resource actions to what they call an “Api” is akin to a phoneix context, so it’s easy to just target some resource in your application and try it out.

I really do enjoy expressing my domain model and getting so much value for such little effort, at first it feels like cheating and like many others, I can’t imagine doing it the long the way.

Question: Do you test the phoenix framework in your apps, or do you focus on testing for the code you write?

Question: what if you are writing far less code because you are using a DSL that does compile time checks and leverages a framework. Would you write tests to test the framework or focus on the just the code you write leaving more time for UI and end to end testing?

Once it clicks in your head, Ash does save a lot of “busy work” and low value drudgery, leaving more time for more important higher value outcomes. Like all things it does have some rough edges, but what doesn’t in open source? The important thing is that is works and is moving in the right direction with better documentation.

I think one of the understated cool things in Ash is the handling of nested resources via AshPhoenix.Form in liveviews. It eliviates many problems of the impedance mismatch between interactive forms and changesets which you can read all the glory details here. It’s a really good post on what you have to do to make a form with one to many work properly.

4 Likes
5

I love that LiveView form blog post, but as an Ash user I just had to demo the example using AshPhoenix.Form. Check it out here GitHub - totaltrash/form_example

4 Likes
6

@dblack that is probably worth a post on its own run the showcase tag :slight_smile:

1 Like
7

That’s an excellent post @dblack and really shows how the tagline of Ash is realized.

With the new Ash liveview generator, even the index, form and show components will be drafted. The index/lists are also fully streamed with pagination supported in the domain model.

But what was most amazing is the Ash Phoenix integration also ensures every liveview state is truely live with what’s committed in the data layer using pubsub notifications based on successful transaction notifications. This leverages another Ash domain model feature to only send notifications on transaction completion so you avoid half baked state in your views with complex transactions which may fail, including transactions that occur across multiple data layer types (think a mix of ETS, Postgres and some external API).

Then we get into the Ash query engine that plans out and pushes queries down to heterogeneous data layers including joining across these layers and doing so in a smart way to preserve observability constraints defined by access policy using it’s SAT solver to make it efficient. e.g. it wouldn’t make sense to query all items on an external API and then join those IDs against a local Postgres table, return the results and only then restrict to what you’re allowed to do. For one, aggregates and calculations will be wrong also and we want those pushed down to the datalayer where possible. For example, if you have an access policy rule that limits observability to only items you created or have contributor role for the Ash SAT solver will determine an efficient means to answer the question.

Most of the drudgery taken care of for ambitious applications.

Ash is truely is on a another level of thoughtful and purposeful design, @zachdaniel has really done some amazing work the Ash Framework.

5 Likes
8

Really appreciate the insight and kind words :man_bowing:

1 Like
9

Moving to ElixirForum just benefited me. I googled elixir ash registry to understand what it is and if I still need it (I ended up with it from an example somewhere). The top result was this excellent question and answer Ash: when to use Registry, and what are the advantages?

7 Likes
10

This is exactly what we were hoping for. That is great to hear!

3 Likes