September 22, 2017 at 14:52How I wrote my CMS, and why I do not recommend you do the same
Working on CMS content management systems is full of wonders. Under the cat is the instructive story of Petr Palas. If everything is fine with English, then in the original text can be read here . Enjoy!
In 2000, I studied at the university and worked as an Intranet developer: I published content written in static HTML on the Intranet. This was my first “programmer" work, and I enjoyed it. Couple of weeks.
Then it became obvious how my duties are monotonous and non-automated. And I started writing an application on the classic ASP, which would allow users to independently manage content. I had no idea about the existence of such a thing as the Content Management System, and therefore invented a bicycle. At that time there were only a few commercial CMSoften costing hundreds of thousands of dollars. Given the prevalence and price range of this category of software, it is not surprising that I was not the only one who tried to reduce my inconvenience and increase efficiency by creating my own CMS.
By 2004, almost every Internet agency created its own CMS , often customizing it for specific customers. This led to dozens of modifications - a nightmare in terms of management. “This is pointless,” I thought. By that time, I had already written some specialized CMS and was bored again. “What about writing a CMS that can be useful for any site?” As a result, I organized Kentico Software, whose mission was very simple: create a CMS that any developer in the world can use to create any site .
13 years later, I am still struck by the number of people who write their own CMS. There are many mature products for all types of projects: from open source to commercial systems of the enterprise level, from the best in its class to universal all-in-one.
So why does anyone still need to write their own CMS?
The answer is simple: people do this out of frustration .
Traditional web-based CMSs are fraught with limitations and limitations. But the truth is that all these disappointments have already lost their relevance . I know that sounds hypocritical. After all, writing my CMS helped me, so why doesn't it help others?
Let me explain.
Over the past 15 years, the CMS and technology market has begun to keep up with the changing digital landscape and user expectations associated with a wide variety of devices.
And today, a new generation of CMS technologies - cloud-based, with headless architecture - will soon revolutionize content management. Unlike traditional solutions, headless-CMS focuses only on managing content and making it accessible to any application through the API. Since such products do not have a “head” that usually dictates how content should be displayed, headless-CMS leaves the design question entirely to the developers.
Therefore, it’s not too wise to write your own CMS today - unless you want to become a vendor of such products. But it’s easy for me to speak. After all, I’m not the only one who has encountered many shortcomings and found many reasons why a self-written CMS can be a way out of the situation.
So let's look at the main reasons for the dissatisfaction of the developers and find out why they are out of date.
The first thing that front-end developers complain about is CMS interfering with their HTML code and the need to look for workarounds.
But this is over: headless-CMS gives you complete freedom and does not affect the resulting HTML code. To extract content from the repository, you just need to call the corresponding REST API using your favorite programming language.
Moreover, you yourself completely decide how this content will be displayed!
Many traditional CMS over the past ten years have grown significantly. Although they all started with the idea of providing a great content management solution, most could not escape the “creeping improvementism” because they infiltrated e-commerce, marketing automation, booking systems, email marketing and so on. Although it is convenient for someone to have everything in one place, it is difficult for new users to learn such CMS . Most only need to manage content; an excess of options reduces productivity.
The new headless-CMS is created on the basis of a different premise: this is just one of the fragments of the mosaic of microservices, and therefore these products have a user interface ,optimized specifically for content management . At the same time, modern CMSs provide content management APIs that allow you to create your own editing interfaces on top of their content repositories. This is convenient if you want to create a more specialized interface or integrate content editing capabilities into the application, rather than redirect users to another interface.
" We did not want to pay X rubles for a commercial CMS, so we decided to write our own ." If you don’t need something much simpler than a real CMS (like managing a list of news), in the long run you won’t be able to save with a self-written CMS .
Today you can choose from a mass of free open source CMS , or use the cloud headless-CMS, whose pricing policy takes into account the characteristics of consumption , which will always be more profitable than developing and using your own system.
For many organizations, CMS security is a nightmare. Therefore, some developers think: " If we write a CMS, then hackers will be harder to find bugs in it ."
Classical security through obscurity (security by obscurity).
Yes, hackers can take advantage of well-known security holes, but widely used CMSs are usually thoroughly tested. And usually the main source of problems is the non-use by companies of fresh fixes of various plugins used.
With cloudy headless-CMS you will always have the latest version. CMS is hosted directly by the vendor, who knows both the code and the infrastructure, and can pay appropriate attention to security issues.
In certain situations, this was a fair remark. The most traditional CMS was intended to be used as a central platform on which everything should be built. This meant that your application code was closely linked to the CMS, as illustrated above. You were limited by your CMS platform, programming language, update cycles, scalability, and security.
Not surprisingly, many software architectures could not follow this path! I had to create a proxy layer between the CMS and the application, or - a surprise! - write your own CMS.
Fortunately headless-architecture makes it easy to access the content through the API and write your applications as you want .
Many digital agencies continue to support their CMS for customers. Some do this on purpose, in order to bind customers who cannot simply switch to another agency.
In general, the use by agencies of their own CMS does not give any advantages. If they do not aspire to become CMS-vendors, then it is better for them to abandon self-written systems as soon as possible. Fortunately, many agencies already have an understanding that this is a dead end and that they cannot be competitive with proprietary systems. But they are afraid to jump into the unknown and transfer customers to standard CMS. In some cases, this is an emotional or political decision.. For example, if the CMS was written by the founder of the company many years ago, or it is the brainchild of the best developer, who, among other things, is also the only one who knows how it works.
My advice: take this bold step before your agency loses!
Choose a modern CMS and highlight the main advantages that will attract your customers to it. Finally, give your developers a new toy! Hint: most of them will fall in love with headless-CMS very quickly.
Honestly, there are still situations when using your own CMS is either advisable, or this is the only possible option:
• Content management is the basis of your business : if you are a company like Medium, then you probably need absolute control over the content management system. If you are a large publisher with dozens of publications, and you need a fully customized workflow, then you may also need your own CMS (or at least a custom editorial interface). However, in the world there are VERY few companies belonging to these categories and for which such investments are justified.
• Unique safety or compliance requirements: again, there are few organizations that have to adhere to specific rules when it comes to content storage, security, software architecture or infrastructure, and these rules do not allow the use of standard CMS.
If one of the above is about you, then remember that every hour spent on creating your own CMS is an hour that you could spend on creating a competitive advantage, and not on inventing a wheel .
People ALWAYS underestimate the amount of work to create a true CMS.
Perhaps at the first moment you thought: “ What is so complicated in CMS? I’ll just take the documented database and screw the editing interface on top . ” This is an easy start, but not yet a true CMS. When you start adding levels, such as content modeling, language options, workflow, permissions, content delivery, search, and so on, you will find that you are developing and managing a truly complex solution.
I hope now it has become obvious to you that writing your CMS is a lousy idea. This is a great programming exercise, but not the foundation of your business — unless you are a CMS vendor.
Writing your own CMS is like keeping an elephant in your home.
For most people, it's much easier to go to the zoo.
In 2000, I studied at the university and worked as an Intranet developer: I published content written in static HTML on the Intranet. This was my first “programmer" work, and I enjoyed it. Couple of weeks.
Then it became obvious how my duties are monotonous and non-automated. And I started writing an application on the classic ASP, which would allow users to independently manage content. I had no idea about the existence of such a thing as the Content Management System, and therefore invented a bicycle. At that time there were only a few commercial CMSoften costing hundreds of thousands of dollars. Given the prevalence and price range of this category of software, it is not surprising that I was not the only one who tried to reduce my inconvenience and increase efficiency by creating my own CMS.
By 2004, almost every Internet agency created its own CMS , often customizing it for specific customers. This led to dozens of modifications - a nightmare in terms of management. “This is pointless,” I thought. By that time, I had already written some specialized CMS and was bored again. “What about writing a CMS that can be useful for any site?” As a result, I organized Kentico Software, whose mission was very simple: create a CMS that any developer in the world can use to create any site .
Surprise: people still write their own CMS!
13 years later, I am still struck by the number of people who write their own CMS. There are many mature products for all types of projects: from open source to commercial systems of the enterprise level, from the best in its class to universal all-in-one.
So why does anyone still need to write their own CMS?
The answer is simple: people do this out of frustration .
Traditional web-based CMSs are fraught with limitations and limitations. But the truth is that all these disappointments have already lost their relevance . I know that sounds hypocritical. After all, writing my CMS helped me, so why doesn't it help others?
Let me explain.
Generic CMS deprecated due to headless architecture
Over the past 15 years, the CMS and technology market has begun to keep up with the changing digital landscape and user expectations associated with a wide variety of devices.
And today, a new generation of CMS technologies - cloud-based, with headless architecture - will soon revolutionize content management. Unlike traditional solutions, headless-CMS focuses only on managing content and making it accessible to any application through the API. Since such products do not have a “head” that usually dictates how content should be displayed, headless-CMS leaves the design question entirely to the developers.
Therefore, it’s not too wise to write your own CMS today - unless you want to become a vendor of such products. But it’s easy for me to speak. After all, I’m not the only one who has encountered many shortcomings and found many reasons why a self-written CMS can be a way out of the situation.
So let's look at the main reasons for the dissatisfaction of the developers and find out why they are out of date.
Reason # 1: standard CMS limits my creativity
The first thing that front-end developers complain about is CMS interfering with their HTML code and the need to look for workarounds.
But this is over: headless-CMS gives you complete freedom and does not affect the resulting HTML code. To extract content from the repository, you just need to call the corresponding REST API using your favorite programming language.
Moreover, you yourself completely decide how this content will be displayed!
Reason # 2: standard CMS interfaces are too complex
Many traditional CMS over the past ten years have grown significantly. Although they all started with the idea of providing a great content management solution, most could not escape the “creeping improvementism” because they infiltrated e-commerce, marketing automation, booking systems, email marketing and so on. Although it is convenient for someone to have everything in one place, it is difficult for new users to learn such CMS . Most only need to manage content; an excess of options reduces productivity.
The new headless-CMS is created on the basis of a different premise: this is just one of the fragments of the mosaic of microservices, and therefore these products have a user interface ,optimized specifically for content management . At the same time, modern CMSs provide content management APIs that allow you to create your own editing interfaces on top of their content repositories. This is convenient if you want to create a more specialized interface or integrate content editing capabilities into the application, rather than redirect users to another interface.
Reason # 3: standard CMSs are too expensive
" We did not want to pay X rubles for a commercial CMS, so we decided to write our own ." If you don’t need something much simpler than a real CMS (like managing a list of news), in the long run you won’t be able to save with a self-written CMS .
Today you can choose from a mass of free open source CMS , or use the cloud headless-CMS, whose pricing policy takes into account the characteristics of consumption , which will always be more profitable than developing and using your own system.
Reason # 4: standard CMSs are not secure
For many organizations, CMS security is a nightmare. Therefore, some developers think: " If we write a CMS, then hackers will be harder to find bugs in it ."
Classical security through obscurity (security by obscurity).
Yes, hackers can take advantage of well-known security holes, but widely used CMSs are usually thoroughly tested. And usually the main source of problems is the non-use by companies of fresh fixes of various plugins used.
With cloudy headless-CMS you will always have the latest version. CMS is hosted directly by the vendor, who knows both the code and the infrastructure, and can pay appropriate attention to security issues.
Reason # 5: standard CMS do not fit into my architecture
In certain situations, this was a fair remark. The most traditional CMS was intended to be used as a central platform on which everything should be built. This meant that your application code was closely linked to the CMS, as illustrated above. You were limited by your CMS platform, programming language, update cycles, scalability, and security.
Not surprisingly, many software architectures could not follow this path! I had to create a proxy layer between the CMS and the application, or - a surprise! - write your own CMS.
Fortunately headless-architecture makes it easy to access the content through the API and write your applications as you want .
Reason # 6: many clients still use the CMS we wrote
Many digital agencies continue to support their CMS for customers. Some do this on purpose, in order to bind customers who cannot simply switch to another agency.
In general, the use by agencies of their own CMS does not give any advantages. If they do not aspire to become CMS-vendors, then it is better for them to abandon self-written systems as soon as possible. Fortunately, many agencies already have an understanding that this is a dead end and that they cannot be competitive with proprietary systems. But they are afraid to jump into the unknown and transfer customers to standard CMS. In some cases, this is an emotional or political decision.. For example, if the CMS was written by the founder of the company many years ago, or it is the brainchild of the best developer, who, among other things, is also the only one who knows how it works.
My advice: take this bold step before your agency loses!
Choose a modern CMS and highlight the main advantages that will attract your customers to it. Finally, give your developers a new toy! Hint: most of them will fall in love with headless-CMS very quickly.
... and two reasons when using a self-written CMS is warranted
Honestly, there are still situations when using your own CMS is either advisable, or this is the only possible option:
• Content management is the basis of your business : if you are a company like Medium, then you probably need absolute control over the content management system. If you are a large publisher with dozens of publications, and you need a fully customized workflow, then you may also need your own CMS (or at least a custom editorial interface). However, in the world there are VERY few companies belonging to these categories and for which such investments are justified.
• Unique safety or compliance requirements: again, there are few organizations that have to adhere to specific rules when it comes to content storage, security, software architecture or infrastructure, and these rules do not allow the use of standard CMS.
If one of the above is about you, then remember that every hour spent on creating your own CMS is an hour that you could spend on creating a competitive advantage, and not on inventing a wheel .
Do not write your CMS until an obvious business case arises.
People ALWAYS underestimate the amount of work to create a true CMS.
Perhaps at the first moment you thought: “ What is so complicated in CMS? I’ll just take the documented database and screw the editing interface on top . ” This is an easy start, but not yet a true CMS. When you start adding levels, such as content modeling, language options, workflow, permissions, content delivery, search, and so on, you will find that you are developing and managing a truly complex solution.
I hope now it has become obvious to you that writing your CMS is a lousy idea. This is a great programming exercise, but not the foundation of your business — unless you are a CMS vendor.