react-admin: a Data Provider based admin framework for REST and GraphQL

The problem react-admin solves: CRUD screens for an API you already have

Most internal tools are the same application wearing different labels. A list screen with pagination, sorting and filters. An edit form with validation. A create form. A delete confirmation. A login page. A sidebar. None of it is hard, and all of it takes weeks, and every team writes it again.

React-admin targets exactly that layer. The README describes it as "A frontend Framework for building single-page applications running in the browser on top of REST/GraphQL APIs, using TypeScript, React and Material Design", open sourced and maintained by marmelab. The audience is a frontend team that already has an API and does not want to hand-build the admin surface on top of it. The framework is not a backend, not a database, and not a CMS. It renders in the browser and calls your API.

The design assumption worth noticing early is that your API is a given. React-admin does not ask you to reshape your backend to fit it. It asks you to write an adapter, and the README is blunt about the consequence: existing providers "can be used as a blueprint to design your API, or you can write your own Data Provider to query an existing API. Writing a custom Data Provider is a matter of hours." That sentence is the whole adoption decision in miniature.

Data Providers and Resources: how the framework actually moves data

The architecture has two named pieces. A Data Provider is an object of async functions that translate react-admin's CRUD vocabulary into your API's requests. A Resource is a declaration that a given endpoint exists and which pages belong to it.

The README's at-a-glance example shows the wiring. `<Admin dataProvider={restProvider('http://localhost:3000')}>` takes the provider, and a child `<Resource name="posts" list={PostList} edit={PostEdit} create={PostCreate} icon={PostIcon} />` binds the `posts` endpoint to three page components. Below that, the page components use hooks and field components such as `useRecordContext`, `DataTable`, `SimpleForm` and `TextInput` to fetch and render records. The documentation states that react-admin connects to any REST or GraphQL API and links to a list of more than 45 adapters, so the common case is picking an existing provider rather than writing one.

Two consequences follow. First, the Data Provider is the seam where every backend quirk lands: pagination conventions, filter syntax, error shapes, authentication headers. Second, the component layer is deliberately replaceable. The README calls the library "Batteries Included But Removable" and says it is built as loosely coupled components and hooks, so a custom datagrid, GraphQL instead of REST, or Bootstrap instead of Material Design are all presented as supported substitutions. The stack underneath is Material UI, react-hook-form, react-router, react-query and TypeScript, and the README notes types are opt-in, so a JavaScript codebase is not blocked.

Installing react-admin and rendering your first list

React-admin ships on npm. The README gives two equivalent install commands, and either works depending on your package manager. The provider used in the README example is a separate package, `ra-data-simple-rest`, which you install alongside.

npm install react-admin
#or
yarn add react-admin

After installation, the README's at-a-glance file wires an `Admin` element to a REST provider pointed at a local API and declares one Resource. Note that the provider URL in the example is `http://localhost:3000`, so the app expects a backend on that port.

import * as React from "react";
import { createRoot } from 'react-dom/client';
import { Admin, Resource } from 'react-admin';
import restProvider from 'ra-data-simple-rest';

import { PostList, PostEdit, PostCreate, PostIcon } from './posts';

createRoot(document.getElementById('root')!).render(
    <Admin dataProvider={restProvider('http://localhost:3000')}>
        <Resource name="posts" list={PostList} edit={PostEdit} create={PostCreate} icon={PostIcon} />
    </Admin>
);

The second file defines the three page components the Resource points at. `PostList` renders a `DataTable` with one column per field, `PostEdit` wraps a `SimpleForm` in an `Edit`, and `PostCreate` wraps the same form in a `Create`. What you should see after starting your dev server is a Material Design shell with a posts list, an edit form reachable from the row action, and a create form.

import { List, DataTable, Edit, Create, SimpleForm, DateField, EditButton, TextInput, DateInput, useRecordContext } from 'react-admin';

export const PostList = () => (
    <List>
        <DataTable>
            <DataTable.Col source="id" />
            <DataTable.Col source="title" />
            <DataTable.Col source="published_at" field={DateField} />
            <DataTable.Col source="average_note" />
            <DataTable.Col source="views" />
            <DataTable.Col>
                <EditButton />
            </DataTable.Col>
        </DataTable>
    </List>
);

If you prefer to read working code before writing any, the repository ships runnable examples under `examples/`. The Makefile exposes targets for each of them, and `run-tutorial` starts the tutorial app while `run-demo` starts the e-commerce demo with a REST backend.

make run-tutorial
make run-demo

Where react-admin is the wrong tool

The Data Provider is the first failure mode, and it is a hard one. If your API returns shapes that do not map cleanly onto list, get-one, get-many, create, update and delete, you are writing and then maintaining that translation yourself. The README's "a matter of hours" estimate covers the initial provider. It does not cover the months of small corrections that follow when your backend adds an endpoint with different semantics, and every screen sits on top of that adapter.

Server-side rendering is the second. React-admin is described as a framework for single-page applications running in the browser. If your product needs SEO-visible marketing pages and an admin panel in one deployable, react-admin covers only the second half. The related searches include a react-admin and Next.js pairing, but the README itself does not document an SSR story, so treat that as something to confirm against the documentation rather than assume.

The third is scope. React-admin gives you the admin shell. It does not give you a backend, a database, an authorization server, or a deployment target. Authentication, roles and permissions are listed as building blocks, which means the framework provides the components and hooks, and you provide the policy. A team expecting an out-of-the-box product with a database attached will spend its first week discovering that it has to supply the other half of the stack.

React-admin compared with Refine and AdminJS

Refine is the closest alternative and the one people search for most often alongside react-admin. The difference is where each puts the abstraction. React-admin's core contract is the Data Provider: a set of CRUD methods your adapter implements, with the admin UI built on top. Refine is built around a similar provider idea but leans on a hooks-first model, where you compose data, auth and notification hooks into your own application structure rather than declaring Resources inside an `<Admin>` element. If your team wants to keep an existing routing and layout and add admin pieces selectively, that style fits more naturally. If you want the whole admin shell assembled from a Resource declaration, react-admin is the shorter path.

AdminJS sits on the other side of the line. It is a server-side admin panel generator: you point it at a data source and it produces the panel, with the browser receiving a generated UI. React-admin inverts that. The panel is your React application, the backend is whatever you already run, and the customization surface is the React component tree. That inversion is why react-admin customization is deep and why initial setup requires more frontend decisions.

The practical test is not which framework is better but which half you want to own. React-admin asks you to own the frontend and the adapter. AdminJS asks you to own less frontend and accept its generated panel.

Maintenance, upgrades and the MIT licence

The repository is not archived, and the last push was on 2026-09-18. Recent releases are v5.15.3 on 2026-09-04, v5.15.2 on 2026-09-01 and v5.15.1 on 2026-06-24. The project is published under the MIT licence, which permits commercial and closed-source use, modification and redistribution provided the copyright notice and permission notice are preserved. That is a permissive arrangement, but it is not legal advice, and the LICENSE.md file is the text that governs.

Upgrade cost is the part teams underestimate. The repository carries a top-level UPGRADE.md and a CHANGELOG.md, and the presence of both suggests the project documents breaking changes rather than only shipping them. The version line is at 5.x, so a major bump is a real event. Because react-admin is a library of components and hooks rather than an application, a breaking change in a hook signature or a component prop propagates into every screen that uses it. The mitigation is the same as the risk: the README states that any component can be replaced with your own, so heavily customized screens absorb upstream changes differently from screens built from stock components.

The repository is a Lerna monorepo with a `packages/` directory and a root `package.json` that drives builds, unit tests, Cypress end-to-end tests and linting. If you vendor or fork it, that is the toolchain you inherit, and the Makefile targets such as `build-ra-core` and `build-react-admin` show the build is split per package.

Editorial conclusion

Adopt react-admin when you already have a REST or GraphQL backend and want CRUD screens, forms, filters and i18n without writing them yourself. Do not adopt it if you need a server-side rendered marketing-plus-app hybrid, or if you cannot write and maintain a Data Provider, because that adapter is the contract every screen depends on. Before committing, verify that an adapter for your API shape exists in the Data Provider list, and read UPGRADE.md to see what a major version bump would cost your codebase.

Frequently asked questions

Official sources

1. License: MIT
2. marmelab/react-admin on GitHub
3. Project website
4. README
5. Releases