Skip to content
On this page

Codebase Overview

The core concepts behind Directus are simple, however the problems that must be solved to honor them can be remarkably complex. We strive to design and engineer the most elegant solutions possible, so that our codebase remains accessible.


The primary Directus repository is located at directus/directus and houses the Admin App (Vue.js 3 w/ Composition API), API (Node.js), API Specification (OpenAPI), and other smaller packages used internally. Directus follows a monorepo design similar to React or Babel — this page will outline our monorepo's design and structure.


Contains the Directus API (REST+GraphQL), written in Node.js.


The CLI commands and matching functions that the directus package ships with.


Route handler controllers for the endpoints in the API.


Database manipulation abstraction, system migrations, and system data. Also where you'd find the main query runner.


Classes for the different errors the API is expected to throw. Used to set the HTTP status and error codes.


Various (express) routing middleware. Includes things like cache-checker, authenticator, etc.


Internal services. The main abstraction for interfacing with the data in the database. Both GraphQL and REST requests are "translated" to use these services as the main logic in the platform.


TypeScript types that are shared between the different parts of the API.


Various utility functions.


Contains the Directus Admin App, written in Vue.js 3 w/ the Composition API.


Assets that are included with the app, but not bundled.


Files that are included within the app. Are bundled / optimized in the build step.


(Base) components that are used across the platform. Contains "basic building blocks" like button, input, etc.


Reusable parts of reactive logic that can be used between Vue components. Includes things reactively calculating time from now, fetching a single item, etc.


Custom Vue directives (e.g. v-tooltip).


Components to display of data within the app.


The core-included interfaces.


Translations abstraction, and language files. The language yaml files are maintained through Crowdin.


The core-included layouts.


The core-included modules.


The routes in the app. Modules define their own routes, so this only includes the "system" things that don't belong to module, like login.


Pinia based stores used for global state tracking.


Global styles in the app. Every component has their own component styles, these are just the global styles.


TypeScript types that are shared between the different parts of the API.


Utility functions used in various parts of the app.


The (two) main views used in the app: public / private. Also contains "internal" coupled components for those two views.


The various sub-packages of the platform. Including the file-storage adapters, schema, specs, etc.


Tests are maintained on a per-package base. This folder contains the platform-wide (end-to-end) tests.