# Backend customization

Strapi runs an HTTP server based on Koa (opens new window). Its internal flow mostly revolves around 7 core concepts: requests, routes, policies, middlewares, controllers, services, and responses. Each of these parts can be customized, as well as models and webhooks.

# Requests

As Strapi runs an HTTP server, it receives requests, handled by routes. These requests can come from API calls (e.g. via a client application) or from the Strapi's admin panel and plugins.

Strapi's server is built upon Koa (opens new window). Koa's request objects are an abstraction on top of node's vanilla request object (opens new window). In Strapi, the context object (i.e. ctx) contains all the request-related information:

  • the request itself is accessible through ctx.request and is available to controllers and policies,
  • the body of the request is passed as ctx.request.body,
  • and the files are passed as ctx.request.files.

# Routes

Requests can be handled on any URL by adding routes to Strapi. Using routes is the first step towards creating custom JSON APIs to be used later on in the client application.

Routes can be configured:

  • with policies, which are a way to block access to a route,
  • and with middlewares, which are a way to control the request flow and the request itself, and change them.

Once a route has been created, it should execute some code handled by a controller.

# Policies

Policies are a way to block access to a route. They are usually used for authorization purposes or to check for some accessibility conditions.

In Strapi, policies work for both:

Policies can be global (i.e. applied to any route in a Strapi project) or scoped (i.e. limited to a specific scope, e.g. only used by a plugin or applied to a specific API).

As a developer, you can manually add policies, and they can also be added by the admin panel or by plugins.

# Middlewares

Middlewares are a way to:

  • control the request flow and change it,
  • and change the request before moving forward.

Usually middlewares are mostly used for logging, caching, debuging, error handling, and security purposes.

In Strapi, 2 middleware concepts coexist:

Middlewares are functions that are composed and executed in a stack-like manner upon request. They are based on Koa (opens new window)'s middleware stack.

# Controllers

Once a route has been created, it should execute some code handled by a controller.

Controllers are JavaScript files that contain a set of methods, called actions, reached by the client according to the requested route. Every time a client requests the route, the action performs the business logic code and sends back the response.

In most cases, the controllers will contain the bulk of a project's business logic. As the logic implemented in a controller becomes more complex, it's a good practice to move that logic into its own layer, ready to be reused and reorganised, using services.

# Services

Services are a generic way to build business logic. They are a set of reusable functions, that can be useful to respect the don’t repeat yourself (DRY) programming concept and to simplify controllers logic.

# Responses

At the end of the flow, Strapi controllers send a response to a request.

Strapi is based on Koa, so responses are based on Koa's response object (opens new window), which are an abstraction on top of node's response object (opens new window).

In Strapi, the context object (i.e. ctx) contains a list of values and functions useful to manage server responses. They are accessible through ctx.response, from controllers and policies.

# Models

Models, define a representation of the data structure of the content accessible through APIs.

There are 2 different types of models in Strapi:

  • content-types, which can be collection types or single types, depending on how many entries they manage,
  • and components, which are data structures re-usable in multiple content-types and can organized with dynamic zones

# Webhooks

Webhooks are a construct used by Strapi to notify other applications that an event occurred. A webhook is a user-defined HTTP callback, used to inform third-party providers so they can start some processing on their end (e.g. continuous integration, build, deployment, etc.).