Never Use a Traditional CMS to Back Your Applications!
Never Use a Traditional CMS to Back Your Applications!
In this post, we take a look at the drawbacks of using a traditional CMS to back your web applications, and examine a different solution.
Join the DZone community and get the full member experience.Join For Free
Almost every application today, regardless of the delivery technology and channel (web, mobile, kiosk, etc.) has content in it. Smart developers quickly realize that managing the strings and the other content should be done outside the application rather than embedding it in the code base. Rather than build custom databases and authoring tools most developers look for a Content Management Systems (CMS) to fill this need. But there’s a problem with that…
Traditional CMS technologies (WordPress, Drupal, and many others) have an architecture and approach that was designed and built over 20+ years ago. Let that sink in.
How can something built over 20 years ago or even something that was built “today” but that maintains the same basic pattern that was introduced over 20 years ago possibly be the right answer for today? It can’t. Here are just a few of the issues:
- They are built with older technologies like legacy PHP, Struts, Sling, and JSPs, etc.
- They don’t scale easily/cost effectively because of shared content stores based on SQL and Java Content Repositories (JCR).
- They are monolithic. Most systems couple authoring and delivery which makes the system complex to maintain, hard to secure, and even more difficult to scale.
- They mandate rigid development and theme frameworks that slow down and limit innovation.
- They make it difficult to roll out new functionality through your DevOps process.
- They are full of bolt-on solutions to keep up with today’s needs like Content as a Service (CaaS). Remember when they were designed, the world was just web pages. You can’t teach an old dog new tricks.
- Because of their heritage as page-centric platforms, they lack flexibility.
Who in their right mind would put a technology with all that baggage in their application architecture?! Don’t do it. Just don’t.
So what’s the answer? Back to building custom databases and editorial tools? No.
To solve this problem a class of CMS solutions has shown up in the so-called Headless CMS. These solutions provide very basic content management and deliver the content as an API. This capability is called Content as a Service (CaaS). Many of these are available only as Software as a Service (SaaS) solutions in the cloud. These solutions solve some of the problems that traditional CMS solutions have by moving all presentation and development responsibility to the consumer (outside the CMS) and making scalability a vendor issue.
If all you need is “headless content”/CaaS and public cloud/SaaS vendors are a viable answer for you, then you may have a solution.
However, many situations call for a solution that includes, but goes far beyond, headless content — templates, personalization engines, queries, and other key CMS capabilities are still needed by most solutions. Further, some companies still require on-premise installations. For these organizations, the field of viable solutions is much smaller. They need a fully featured CMS platform without all the baggage — one that that has been completely re-architected and re-oriented for today’s high rate of innovation/iteration and digital experience challenges. That’s where Crafter CMS, an open source, Java-based, enterprise-grade CMS really shines.
Crafter CMS is not a traditional CMS. Crafter CMS is a new platform built on modern technologies and a completely different architecture that is designed for situations that require rapid innovation, flexibility, enterprise integration, and extreme performance and scalability.
How is Crafter CMS different from traditional CMS technologies? Here are 10 reasons why:
- Crafter was built to manage any kind of digital experience and related content. Unlike legacy CMS software, it’s not page centric.
- Crafter is built with today’s most modern enterprise friendly technology like Java, Groovy, and Spring, Git and Apache Solr.
- While Crafter CMS has a lot of built-in services and capabilities it doesn’t add or enforce a lot of frameworks. Developers leverage existing skills for familiar technologies rather being forced to learn and use platform/vendor-specific technologies, and frameworks.
- Coding support for Groovy and Freemarker scripting removes the need to for heavy coding and deployment cycles.
- Crafter fits seamlessly into your development and DevOps process. Finally, there’s a CMS available that is not only powerful from a development perspective but that also plugs into your development process!
- Crafter is a decoupled CMS with separate authoring/management and delivery capabilities that are built on a microservices architecture.
- Crafter is blazingly fast. Rather than using databases and JCR repositories that are fundamentally slow and difficult to scale, Crafter uses an in-memory database, disk, and Apache Solr for content storage and retrieval.
- Crafter is horizontally scalable. Experiencing a huge surge in “traffic”? Just add more nodes. There’s no database to scale behind Crafter’s delivery tier. Further, because Crafter uses simple but powerful technology to drive dynamic content, a single server can do a tremendous amount of work. That means fewer servers are required to get the job done. Fewer servers translate to less infrastructure, less labor, less cost. Huge win.
- Crafter is geographically scalable and can even serve content in remote or disconnected environments. No databases. No clusters. No problem.
- Crafter CMS is battle tested and powering content and experiences at many of the world’s top brands and most innovation-forward companies.
Separating content from code is a smart move. Betting on a traditional CMS to try and make it happen when you need development agility and scalability is a dumb move. Check out Crafter CMS! It’s a totally new take on what a CMS platform should be!
Published at DZone with permission of Russ Danner , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.