Hello - I’m building an integration with Ash for my app, using the existing Backpex adapter as a starting point.
Ideally I’ll be able to open source this as a standalone AshExtension, or contribute it straight to Backpex in the future.
Would it be possible for me to get into the Backpex Slack?
I’d appreciate being able to either participate in any conversations that might impact this, or at least be aware of them ahead of time so I can prep for any changes that will break my integration.
I also already have a small wish list for you
And THANK YOU for a great library I’m at a point where building the integration feels better than the alternatives, as a business decision. I think that says a lot your incredible work.
First, thanks for your work on the Backpex Ash support. Many people have asked about it, but since we don’t use it in any of our apps, we haven’t made much progress in the last few months. Nevertheless, we are very interested in providing full support for Ash with Backpex. Having one of our community members work on it means a lot to us!
Would it be possible for me to get into the Backpex Slack?
I see that you’ve already joined the Backpex Slack, great!
Ideally I’ll be able to open source this as a standalone AshExtension, or contribute it straight to Backpex in the future.
Having it as a standalone package is great. Regarding your wish list, write down whatever you need to build the Ash adapter. We’ll support you wherever we can.
All the best in this effort.
I think it would be great to utilize Ash own resources and policies definitions instead of requiring the developer to add specific resources definitions to utilize Backpex “I think this aligns more with Ash idea of define once , derive the rest” as long as it is possible.
This is, indeed, what we are doing! AshBackpex derives defaults for the Backpex configuration from the Ash resource itself.
defmodule MyAppWeb.Live.Admin.PostLive do
use AshBackpex.LiveResource
backpex do
resource MyApp.Blog.Post
load [:author]
layout({MyAppWeb.Layouts, :admin})
fields do
field :title
field :published_at
field :author do
display_field(:name)
live_resource(MyAppWeb.Live.Admin.AuthorLive)
end
end
filters do
filter :state do
module MyAppWeb.Live.Admin.Filters.PostStateFilter
end
end
end
end
As time goes on we’ll see what more can be derived. For example in something like that PostStateFilter referenced, say the Post resource has 3 valid states of [:published, :draft, :trashed]. We could derive that filter from those configured constraints.
Policies are still not fully supported. We will need to do a bit of work in Backpex to make that compatible everywhere a given resource is queried.
For now I’m only using AshBackpex in a high-trust environment where all the users are admins anyway. I will be looking into getting policies fully compatible in the coming weeks/months!
Any plan to add RBAC “Role based access management” to Backpex ?
Backpex seems like a perfect place to manage users/roles since it is building the interface to do the admin work.
Very sad move.
Forcing bleeding edge on your users is not a good idea in general.
While Tailwind 4.x has many cool features, it drops support for a lot of older browsers, which is not a good tradeoff for existing projects on 3.x. Also some extensions don’t have support for 4.x It looks like there’s nothing special in 4.x that you couldn’t achieve with 3.x. So 3.x is not obsolete at all.
Hey, we use Backpex in some projects with different roles and permissions being involved. The can? callbacks can get you quite far. Currently, there is no plan to improve this or add dedicated features for RBAC.
I think it is a good idea if you create a discussion with requirements and feature wishes. Then we can see if others want to see such RBAC features/improvements as well.
In general, you are always welcome to contribute features and improvements to Backpex by submitting a PR (note that its always a good idea to submit an issue/discussion first to discuss implementation details).
It looks like there’s nothing special in 4.x that you couldn’t achieve with 3.x
Backpex depends on daisyUI, which dropped support for Tailwind v3 in its latest major update. Sticking with v3 would mean being stuck with an older version of daisyUI, with limited access to bug fixes and new features. Additionally, Tailwind CSS v4, especially the simplified installation process, made things easier for us. We developed a Backpex installer that was much easier to implement with Tailwind v4 (to be released in the next version of Backpex).
it drops support for a lot of older browsers
In v4.1, Tailwind improved compatibility with older versions of Safari and Firefox, so this shows the team is committed to maintaining broad browser support. See the v4.1 changelog.
In general, Backpex is still in a 0.X version, so things like major dependency upgrades and breaking changes are to be expected.
They still require a browser released not earlier than 2 years ago.
There’s absolutely no excuse to break people’s projects this way. The tech behind v.3 is still working and will continue to work for the foreseeable future.
Lost visitors/users on incompatible browsers directly translate to lost revenue. Shiny new toys for developers don’t translate to business outcomes. And then we complain that companies don’t take Elixir seriously.
If that distinction is worth real money how much of it are you investing for the maintainers to stick with tw3 – and likely decouple it from users style pipeline to support people using phoenix 1.8 with tw4? Unless you’re paying for it you cannot expect open source maintainers to work by your personal business constraints – no matter how valid your pov may be.
Up to now, yes, I haven’t been able to fully use Ash policies because the current_user aka actor isn’t present everywhere queries are being made.
I know that the Backpex folks added the assigns in more places with the 0.14 release, but I haven’t been able to dig deeply into that yet.
Some backstory on this integration - I started it so that I could use it in my own application for my web accessibility startup called Insi. Since then, I have been extremely busy with other aspects of this startup, and haven’t had the bandwidth to push ash_backpex any further than what met Insi’s immediate needs.
However, I’m going to. We can get away with limited authz for the moment because we’re only using it as an internal admin for now. The whole thing is walled off. But we will eventually want a more full-featured customer-facing admin as well as all the other Backpex bells and whistles.
My dream is to get it all hooked up with Igniter and be able to present a demo of creating a full featured AshBackpex app in like 15 minutes via the command line.
I guess I’m writing all this extra stuff to say I’m worried people think I have abandoned this - I have not! We have an #ash_backpex channel in the Ash Discord and Zach Daniel and other Ash maintainers have already been a big help!
We all have a limited amount of time in this world, and browser APIs move quickly.
It may be better to rip off the band-aid now and have a product that still works in 5 years, as opposed to having to maintain a legacy system, and watch as yet another Phoenix admin package eats your lunch because you’re stuck with a bunch of old code that you don’t have time to upgrade.
If you don’t like it, there are alternatives, like Kaffy.
Like it or not, the ecosystem has settled on using Tailwind v4. (see also: Phoenix 1.8)
There’s no band-aid. 3.x is perfectly fine, unless you enforce artificial obsoletion. There’s no rush to upgrade.
Or you could upgrade just in time, when all users have moved on to newer devices/browsers so you are not losing anything, you know.
In other words: don’t fix something that is not broken. And TW 3.x is clearly not broken. As is the tech behind it.
Also, not every code must be upgraded. Some code will work forever without an upgrade.
Nonsense, TW 3.x is still supported. The generated code can easily be adjusted, and it works only for new projects anyway.
they didn’t break anything. It’s free, and literally every revision is available on GH. So the thing they already gave you(for free) you still have(for free). They simply released more stuff(for free) that you don’t like when compared to the old stuff(that was free)
There is a conveniently placed “fork” button if you wish to invest the effort in maintaining a version of backpex using tw3.
With all that in mind, there is no “excuse” needed
