When would you use plain Phoenix and when Phoenix with Ash?

Can you suggest a real world example, e.g. a car selling website like cars.com or social network or blog, API for mobile apps, etc.? Which to use when?

2 Likes

Since Ash is new, I’d use it for experimental projects and learning. After some hands-on experience, you’d be able to decide for yourself in future projects.

1 Like

I have difficulty coming up with an example where I wouldn’t use Ash after using it for a year. Ash is doing a lot for you, but in the end, it is just resources and actions. A resource can represent pretty much anything, and actions are how you interact with it.

It’s a lot to learn at the beginning, but I feel it pays off very well in the long term.

1 Like

I learned to not deviate too much from the “defaults” of the ecosystem anymore.

  • For the short-term, the benefits can be huge when just pulling together any productivity boost available at the time, definitely true
  • For the mid-term, you often end up needing those customizations anyway, just that you do it now another abstraction indirection or drop down to the original thing, so its just added complexity because of more stuff to think about in total
  • For the long-term, the best ideas from the community ends up in the default way ideally. Like, Surface did some awesome things and then we got Heex + live components in phoenix liveview natively after a while when they joined forces. This is when an idea really succeeds for me.

… also add ontop that there are many many engineers here that already struggle with the learning curve of elixir/phoenix/liveview when they start out, and I really hesistate to add anything else ontop for now. Also the “there is no magic” and straightforward functions within phoenix really do help beginners to “get” it, and I argue only after this point it even makes sense to talk about what ash brings to the table and why its good.

I have patience and will wait until ash is no longer “AshPhoenix” but natively/seamlessly integrated as optional component within phoenix itself, and I can choose to create some Context with a flag either plain ecto or with ash, just like I can choose to have my frontend generator phx.gen.live or phx.gen.html :slight_smile:

if this is not the roadmap, fine for me too, but then I will probably never use it personally, since I won’t deviate from the phoenix baseline defaults anymore. :slight_smile:

4 Likes

At the end of the day, Phoenix has very few opinions on how you build your actual application. In my opinion, delegating that decision to them is essentially deciding on “no decision”. I think it is pretty unlikely that phoenix will ever ship with Ash, but stranger things have happened :grinning:

1 Like

maybe not by name “ash” for whatever reason (although I don’t see a conflict, I also run mix ecto.gen.migration in a phx project, sooo)…, but I guess in terms of functionality like 80% could be done as a core lib at least, and then full focus with the rest of the stuff, like phx.gen.live being aware of either the more manual ecto-way or the more declarative ash-way.

If this just works natively, I think the majority of users of phoenix will start using ash without thinking it as an “or” decision like it feels today (its not technically correct but feels like that) - it rather would be an upgrade thats worthy some phoenix 1.9 keynote or sth like that.

But at the end of the day I believe its just more fun to explore new ideas or iterate on standalone things instead of fine-tuning the integration story, especially when lots of great feedback starts rolling in. Still I’d like to be “that” guy nagging in this area of focus, since a “unification” in many cases also brings more benefits to all partners than what anyone would achieve on its own, basically only a piece of the cake is yours but the cake itself is much larger in itself + more people to enjoy it with right there. I hope this somehow makes sense and please be assured I only argue about this at all because I think ash is a great project to begin with, so kudos to you :slight_smile:

1 Like

I think it’s better to leave Phoenix un-opinionated about your domain implementation as it currently is. I don’t think that it should include ecto related things or Ash related things. Phoenix is a web framework. It makes sense that many parts of Surface made their way into Phoenix because they have overlapping domains, whereas Ash and Phoenix are actually solving two different problems. Because phoenix has stayed un-opinionated about these things, people are free to bring in things like Ash, or not, or use other application building tools as they see fit.

Phoenix ships with a low level(but very high quality, I’m a huge fan of Ecto) tool for interacting with data, not any kind of application development tooling. People often refer to Ecto as an ORM, but it doesn’t really fit that bill.

6 Likes

I think I get your point here, but bear with me a bit!

First, phoenix is a framework and a library at the same time. It expands around a basic mix projects and adds the “$_web” layer ontop of it for some kind of interactions with the world. But it also provides the basic structure (contexts in the mix project and web stuff) and tooling (like predefined tailwind/esbuild) and fullstack goodies (like the generators, my primary way of working, that work on the web and non-web parts). And apart from the excellent toolings, it assembles Plug/LiveView/Ecto/… (each excellent on its own) into one seamless experience.

compared to (previous vanilla) phoenix+liveview, surface really tried to optimize the “user interaction” part ontop of the raw technology and made great progress on several specialized areas along the way. now we have a liveview on steroids (compared to back then) and the benefits even reached into other frontend areas (like deadviews now also enjoying Heex).

compared to (current) phoenix+ecto, ash really tries to trim down the context boilerplate into declarations and this indirection allows to have additional functionality like plug’n’play lego blocks because of added standardizations/knowledge internally to build upon. now we have a domain layer on steroids and can make progress in specialized areas along the way (iE: admin dashboard like django ootb, or APIs of different kinds without manual wiring/repetition, or…) so the benefits reach into other layers like frontend areas even.

so from my view its literally the same situation just from a different angle this time :slight_smile:

1 Like

I think we’re going to have to agree to disagree on this front :laughing: For some context, Surface is 15k lines of code in a single package designed to make a specific segment of your application better. Which is not disparaging to surface at all, its an excellent tool and “how many lines of code” is an extremely crude measure of scope.

In comparison, Ash is an entire ecosystem that does (I think based on this conversation) a lot more than you think it does. Using only the current published packages (there are a few that are not yet), Ash consists of 114189 lines of code. Again, I’m not suggesting “lines of code” is by any means a metric we should care about, I’m only trying to use it as a very crude illustration that Ash covers significantly more ground. A footprint that will only continue to grow.

To be fair, I too am not seeing Phoenix ever making tighter integrations with libraries like Ash but for what it’s worth nothing is stopping any of us in the community to make Ash-aware Phoenix code generators.

And I get what you are saying, standardization brought in by Ash really opens up the doors to make stuff like Django does, which could be a huge win.

4 Likes

@Kin Also my apologies for not answering your question directly, but as the author of Ash I think there might be some (real or perceived) bias in my answers, so I’ll stay out of it and let others give you their thoughts.

1 Like

I haven’t used Ash yet but I’ve read a lot about it, so you can take that as you will. Basically, as others have said, Ash provides a bunch of solutions to many common problems for building your backend/business logic. There are very excellent alternatives to all of this stuff available in the ecosystem so it totally depends on if you are someone who prefers to assemble it all yourself or be handed an, also excellent, curated package of solutions.

2 Likes

hey man, agree to disagree :slight_smile:

and how I see it there is the Ash.Resource at the very heart of the ecosystem (which could be derived from existing Ecto.__schema__ reflection instead of doing the inversion of control break imo) and with a standardized resource struct at hand you build an expansive list of addons in different directions. My whole point is that the ecosystem split is not neccessary at all technically but many ecosystem features could be designed as phoenix plugins to begin with, which would expose them to a much bigger user base.

But that discussion is probably going nowhere, so I am closing my thoughts here with an answer to the very initial question: “never, until its a real part of phoenix” but nevertheless support the ash movement and @zachdaniel and keep an eye on how it goes :slight_smile: