Headless CMS vs RDBMS

Question

0.00/5 (No votes)

See more:

Hey,

So the team I am on is experimenting with implementing a headless CMS to house all of our data. The headless CMS product is Contentstack. It's kind of cool it has Write and Read APIs for authoring data.

My question is, is this a good idea to use to replace essentially our RDBMS? We currently have one API that reads from a MYSQl DB and proxies other APIs that also house their data in a MYSQL db. The data is finally served to web and mobile experiences for both users and admin (We use a custom admin tool to curate data). There is also some inter back-end app communication through rabbit mq etc.

The bottom line is they are experimenting with replacing the data access layer to communicate with contentstack rather than mysql. There is some top down organizational suggestion floating around about all teams' data being in one place making it easier and breeds less barrier to entry for collaboration, however this is all in theory.

Have anyone ever been a part of something like this? Is it a good idea generally? My initial thoughts are... no especially if we aren't planning on using the headless cms UI to author data but instead our own curation tool. I just don't see an immediate benefit to justify the migration we could be doing.

What I have tried:

I have proofed it out and established it CAN be done. The question is SHOULD and WILL we do it?

Posted 17-Jun-19 5:59am

Member 8208898

Updated 17-Jun-19 8:03am

Add a Solution

2 solutions

Solution 3

One of the main benefits of a headless CMS is its dynamic document model. A content type (or content schema) can generally be created and modified easily. This flexibility has positive consequences for both business and engineering, when, say, marketing wants to create a new layout for a webpage, or engineering is tasked with standing up a new section of a website.

As mentioned above, the right solution is heavily dependent on the internal skills available. But having a highly-available, maintenance-free CMS plays nicely with other components of a modern tech stack. In addition, your application's existing APIs (and proxied APIs), could remain mostly the same.

Posted 28-Jun-19 8:53am

Member 14514693

Updated 28-Jun-19 10:36am

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

MadMyche · Accepted Answer · 2019-06-17T08:03:00

Solution 1

In all reality, the APIs you have in place aren't too far off from being a headless CMS.

What is right for you all depends on your needs and the skills you have available.
I personally prefer to have my own database and my own code for accessing it as it allows me greater flexibility and I can tune the queries as needed.

Posted 17-Jun-19 8:03am

MadMyche

Comments

Member 8208898 19-Jun-19 16:33pm

Yea, I agree with that. Thanks for the insight - our APIs are basically headless CMSs for the most part. At the very least we can migrate that part over to the CMS and be absolved with worrying about delivery... at least for basic payloads.