DEV Community

Cover image for Choosing a Content Management System
Jordan Snow
Jordan Snow

Posted on • Originally published at

Choosing a Content Management System

First off, let's get something straight. I'm something of a new developer. I played hell trying to figure out what the differences were between headless, decoupled, and legacy CMS's, as I'm sure any new developer who is teaching themselves how to code would under the same circumstances. The weird part, though, is that I have never really messed with Wordpress or Drupal (or any other traditional CMS). This really slowed me down in the long run, because when I started my search for a good headless CMS, I really didn't even know what I was looking for!

The SnowDev Blog

The only thing I really knew was that I needed some kind of system to reliably and efficiently write and consume my blog posts. I had a few simple requirements:

  • I needed to be able to use the CMS with my own custom frontend, as I was trying to teach myself as much as I could about development
  • I knew I would need a badass API system for when my blog goes completely viral and I have to set up load balancers on 12 different servers to be able to handle all the visitors 😁😁
  • I really wanted to have an excellent admin panel, with included editor, so that I wouldn't have to build it ALL on my own!
  • Whatever I chose had to be completely open source!

All these things had to exist in one place, right? So I fired up the trusty old Google search and started clicking away on the keyboard, but what was I actually looking for?

All CMS's Are Not Created Equal

The first thing I had to come to grips with was that there are profound differences between content management systems. So I needed to start chiseling out some definitions for myself.

Traditional Content Management System

Come to find out, a traditional CMS, such a Wordpress, Drupal, and Joomla, to name just a few, IS a solid way to get all of things you need to run a blog in production quickly. I didn't go this route, and while I truly learned a lot and accomplished my goals, I also decided that this really is the only option for the person who has minor technical chops, but who really wants to get a website up and running yesterday.

Sites like these are absolutely designed with the "leyperson" in mind. They truly have everything - SEO out of the box, secure and streamlined admin panels and content editors, full REST API's that are easy to work with (as long as you don't get too crazy about thinking outside their box), and beautiful frontends that make your website look like they were designed by an absolute pro (...well, because they WERE!). And don't even get me started on deployment! It's so easy! No worrying about Nginx or load balancing or Linux or DigitalOcean or, or, or...However, this really isn't what I was looking for. While I learned how cool some of these could really be, they definitely haven't converted me.

Decoupled CMS

I'm going to admit something here...I really didn't even know these were a thing until it was too late and I had already taken the bait. In fact, my blog as it sits right now, at the writing of this, uses a decoupled (not 'headless', as it's documentation says) CMS called Ghost. Now don't get me wrong, Ghost is pretty cool for a lot of reasons, and for the right person, I believe it would be fantastic. The Github community agrees, as right now Ghost has about 33.8K Stars. That's some pretty impressive numbers, but for as excited as I was, I was pretty let down when I finally got it up and running.

First of all, the documentation literally screams that Ghost is a "headless" CMS. Screams it.
Ghost CMS Home Screen
So imagine my disapointment when I realized that this system was more "decoupled" than it was "headless". A decoupled CMS has frontend, backend, and admin UI components, and you can decide which to use interchangably. For instance, Ghost is technically a legacy CMS that has been decoupled - which is great! I just wish they'd use the right terminology to describe their product, especially for new guys like me. What they really did was give out the API, which allows you to make calls from a custom frontend and consume the data. They don't allow you to shut off the site with their frontend running, however, as this is where the admin UI is located as well! (ie. - the frontend server is running on, while the admin panel is running on This was very frustrating to me, and I spent entirely too many hours trying to figure out how to shut off the frontend for a supposedly "headless" CMS.

An Actual Headless CMS

It's ok, though. Thank the Lord for Youtube subscriptions. My man Brad Traversy over at Traversy Media really came through for me, without ever knowing he was doing it! Right in the thick of my woes over this CMS struggle, I get a notification that he had a new video, giving a runthrough of something called Strapi. I was done coding for the night and ready for something a little different, so I checked it out. Glad I did...

Strapi is a truly headless, API-first, content management system. This means that, out of the box, you get an insanely powerful tool capable of making flexible data structures without breaking a sweat. Defining models, controllers, and middleware ("policies", in Strapi-speak) is a breeze. And then, and here's the best part, there is no frontend. None. You can consume Strapi API from any client. React? Check. Gatsby? Check. What about Angular, Vue, hell, even just a vanilla HTML/CSS/JS site? Yup, that works too.

I'm gonna blow your mind with this one, it get's even better - Strapi even works with GraphQL!!

I mean, the thing is just crazy. It comes with a --quickstart flag in it's CLI tool that, you guessed it, quickly starts your own instance of a development server, complete with SQLite and a file watcher that hot reloads the server, and a performant and efficient browser-based GUI for the developer. I could literally go on for about a thousand lines about how cool this thing is, so you're just going to have to take my word for it and go try it out!!!

So Let's Recap

  • A true headless CMS is API-first, meaning it doesn't have any frontend whatsoever forconsuming the data of your API, just creating and maintaining it
    • great for developers, steep learning curve for the blogger that just wants to get their words published online
    • most technical to get started with
  • A decoupled CMS has individualized components, ie a backend, API, frontend, and admin interface, and each part can be used somewhat individually
    • Really good intermediate starting point for the beginner developer that wants to learn about this stuff, but quickly stifling with the push to only use it in one way
  • A traditional, or legacy, CMS, provides everything in one package
    • The easiest way to get started, perfect for the professional blogger who wants to make their own small site without much customization

As always, if you have any questions, comments, concerns, or criticisms, feel free to drop a comment below! I would love to write an article on something you bring me! Make sure to watch for upcoming articles on how to get both a Ghost site and a full Strapi site deployed! These will be complete walkthroughs, with technical breakdowns of all the steps necessary to get a site up and running using both of these technologies!

Also, drop on by my website - Snow Development, and check out my blog running on the Ghost platform before I jump it over to Strapi!

Top comments (2)

patarapolw profile image
Pacharapol Withayasakpunt • Edited

My thought is I just want something to be over MongoDB (mongoose / typegoose, actually). That's why I created

It isn't that easy to use, and does involve remembering where things are though.

Actually, I have tried Strapi, and I didn't really get why I need it.

Ghost is nice for UI, but I don't really know if it is headless. Is it like WordPress, in the sense of headlessness? (Actually, my concern with Ghost and WordPress is customization of the UI.)

jordansnow_thelegend profile image
Jordan Snow

So Ghost does a great job with their UI and editor, but it's not truly headless at all. The only way to use it is to deploy your ghost app and just use it for the admin, then make calls to it with your frontend and display the data that way. You can then make the ghost app "private" so that it turns off all the handlebars-implemented SEO.

I almost think creating a blog with Strapi is overkill, unless you have more than one author contributing. It would be great for a small business web app that has a blog component with several employees contributing. Strapis real value is in how organized it is. It takes a weeks worth of API structuring and creation and accomplishes it in an afternoon. Very powerful.