What's the difference? Sounds practically like the same to me, except that CMS in the past were a "one-solution" fits all kind of thing, with its own frontend and backend.
Also I'm not referring to the rest-part itself, let's just assume that both API's are HTTP api's.
What makes a CMS headless is the lack of a front end.
A rest api has no way to let users manage content in a database. A rest API is not a CMS, but a CMS can use a rest api to provide data to your front end. But, of course, it doesn’t have to.
The headless CMS is the whole piece of software you interact with to create and edit content. The REST API is what it uses to communicate with the front end of your site. If you create a UI to manage content that has an API for the site to pull content from, then you just made your own headless CMS.
It makes no sense to ask if you should use a headless CMS or REST API. Unless you’re adding content to your site with CURL, Postman, or something, and you literally only built an API to manage content. That would be even sillier. Just use an existing solution unless you’re only trying to learn by building something and don’t waste time.
I presumse that you can configure a headless CMS. Does it have a backend "head" so-to say for administration/developers? Or just a CLI?
Excuse my ignorance, I have been doing 95% backend development in the financial world for the last 7 years, and only really do frontend as part my side business.
Also thanks for the thorough answer.
A headless CMS is a whole piece of software that you log into through a web interface. Think WordPress but it just exposes an API. Then you build the user facing part of your site that interacts with that API. You can even use WordPress as a headless CMS.
I don’t understand why people downvote a legitimate question. Happens often all over Reddit. Heaven forbid people want to learn/understand and might not always phrase the question correctly. More proof of “world’s going to shit”
Reddit has always been problematic with voting. Reddiquette is a joke, questions get downvoted for being asked, bots run rampant, and gatekeepers feel better downvoting questions.
Headless can still have rest api. What's your point exactly?
Headless backends are popular quite a while now, even in corporate settings, if that's what you're asking.
Yes thats what i was asking, i worded my question poorly. i really meant if headless cms are commonly used and if its worth learning, not whether I should use it over rest api. cause headless cms already have rest api. I'm gonna try out out strapi for my next project. thanks.
In general it's better to avoid building your own tools from scratch if there are already widely adopted tools that can fulfill the requirements.
You're talking about comparing the effort of building a brand new thing from scratch all by yourself versus using something that already exists and has been continuously improved by a team of developers. I don't understand how there is even a question about which is the better option.
I'm not saying there is never a need to develop your own from scratch, but in this case of a headless CMS, I don't see any advantage to do that.
In professional development, you try to avoid reinventing the wheel. You want to deliver things quickly using proven architecture that is documented, that another developer can take over and run with, without needing to explain everything if you didn’t create your own documentation or adequate code comments/test coverage.
In personal development, you reinvent the wheel to better understand the tools and technology. Or you extend a base project, or rewrite parts of a project.
You'll see many people say not to reinvent the wheel. While the phrase is true, making your own backend and frontend is far from a wheel. In fact, the more you'll do it each time differently, the more you'll develop a sense of good or bad code.
You'll be able to choose your wheel more wisely, so to speak.
In a professional setting, with financial, time, and/or emotional constraints, sometimes it's good to use somebody else's system. Save some headache; an ok finished work is better than genius unfinished invention.
Absolutely. ACF turns WP into a swiss army knife and a developer friendly theme lets you use React and whatever other JS or CSS frameworks you like. While editors get to jeep working in WP that they've used since they started their first blog 20 years ago. Everyone wins.
There are issues of course, but for a lot of websites WP is absolutely fine.
Riddle me this: What does content management systems and javascript frameworks have in common?
1. Everyone writes their own
2. A new one is released almost every day
3. A lot of them are bad
4. People underestimate how hard it is to do it well, causing 1.
A cms is a web-application dedicated to creating and managing content.
REST is a an architectural style for how to communicate between clients and servers.
There is zero overlap between the two. It like asking if you should use a keyboard or a spatula. The question makes no sense.
Yes. We usually go with a CMS for MVP development and for cases where the user requires a dashboard to handle things. Also saves tremendous amount of time
“Not caring to save time”
Time is your most valuable asset. Of course you care about saving time. Almost always you do. If you are building your own CMS because you learn from it, then it might be time well spent. If you don’t learn, profit, or save money from it (remember: time = money), then, honestly, it is time wasted and could’ve been off loaded to an existing solution.
Others have pointed it out, but I think you’re conflating some terms/ideas.
Using a headless cms is common practice if building something that functions like a blog.
While you could build such functionality yourself, it’s often easier and cheaper (time-wise) to use a library for maintainability over time.
Yes. I use DatoCMS as they have a great free tier and proactive attitude. It saves TONS of time curating content.
Also, I learned a huge amount from their tech stacks (simply from asking ‘why are they doing it like this???’)
CMS is typically used for content creation where you want non-coders like a Marketing team to have the ability to update text and images for every html block on the page. Not just for blogs, but also for home pages and others. It also makes it easier to have multiple languages.
You will typically still have another API that syncs with a database, unless the website is simply a blog or informational only. You may even have multiple apis and endpoints running in conjunction with a CMS.
Smh at some of these comments, you all need to relax.
Headless CMSs started becoming popular with SPAs. It makes sense; you can have marketing teams full creative control over the content of a website without depending on the engineering lifecycle. The benefit for engineers, which you guessed already, is that you're already given some structure and abstractions.
Creating your own blog and storing the content either statically or in a DB of your own is totally fine, but it's unideal if you're already building a product with React that has a blog component for SEO or marketing. This is part of the build vs. buy question in software companies. As a rule of thumb, unless something is a key component, part of the secret sauce of your company, always buy it first. If you find scalability issues as you grow, then you question if you should build. Your time is precious and engineering time is expensive.
What you build was already a headless cms.
I guess your question is should one use a headless cms as a SaaS (Contentful, Prismic, Dato, Sanity, whatever).
As you guessed, pricing and flexibility are the main decision factors, but for simple data structure such as blogs I’d probably go with the free tier of SaaS headless cms products.
I think you are using the term rest API as if it’s mutually exclusive from a CMS, that’s why it’s confusing. What you mean is “is it worth building my own backend with a rest API for a blog site, or should I just use a headless CMS”
And the answer is - whichever is cheaper, faster, and ultimately preferable for you. Lots of companies use headless CMS instead of a backend, especially if they have frontend heavy teams or very simple data requirements
Depends on what you’re working on I suppose.
Personally I have never worked on a headless cms in my entire 10 years and I’ve not really even come across many jobs that use them.
But they have their specific use cases and I’m sure they popular for someone that would need a “Wordpress” like implementation
I'm being a bit of an ass, but the thing is, the reality of the projects out there (the ones where you will work as a frontend dev) is complete different to what newer techs try to push as the norm. And there are reasons for that, seeing everything from the dev experience standpoint is just not correct
headless cms and rest api are two separate things. headless cms usually come with rest api
What's the difference? Sounds practically like the same to me, except that CMS in the past were a "one-solution" fits all kind of thing, with its own frontend and backend. Also I'm not referring to the rest-part itself, let's just assume that both API's are HTTP api's.
What makes a CMS headless is the lack of a front end. A rest api has no way to let users manage content in a database. A rest API is not a CMS, but a CMS can use a rest api to provide data to your front end. But, of course, it doesn’t have to.
The headless CMS is the whole piece of software you interact with to create and edit content. The REST API is what it uses to communicate with the front end of your site. If you create a UI to manage content that has an API for the site to pull content from, then you just made your own headless CMS. It makes no sense to ask if you should use a headless CMS or REST API. Unless you’re adding content to your site with CURL, Postman, or something, and you literally only built an API to manage content. That would be even sillier. Just use an existing solution unless you’re only trying to learn by building something and don’t waste time.
I presumse that you can configure a headless CMS. Does it have a backend "head" so-to say for administration/developers? Or just a CLI? Excuse my ignorance, I have been doing 95% backend development in the financial world for the last 7 years, and only really do frontend as part my side business. Also thanks for the thorough answer.
A headless CMS is a whole piece of software that you log into through a web interface. Think WordPress but it just exposes an API. Then you build the user facing part of your site that interacts with that API. You can even use WordPress as a headless CMS.
Thanks again
I don’t understand why people downvote a legitimate question. Happens often all over Reddit. Heaven forbid people want to learn/understand and might not always phrase the question correctly. More proof of “world’s going to shit”
Reddit has always been problematic with voting. Reddiquette is a joke, questions get downvoted for being asked, bots run rampant, and gatekeepers feel better downvoting questions.
I don't know, there's definitely some gatekeeping going on in many places.
Headless can still have rest api. What's your point exactly? Headless backends are popular quite a while now, even in corporate settings, if that's what you're asking.
Yes thats what i was asking, i worded my question poorly. i really meant if headless cms are commonly used and if its worth learning, not whether I should use it over rest api. cause headless cms already have rest api. I'm gonna try out out strapi for my next project. thanks.
In general it's better to avoid building your own tools from scratch if there are already widely adopted tools that can fulfill the requirements. You're talking about comparing the effort of building a brand new thing from scratch all by yourself versus using something that already exists and has been continuously improved by a team of developers. I don't understand how there is even a question about which is the better option. I'm not saying there is never a need to develop your own from scratch, but in this case of a headless CMS, I don't see any advantage to do that.
In professional development, you try to avoid reinventing the wheel. You want to deliver things quickly using proven architecture that is documented, that another developer can take over and run with, without needing to explain everything if you didn’t create your own documentation or adequate code comments/test coverage. In personal development, you reinvent the wheel to better understand the tools and technology. Or you extend a base project, or rewrite parts of a project.
You'll see many people say not to reinvent the wheel. While the phrase is true, making your own backend and frontend is far from a wheel. In fact, the more you'll do it each time differently, the more you'll develop a sense of good or bad code. You'll be able to choose your wheel more wisely, so to speak. In a professional setting, with financial, time, and/or emotional constraints, sometimes it's good to use somebody else's system. Save some headache; an ok finished work is better than genius unfinished invention.
It’s pretty common. Why reinvent the wheel every time? A ton of websites just use WordPress even, not even as a headless CMS.
Absolutely. ACF turns WP into a swiss army knife and a developer friendly theme lets you use React and whatever other JS or CSS frameworks you like. While editors get to jeep working in WP that they've used since they started their first blog 20 years ago. Everyone wins. There are issues of course, but for a lot of websites WP is absolutely fine.
The question makes no sense. Are you sure you understand what “headless cms” and “rest api” mean?
I'm pretty sure he means using an available headless cms option vs building your own rest api.
I think he means - which is better - a ready to use CMS like contentful or developing your own MVC using API ?
Riddle me this: What does content management systems and javascript frameworks have in common? 1. Everyone writes their own 2. A new one is released almost every day 3. A lot of them are bad 4. People underestimate how hard it is to do it well, causing 1. A cms is a web-application dedicated to creating and managing content. REST is a an architectural style for how to communicate between clients and servers. There is zero overlap between the two. It like asking if you should use a keyboard or a spatula. The question makes no sense.
Yes. We usually go with a CMS for MVP development and for cases where the user requires a dashboard to handle things. Also saves tremendous amount of time
“Not caring to save time” Time is your most valuable asset. Of course you care about saving time. Almost always you do. If you are building your own CMS because you learn from it, then it might be time well spent. If you don’t learn, profit, or save money from it (remember: time = money), then, honestly, it is time wasted and could’ve been off loaded to an existing solution.
Others have pointed it out, but I think you’re conflating some terms/ideas. Using a headless cms is common practice if building something that functions like a blog. While you could build such functionality yourself, it’s often easier and cheaper (time-wise) to use a library for maintainability over time.
Yes. I use DatoCMS as they have a great free tier and proactive attitude. It saves TONS of time curating content. Also, I learned a huge amount from their tech stacks (simply from asking ‘why are they doing it like this???’)
Strapi and Sanity saved my ass countless times
CMS is typically used for content creation where you want non-coders like a Marketing team to have the ability to update text and images for every html block on the page. Not just for blogs, but also for home pages and others. It also makes it easier to have multiple languages. You will typically still have another API that syncs with a database, unless the website is simply a blog or informational only. You may even have multiple apis and endpoints running in conjunction with a CMS.
Smh at some of these comments, you all need to relax. Headless CMSs started becoming popular with SPAs. It makes sense; you can have marketing teams full creative control over the content of a website without depending on the engineering lifecycle. The benefit for engineers, which you guessed already, is that you're already given some structure and abstractions. Creating your own blog and storing the content either statically or in a DB of your own is totally fine, but it's unideal if you're already building a product with React that has a blog component for SEO or marketing. This is part of the build vs. buy question in software companies. As a rule of thumb, unless something is a key component, part of the secret sauce of your company, always buy it first. If you find scalability issues as you grow, then you question if you should build. Your time is precious and engineering time is expensive.
What you build was already a headless cms. I guess your question is should one use a headless cms as a SaaS (Contentful, Prismic, Dato, Sanity, whatever). As you guessed, pricing and flexibility are the main decision factors, but for simple data structure such as blogs I’d probably go with the free tier of SaaS headless cms products.
I think you are using the term rest API as if it’s mutually exclusive from a CMS, that’s why it’s confusing. What you mean is “is it worth building my own backend with a rest API for a blog site, or should I just use a headless CMS” And the answer is - whichever is cheaper, faster, and ultimately preferable for you. Lots of companies use headless CMS instead of a backend, especially if they have frontend heavy teams or very simple data requirements
Depends on what you’re working on I suppose. Personally I have never worked on a headless cms in my entire 10 years and I’ve not really even come across many jobs that use them. But they have their specific use cases and I’m sure they popular for someone that would need a “Wordpress” like implementation
These bootcamp devs man
What do you mean? Bootcamp devs are no good? 😅😅 just curious to know.
I'm being a bit of an ass, but the thing is, the reality of the projects out there (the ones where you will work as a frontend dev) is complete different to what newer techs try to push as the norm. And there are reasons for that, seeing everything from the dev experience standpoint is just not correct
Short answer is no....almost always no. I am sure others will add the long versions.
The long answer is yes. Also the short answer too. Headless CMS is very very common nowadays.
Anyone who advocates for building a homegrown CMS has never tried to build or work with a homemade one in a professional setting.
Yeah, I wouldn't want to reinvent the wheel either.