New packages, revamped admin

Well, it's been a couple months and a lot has happened.

I'm still marching towards a 1.0 release, but for now I'm still enjoying the freedom to change things on a whim.

To give you a taste, here are the kinds of projects where I'm using Plain:

• a code review product (used by Fortune 500 companies)
• a custom wholesale ordering portal
• a marketing + e-commerce site
• a marketing + documentation site (for Plain!)
• my personal notes app :)

Let's get to the latest highlights!

New packages

Surprise, there are six new Plain packages! Again, these all come from real-world use — nothing hypothetical. The downside of this fast, "entrepreneurial" approach is that there is very little documentation so far, since the focus is entirely on getting the core package published and functional.

plain.tunnel - an ngrok replacement

I've been using Ngrok for years to integrate webhooks into my apps. But these days it feels like ngrok has outgrown me! It has all kinds of features that I just don't care about, and definitely don't want to pay extra for. There are alternatives, but mostly tailored to other ecosystems/languages. Anyway, I was curious and decided to try building a simple replacement using Cloudflare and it's working great!

Eventually I think Plain will have some paid services, and this might play a role in it. But even then, the goal would be to have a generous free tier and/or hit the no-brainer pricing that ngrok used to have (I happily paid $60/yr for years).

plain.support - built-in customer support features

I've gone back and forth over the years with using Intercom. Ideally, every project would be able to justify the cost of services like that. But in reality it can be pretty expensive for small businesses and side projects, plus they don't really design them for one or two person teams.

Anyway, plain.support is a step towards an official, off-the-shelf solution for supporting users. Initially it is starting with basic "contact support" forms that trigger emails. These forms can be rendered directly in a Plain app, or can be embedded in a marketing or documentation site.

I'm not working on it yet, but I have a specific vision for how in-app chat could work as a part of this and be designed specifically for solo or small teams (i.e. where 24/7 chat support is not a viable expectation).

plain.pageviews - simple pageview tracking

Related to plain.support, it's often extremely useful to see what pages a user was just looking at. Tools like Intercom do a good job of integrating these details. In theory you can find this in a separate analytics service, but in reality we never go to look or make the necessary connections for it to work. We have a database, why not use it?

plain.redirection - manage redirects from the admin

One of my favorite plugins from the WordPress ecosystem is Redirection. This isn't too different from the Django redirects app, but it has some important additions like seeing 404s so you know where redirects are needed! I recently helped transition a marketing site over to Plain and decided to build out the initial version of this.

plain.esbuild - compile js assets with esbuild

I'm still piecing together the "JavaScript story" for Plain, and as much as I like the idea of no build, there are still plenty of legitimate and useful reasons to build a JavaScript asset.

The plain.esbuild package is for projects that have independent js files scattered around that need building (i.e. not a single entrypoint). You don't have to set up a bunch of file watchers in dev, or integrate it into your pre-deploy step — this package will do everything. Just name your file with a .esbuild.js extension and it will be compiled with esbuild.

plain.api - buid a REST API with views

Plain uses class-based views, and plain.api is simply an extension of that. API endpoints are building using standard url patterns and a few base classes. Type annotations can optionally be added for validation and automatic OpenAPI documentation.

More to come on this one, including what I hope will be a Stripe-like approach to API versioning.

Revamped admin

The plain.staff package has been renamed back to plain.admin! Ultimately I think this is just what people expect to call it.

As you can see above, the Plain admin has a new dark style! I'm still playing with where and how the admin can be customized, with the goal being that you can make a fairly complete back-office tool inside of it.

Under the hood, most of the admin view classes have been reworked. I do like the pattern being used here though which is to nest classes inside a Viewset, which automatically interlinks them with each other.

The admin toolbar also shows detail for exceptions! I like the direction this is headed compared to doing a full-blown error page, because I still want to know and remember what the end-user sees in these situations.

Other notable changes

• the repo root is now on the PYTHONPATH, so relative imports work and absolute imports are app.{pkg}
• plain dev keeps the local URL at the bottom of the terminal
• breakpoint() opens a Mac terminal in development
• all Django management commands have been replaced with Click commands
• assets served as a URL + view, not middleware
• moved auto .env loading to plain.dev (.env files are usually for dev)
• TemplateEmail class is built in to plain.mail
• dd() multiple objects at once
• jinja.py files renamed to templates.py
• template filters and globals are registered with a decorator
• custom compile commands can be written in pyproject.toml under tool.plain.compile.run