Full Stack Development vs Headless CMS vs Traditional CMS

Original Post

Which one is better?

Like most of us, I like to spend my time finding ways to improve development time while still producing high-quality apps. Lately, there have been increasing interest and popularity in using a Headless CMS. But how does it differ and what are the benefits from traditional development and a Traditional CMS solution?

Hopefully this post shed some light and serve as a guide for your next project :)

(Tip – There’s a TL;DR; at the end of this post)

To get a more detailed understanding, we should look common pieces in detail using actual examples such as .NET Core based stack, Strapi (Headless CMS), and WordPress (Traditional CMS):

So What’s a Headless CMS? In general, a Headless CMS is a management solution that is designed and built for simply managing the structure and access of content for multiple apps. Compared to a Traditional CMS, it’s a Headless CMS + front end management.

So how much development work are we looking at?

What percentage developers have to build/focus on typically look something like this:

UI

.NET Core: Whatever UI framework preferred.

Strapi: Whatever UI framework preferred.

WordPress: You can use the inbuilt UI management tools for theming, and configuring the layout of pages and posts for a website. Alternatively, it has a REST API for retrieving posts, pages, categories, tags, etc. with your preferred UI framework. The only caveat is that the API only returns content in HTML. So you need to consider that for front-facing web, mobile, and desktop apps.

Content Management

.NET Core: Unless you build a solution, you will have to define entities/objects/content types by defining classes and relations and integrating a data access technology like Entity Framework Core.

Strapi: Admin screen for defining entities/objects/content types and relations.

WordPress: Supports making pages, posts, categories, tags, by default. You will have to get a plugin or make your own for any additional content types.

Testing

.NET Core: You have to build unit tests and integration tests using xUnit or MSTest for APIs and any other server-side code you want to be tested. You are also free to use any client-side/UI testing tools according to what languages you’re using.

Strapi: No need for creating tests for server-side code. At most, you may want to manually double-check definition of content types, data stored, and roles and permissions just to be sure. You still need to focus on UI tests.

WordPress: You’ll have to focus on testing plugins to make sure updates don’t break anything. Helpers like PHPUnit and WP-CLI comes in handy.

APIs

.NET Core: Will have to architect and program REST or GraphQL API using data access technology like Entity Framework Core for connecting to a database, along with defining entities/objects/content types using classes.

Strapi: Platform automatically creates a REST and GraphQL API once you create content types using the admin UI.

WordPress: Automatically has a REST API to retrieve content. If needed you can extend the API endpoints.

Roles and Permissions

.NET Core: Typically you would use a library like Identity Services for SSO and regular user authentication (email and password). Then you will have to include authentication & custom permission checks on each request to a content resource.

Strapi: Admin UI section for managing roles and permissions with interactive with different content types.

WordPress: Typically only provides the below:

• Subscribers can read comments/comment/receive newsletters, etc. but cannot create regular site content.
• Contributors can write and manage their posts but not publish posts or upload media files.
• Authors can publish and manage their own posts, and are able to upload files.
• Editors can publish posts, manage posts as well as manage other people’s posts, etc.
• Administrators have access to all the administration features.

– taken from WordPress

Database

.NET Core: Typically a developer would use Migrations if using EF Core and the appropriate data provider library for the respective SQL database. It’s up to developers, or database admin to manage performance at the database level.

Strapi: Upon setting up, you’re given the option to choose which database to use:

MongoDB >= 3.6
MySQL >= 5.6
MariaDB >= 10.1
PostgreSQL >= 10
SQLite >= 3
It’s up to developers, or database admin to manage performance at the database level.

WordPress: Limited to only MySQL. It’s up to developers, or database admin to manage performance at the database level or acquire a plugin to help.

Email Notifications

.NET Core: Can implement this via an on-premise mail server, or external service. Can implement this in code base where necessary.

Strapi: Can use the email plugin to trigger sending emails using services like Sendgrid on custom controllers or services.

WordPress: Chances are you can easily get a free plugin to send emails. All you need to do is to provide mail server settings or external service account info (if using a service like Sendgrid).

SMS/MMS Notifications

.NET Core: Can implement this via external service. Can implement this in the code base where necessary.

Strapi: Based on their documentation, there’s no plugin to send SMS or MMS. However, nothing is preventing you from using a NodeJs SDK to send SMS/MMS notifications.

WordPress: Again, there’s probably a plugin for this. Otherwise, you’ll have to create one. In both cases, an external SMS/MMS provider account (like Twilio SMS) details are required.

Documentation

.NET Core: You can use Swagger for REST API documentation. There are also various free and paid solutions for providing documentation for both server-side and client-side apps. The choice is yours.

Strapi: It also uses Swagger for Strapi’s REST API documentation. The official documentation also addresses API endpoints that are generated for content types. As with any stack, you will have to find a free or paid solution for documenting any client-side app.

WordPress: Can find a plugin that uses Swagger to document WordPress’ REST API. The official documentation also addresses API endpoints that are generated for content types. As with any stack, you will have to find a free or paid solution for documenting any client-side app.

Cost

.NET Core: Depends on the hosting providers’ plans, and fees from 3rd party services.

Strapi: Depends on the hosting providers’ plans, and fees from 3rd party services.

WordPress: Depends on the hosting providers’ plans, and fees from 3rd party services, and paid plugins.

Fixing Bad Code… >_<

.NET Core: Can be found within the UI project, API, and perhaps some SQL. Still…. it depends on the situation. A developer may have been working on the codebase before you and may not have done such a great job choosing and sticking with software design patterns…. or requirements have changed which makes the existing code redundant. To make it worse, the codebase might be huuugee! No matter the reason, dealing with bad code sucks most of the time.

Strapi: You may find bad code within a custom controller, services, plugins, and within the UI project’s codebase.

WordPress: Can be found within plugins and event custom Js snippets for posts or pages.

TL;DR;

The truth is, it depends on the requirements for the app and the vision. If you just want a blog, WordPress is the way to go. But if you want a solution for managing content for various apps, blogging, and other various things, a headless CMS or full-stack development could be feasible.

You see or feel something should be updated? Please reach out and let me know! It’ll be awesome to hear your feedback on this.