Recently, we merged a pivotal change to how we treat Admin Users and End Users. This post will describe what we did, why we did it and how it affects you as you continue to develop your projects going forward with Strapi.

With the release of the Beta Version of Strapi, Admin Users (also called Administrators) and Users (called Users or End Users) are separated. Admin Users primarily interact with the Strapi dashboard. End Users primarily consume the API or access the front-end.

We made this split to maintain a separation of concerns going forward. Both Admin Users and End Users fulfill a different set of features:

For example, Admin Users concern themselves with content contribution (creating and editing content, moderating, translation, publication, A/B testing, previewing content prior to release, etc.), Strapi Administration (API tokens, webhooks, API testing and status checks, logging/monitoring, statistics, etc.) and a last example, third party providers (OAuth, LDAP, SAML).

These Admin User features are distinct and separate from the features available for the End User.

The features for the End User revolve around an authentication and authorization layer that you can build your business logic on top of. Similar to the features we are developing for the Admin User, we have goals we want to achieve with the users-permissions plugin. For example, providing a fully featured authentication and authorization service with OAuth2 and OpenID Connect, providing an advanced Role and Permissions system, custom policies, managing 3rd party connectors like Facebook and Google.

Of note, by separating the Admin User and End User, we have made it possible to create a logical integration where Admin Users become End Users. This also applies where an End User becomes an Admin User. Granular control will now be possible.

The separation of the Admin User and End User occurs at the database level and the UI level. Admin Users now occupy an administration panel located under, “Manage the administrators”, found under the username.

End Users are still found as a unique Content Type in the left-hand menu, under Users.

Aside, from a UI level change, the most fundamental change Strapi developers will confront is the need to create an additional End User. For example, if a blog or similar project is being developed that has a need to display the Admin User an “author”, a “profile name”, etc.

Simply put, an Admin User can access the Strapi dashboard. An Admin User may create content types, add content, manage API access, install plugins, etc.

An End User can only consume the API. This may include adding content but through the GET/POST methods in a form - not the Strapi dashboard. For example, for an ecommerce account, to leave a comment/review, to be the author of an article or otherwise have a profile.

But what about other blogging platforms? Those that do not separate the Admin Users from the End Users. This is a good point, but these platforms have been primarily developed around displaying website content and blogging. In that context, it might make more sense to keep both Admin Users and End Users in one database table. Strapi is much more than another alternative for solving blogging needs, we also include that as a capability, but Strapi is designed to do much more with content and APIs.

We made this change to how we handled Admin Users and End Users as an investment in the long-term roadmap of the Strapi project. A quick glance at the roadmap shows an even shorter-term step with the Administrators Roles & Permissions feature and then later, other features that are made cleaner in their implementation.

We felt that providing more granularity and control was worth the trade-off of extra complexity on our side but providing greater flexibility and features for our users. The approach of separating the Admin Users from the End Users allows for other features. Aside from upcoming features, by separating them, performance isn't affected due to, for example, the database structure.

In summary, separating Admin Users and End Users in the UI and database opens the door for providing features and functionality sought after by Strapi users. Their separation also avoids performance and database issues down the road.

Strapi is a 360° headless CMS. We are front-end agnostic as a headless CMS should be, but we are also database agnostic, allowing for a practically infinite set-up, configuration, and use. By being agnostic in this way, we are able to fulfill our mission to reinvent the way content is written and distributed to people. Separating the Admin User from the End User is just one step towards fulfilling the promise of a headless CMS.

Article written by your David in collaboration with Alexandre.