Backend Customization of Strapi

• the requests received by the Strapi server,
• the routes that handle the requests and trigger the execution of their controller handlers,
• the policies that can block access to a route,
• the middlewares that can control the request flow and the request before moving forward,
• the controllers that execute code once a route has been reached,
• the services that are used to build custom logic reusable by controllers,
• the models that are a representation of the content data structure,
• the responses sent to the application that sent the request,
• and the webhooks that are used to notify other applications of events that occurred.

In this article, we’re going to be working with the Strapi backend and covering a few aspects of customizations to the Strapi backend. We’re touching on controllers, services, policies, webhooks and routes, and others.

Also, I’ll explain to you how we can create our custom plugin.

Let’s start the customization

Custom Controllers and Routes

Controllers are a very important aspect of how Strapi works and play a big role in customizing the backend. So, let’s go ahead and create a custom controller which overrides the find function and a route for it.

Create a Controller

To define a custom controller inside the core controller file for the product endpoint or collection type, we can pass in a function to the createCoreController method.

Default implementation:

Custom code:

Here we are creating a countProducts which is a custom controller and it returns the count of products that are available or published. Since we have successfully created our custom controller now let’s move forward to create our custom routes.

Create a Route

We’re going to create custom route definitions for our countProducts controller. If we take a look at the already created product.js route, we’ll see that the core route has already been created:

We don’t have to make any modifications here in order to create our custom routes, we can create a new file for that. In order to access the controller we just created from the API, we need to add it to a route.

Create a new file that contains our custom route definition in the product/routesdirectory – ./src/api/product/routes/count-products.js with the

What we’re basically doing here is creating an object with a routes key, which has a value of an array of route objects.

The first object here defines a route with the method of GET and a path – /products/count. It also defines the handler, which is the controller that will be used in the route, and in our case, that would be the countProduct  controller we created.

Now let’s add some products from the content manager of Strapi:

Test the Custom Controller and Routes

Let’s run the Strapi application by the

or

Once the app is running we can start sending requests API platform tool. I’ll be using POSTMAN. It is an API development tool that helps to build, modify and test APIs. It can be downloaded from here.

Once, you’ve gotten your API tester set up, send a GET request to http://localhost:1337/api/products/count.

As you can see, we’re getting a 403 forbidden error. This is because Strapi doesn’t return anything for unauthenticated routes by default. We need to modify the Permissions in Strapi admin panel so that it is available to the public.

To do that, go to the Strapi admin dashboard, then go to SETTINGS in our admin dashboard, and then USERS & PERMISSIONS PLUGIN > ROLES > PUBLIC.

As you can see, we have a new action – countProducts. Enable it and click on SAVE. Now, if we try to send the request again, you should see the screenshot below.

Models

Creating a data structure for the content is one of the most important aspects of using the software. Models define a representation of the data structure.

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 that are data structures reusable in multiple content-types.

Model Creation

Content-types and component models are created and stored differently.

# Content-types

In my previous blog, I explained how we can create content types (Single-types, Collections). If you have no idea about it then please go through it first after then you will continue this article.

We could also create these content types using the strapi generate with Strapi’s interactive CLI tool.

The content types have the following models files:

• schema.json for the model’s schema definition. (generated automatically when creating content-type with either method)
• lifecycles.js for lifecycle hooks. This file must be created manually.

# Components

Component models can’t be created with CLI tools. Use the Content-type Builder or create them manually.

Components models are stored in the./src/componentsfolder. Every component has to be inside a subfolder, named after the category the component belongs to (see project structure).

Model Schema

The schema.json file of a model consists of:

• settings, such as the kind of content type the model represents or the table name in which the data should be stored,
• information mostly used to display the model in the admin panel and access it through the REST and GraphQL APIs,
• attributes, which describe the data structure of the model,
• and options used to define specific behaviors on the model.

General settings for the model can be configured with the following parameters:

Model Attributes

The data structure of a model consists of a list of attributes, and each attribute has a type parameter that describes its nature. They are scaler types(e.g. strings, dates, numbers, booleans, etc.), Strapi specific-types such as media, relation , component ,dynamiczoneand thelocaleandlocalizationstypes. If you have no idea about these terms then you can refer to this article.

Validations

Basic validations can be applied to attributes using the following parameters:

You can also refer to the official Strapi Models customization documentation for a better understanding of validations, relations, etc.

Policies

Policies are functions that execute specific logic on each request before it reaches the controller. They are mostly used for securing business logic. Each route of a Strapi project can be associated with an array of policies. For example, a policy named is-admin could check that the request is sent by an admin user, and restrict access to critical routes.

Policies can be global or scoped. Global policies can be associated with any route in the project. Scoped policies only apply to a specific API or Plugin.

# Implementation

A new policy can be implemented with the interactive CLI commandstrapi generate or manually by creating a JS file in the appropriate folder (see the folder structure)

Global policy implementation example:

Using config object you can configure policies:

You can get more information about policies on this URL.

Plugin Development

Strapi allows the development of local plugins that works exactly like the external plugin available from the marketplace.

Steps to create a plugin

Strapi provides a command line interface(CLI) for creating plugins. To create a plugin:

1. Navigate to the root directory of the strapi project.
2. Run yarn strapi generate or npm run strapi generate
3. Choose “plugin” from the list, and give the plugin a name in kebab-case(e.g my-plugin-name).
4. Choose either JavaScript or TypeScript for the plugin language.
5. Enable the plugin by adding it to the plugins configurations file:
   JavaScript

   // path: ./config/plugins.js module.exports = { // ... 'my-plugin': { enabled: true, resolve: './src/plugins/my-plugin' // path to plugin folder }, // ... }

   1 2 3 4 5 6 7 8 9 10

   // path: ./config/plugins.js       module.exports = {       // ...       'my-plugin': {         enabled: true,         resolve: './src/plugins/my-plugin' // path to plugin folder       },       // ...     }

6. Runyarn buildornpm run buildto build the plugin.

Plugins created using the preceding directions are located in thepluginsdirectory of the application (see project structure).

Add features to the plugin

Strapi provides programmatic APIs for plugins to hook into some of Strapi’s features.

Plugins can register with the server and/or the admin panel, by looking for entry point files at the root of the package:

• strapi-server.jsfor the Server (see Server API),
• strapi-admin.jsfor the admin panel (see Admin Panel API).

Conclusion

Congratulations, you have seen it to the end of this guide. You have seen how to customize controllers, routes, models, and policies, and also we have seen how to create our custom plugin on Strapi. If you have any doubts or queries regarding this then you can also follow the links that I provided below in References.

REFERENCES

• Backend Customization of Strapi Documentation
• Plugin development
• Admin Panel Customization
• Headless CMS and Strapi
• Deployment of Strapi on Heroku and Next.js on Vercel