An Introduction to Strapi

Strapi is the next-gen headless CMS. It is open-source, Javascript, enabling content-rich experiences to be created, managed, and exposed to any digital device.

The name Strapi summarizes what the open-source project does well, allowing you to create your API from scratch using a point-and-click interface. Developers can easily personalize their API for custom implementation or custom logic.

Why Did We Build Axolo and What is Axolo?

We believe efficient communication when reviewing, and writing code is essential for productive tech teams. Axolo is a tool to enable developers to engage and communicate easily around pull requests. We integrate via GitHub and Slack. Axolo creates a temporary Slack channel for every pull request so that you can discuss the pull request with your colleagues quickly and with the proper context (code review comments, code comments, GitHub checks, and GitHub actions).

How Do We Use Strapi at Axolo?

Strapi runs our backend and handles all the programming logic with our database. Strapi helped set up the models and create routes to interact with the GitHub and Slack API. It also gives an excellent base for scaling a project with the proper structure (controllers, services, API, policies, models, etc.).

What are Strapi Policies:

According to the Strapi documentation, "Policies are functions that execute specific logic on each request before it reaches the controller. They are mostly used for securing business logic." Policies are placed in your router and can be found under your models /routes folder. Usually inside api/{modelname}/routes/{modelname}.js.

What’s So Great About Strapi Policies?

Strapi policies allow you to create rules for your routes. Whenever you need to implement a rule for a route, you can add a policy to your router for the selected route. It helps keep your code DRY (don’t repeat yourself) and prevents your controller from being surcharged. I personally often find myself re-using routes I made a while ago.

Creating a Strapi policy

To create a policy, you need to create a folder in your src called policies. You can give it the name that you feel is more appropriate. The name of the file will be the name of the policy in your routes.

Applying a Policy to a Route

To apply a policy to a route, you need to add a key to your route object as stated in the Strapi documentation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
    // path: ./src/api/restaurant/routes/router.js 
    module.exports = {
     routes: [
       {
         method: 'GET',
         path: '/restaurants',
         handler: 'Restaurant.find',
         config: {
           /**
             Before executing the find action in the Restaurant.js controller,
             we call the global 'is-authenticated' policy,
             found at ./src/policies/is-authenticated.js.
            */
           policies: ['global::is-authenticated']
         }
       }
     ]
    }

The policies key takes an array as an argument. You can add multiple policies to a single route if you like. Also, the policy name is the name of the file.

How do we use Policies at Axolo: There are three (3) main ways we use policies at Axolo. Here is the list with code examples:

1. Is-admin policy:

This policy helps us determine if somebody making a request is an admin within his organization.

Within Axolo we have two types of users:

• An Administrator who can edit the settings for their organization,
• Engineers who use our service day-to-day.

Both types of users are signed in to our service but only the administrator can edit the settings. To add a layer of security to our frontend, we used a Strapi policy, see below:

1
2
3
4
5
6
7
8
    // path: ./src/policies/is-organization-admin.js
     
    module.exports = (policyContext, config, { strapi }) => {
     if (policyContext.state.user.isAdmin) {
       return true
     }
     return 401;
    };

2. Is a paying customer policy:

Some Axolo features are dedicated to paid customers. We’ve ensured a non-paying user cannot access those routes by adding an is-paying-organization policy. Our user model has and belongs to an organization model.

1
2
3
4
5
6
7
8
9
10
    // src/policies/is-paying-org.js
    module.exports = (policyContext, config, { strapi }) => {
     const id = policyContext.state.user.organization;
     const organization = await strapi.query('organization').findOne({ id });
     const { plan } = organization;
     if (plan === 'professional' || plan === 'trial') {
       return true;
     }
     return false
    };

3. To know the day of the week:

We use Heroku as a hosting platform and Heroku scheduler as a cron job. These cron jobs work by calling a specific route in our backend. Heroku only allows three possibilities for the cron job to be contacted: every 10 minutes, every hour, or every day. Since some of our actions only need to be run during the week, on a specific day, or only during weekends, we have a dedicated policy for each of those cases.

Here is an example of a policy that checks if it's a weekday (Monday, Tuesday, Wednesday, Thursday, or Friday).

1
2
3
4
5
6
7
8
9
10
11
    // src/policies/is-weekday-today.js
    const moment = require('moment');
     
    module.exports = (policyContext, config, { strapi }) => {
     const date = moment();
     const day = date.day();
     if (day >= 1 && day <= 5) {
         return true
     }
     return false
    };

Conclusion

Policies are helpful to keep your controllers DRY (don't repeat yourself). If you see yourself using the same code over two controllers or think you could be reusing some of the logic you implement in a controller, it probably is a good idea to create a policy for that.

Do you have any other use case for policies? Share them below so that anyone reading this article can get inspired by your way of having policies.