Something that I noticed as I have begun building out applications in Phoenix is the complete lack of any kind of “Admin View.” Most frameworks like this don’t come with one included, but I guess I have just been spoiled by Django’s inclusion of these by default. I searched around and found several do exist and will maybe spend some time looking at them in the future, but today I’ll share my experience integrating Backpex.
First Impressions
The website for the framework is beautiful, and the demo you can access straight from the landing page without hunting around likewise looks great. It’s a far cry from the awful default Django Admin look and feel that has acted as a honeypot for so many designers who wind up dropping product work and doing everything possible to make it look better. 😈
It seems to fit the bill for being appealing to the eyes, easy to navigate, and the forms have a very rich design and are accessible, which is always a plus. Let’s see how it works setting up from scratch.
Setting Up
For this post, I am following the instructions on the GitHub repository and will build a simple application that uses the admin to manage blog posts. I won’t do a “blow-by-blow” but will summarize as I go along and share some comments and thoughts along the way. One mistake I made was looking past the prerequisites, which caused me heaps of problems later, so make sure you fulfill those before starting, especially ensuring you install daisyUI as well.
One gotcha is that the installation instructions show the PostLive resource with update_changeset/3 and
create_changeset/3 functions referenced; however, the Post schema only has a single changeset/2 that is generated
by default. If you are familiar with Phoenix Schemas, you will know what to do, but if you are new, you may get confused.
Simply add an ignored third arity to changeset and default it to an empty list.
def changeset(post, attrs, _meta \\ []) do
post
|> cast(attrs, [:title, :views])
|> validate_required([:title, :views])
end
Then update the references in the PostLive resource (note my app in this example is AdminSiteDemo):
defmodule AdminSiteDemoWeb.Live.PostLive do
use Backpex.LiveResource,
layout: {AdminSiteDemoWeb.Layouts, :admin},
schema: AdminSiteDemo.Blog.Post,
repo: AdminSiteDemo.Repo,
update_changeset: &AdminSiteDemo.Blog.Post.changeset/3,
create_changeset: &AdminSiteDemo.Blog.Post.changeset/3,
pubsub: AdminSiteDemo.PubSub,
topic: "posts",
event_prefix: "post_"
@impl Backpex.LiveResource
def singular_name, do: "Post"
@impl Backpex.LiveResource
def plural_name, do: "Posts"
@impl Backpex.LiveResource
def fields do
[
title: %{
module: Backpex.Fields.Text,
label: "Title"
},
views: %{
module: Backpex.Fields.Number,
label: "Views"
}
]
end
end
Other than that, following the instructions and skipping the theme switcher (it isn’t available in 0.6.0) yields a
complete working CRUD interface at /admin/posts!
My Thoughts
The setup is rife with gotchas. I feel a lot of similar projects like this in the Phoenix ecosystem require you to take
a scalpel to the generated Phoenix code to install. On one hand, this is great as you really get to know the details of
all the moving pieces and can custom tailor to your needs. On the other hand, it is nice to be able to just run a
command like mix phx.gen.auth Accounts User users and have it “just work.” That said, I do like it because I have
two projects using Backpex, and both are using it in different ways.
Once you get going though, I love the simplicity. Just this morning, I created a full admin site for all the schemas in my application and even got into the details of field customizations, computed fields, etc. To be completely done with that and have custom actions for some resources was just fantastic. I think the project has a lot of promise, and I will be following development closely. You can see the end result of this exercise here.
Are you using Backpex in production? Or are you perhaps using one of the other admin interfaces that exist? Sound off below!