Backend overview

The components in this library are only half of a product: a LoginForm needs an account system, a DataTable needs a paginated endpoint, a Composer needs a model that streams. The Backend section documents three packages that provide that other half, designed together so that the props a component takes are exactly what the API returns.

How a request travels

Take the login screen. LoginForm calls onSubmit, which comes from useLogin().loginFormProps. The hook calls client.auth.login(), which fetches a CSRF cookie if needed and posts JSON to /api/auth/login. Django checks the rate limits, the password and the 2FA state, writes the session to MongoDB and answers either the user or {mfa_required: true}. The hook flips to the second step and the page renders TwoFactorForm with twoFactorFormProps. Errors come back in one format, so the same hook can put field messages under the right inputs.

"use client";
import { LoginForm } from "pleate/auth/login-form";
import { TwoFactorForm } from "pleate/auth/two-factor-form";
import { useLogin } from "pleate-client/react";

export default function Login() {
  const login = useLogin({ onSuccess: () => location.assign("/") });
  return login.mfaRequired
    ? <TwoFactorForm {...login.twoFactorFormProps} />
    : <LoginForm {...login.loginFormProps} />;
}

The apps

Each feature is its own Django app, mounted under its own prefix by pleate_backend.urls. Remove an app from INSTALLED_APPS and its routes, its /auth/me fields and its section of the data export disappear with it.

Why Django on MongoDB

The backend uses django-mongodb-backend, the official MongoDB backend for the Django ORM, instead of talking to MongoDB through PyMongo or an ODM such as MongoEngine. The choice is about what comes for free:

• The Django ORM. Models, migrations, querysets, select_related, signals and transactions, the API every Django developer already knows. Your own models sit next to pleate's and can point at its User with a plain ForeignKey.
• Django auth. Password hashing (Argon2), permissions, groups, sessions and authenticate() work unchanged, so roles and object permissions build on them instead of reinventing them.
• The admin. Every app registers its models, so staff can browse users, files, bans or webhook deliveries on day one.
• Django REST Framework and OpenAPI. Serializers, permissions, throttles, filters and drf-spectacular all need the ORM. The OpenAPI schema is what generates the TypeScript types of pleate-client.
• The ecosystem. django-filter, django-storages, django-anymail and Celery plug in as they do on PostgreSQL. With PyMongo or MongoEngine each of these would need its own glue.

Where to go next