Developers

Learn how to build better digital experiences

Dawn Foods: What's in your stack?

Learn what technologies Dawn Foods uses to modernize its digital and e-commerce strategies, and how Contentstack makes it all work seamlessly.

Power productivity: Thinking composable? Think workflows

Dhaval Majithia, Product Manager at Contentstack, explores the essence of workflows for content creators to understand their importance in digital management and their role in enhancing team productivity.

How to secure your composable DXP

Matt Black, Director of Information Security at Contentstack, explores essential security practices for safeguarding your composable DXP, focusing on user management and API token strategies within an enterprise headless CMS environment.

Building a scalable DXP - Part 3

In parts one and two, we covered the basics of building a scalable DXP and how to scale your DXP. In taking on the initiative to scale your DXP, it is fundamentally important to know why you are doing it. Let’s dive in. Why should I scale? If building and scaling your DXP sounds like a lot of work and critical thinking, it is. So why should you do it? You may be enticed by the revenue you want to increase or the costs you want to decrease, but if your reasoning only extends to cash flow, you will open yourself and your company up to potentially bad decisions.  Of course, any sound strategy you take with your digital experience platform (DXP) ought to lead to increased financial returns on your investment and effort, but that is only one of many potential outcomes. If those additional returns aren’t quickly felt by the team undertaking the work and feeling the brunt of the change process, such as in a bonus strategy or revenue share, then those returns won’t be durable enough to instill a lasting approach to scalability in your digital organization. A DXP puts the customer first The first reason you want to build a scalable DXP is for your customers. Adopting a scalable approach will allow you to reach them better, faster and more efficiently. It will allow you to continue to evolve your mission and increase your engagement with your audience. Scalability for your DXP means your customers can efficiently interact with your brand, including sales, support and even your community of customers. It means that orders are accurate and filled quickly. It means that the latest and greatest news and information from your company are always right there ready for your customers to experience in their preferred context.  Create and manage more content It also means that you can create and manage more contexts. Consider a traditional monolithic CMS that is designed purely for publishing on the web. Perhaps you’ve cobbled together bold-on API solutions that allow you to publish simultaneously to the web and your mobile application, and perhaps you’ve optimized a slew of copy-and-paste processes to their maximum efficiency. But adding another distribution channel, say, a voice app or integration with an IoT device, feels like months, if not years away from your present state.  Now consider how replacing your monolithic CMS with a headless CMS would tear down walls for your team, allowing your content managers to focus on crafting delightful and optimized content while your designers and developers focus on the presentation of that content in numerous contexts. Unlock the potential of your people This leads us to the second main reason you want to scale: your people. Time not spent copying, pasting and emailing content and collateral is time that is available for ingenuity and innovation. As you unlock scale within your DXP, you free up your team to focus on the areas where they can create real value, which is typically a rewarding and uplifting result in your staff’s day-to-day work. Although it may be tempting —and at times, necessary — to optimize and scale your DXP or other business processes to reduce team size, that should rarely, if ever, be the sole motivating factor for pursuing scalability.  Instead, pursue scalability across your organization and DXP as if you are upgrading everyone’s daily lives or giving them a new suit of clothes to replace the old ones that don’t fit so well anymore so that they can do their very best high-value work. Your team will thank you for setting them free, and your customers will thank you for the ease with which you provide them with your services. After all, businesses are run by people to provide goods and services for others, and meeting the needs of both groups of people efficiently and optimally is the definition of good business, which inexorably leads to growth. A scalable DXP drives business growth   While many companies are fortunate enough to achieve growth, not all of them can achieve scale. Often what holds a business back is more the result of how teams look at their internal systems and processes than it is about market conditions. In fact, by looking deeply and understanding the end-to-end processes within your organization, you have the potential to actually drive demand by making your products better and cheaper than your competitors. This is precisely the outcome Ransom Olds achieved for Oldsmobile in 1901 when he implemented the first automobile assembly line and increased output by 500% in one year. Today, blazing-fast mobile connectivity, the Internet of Things (IoT), and new devices on the market all point in the same direction: the number of places where your customers expect to engage with your brand online is growing, which means that your capacity to meet them there should also be growing if you want to maintain your competitive edge. By understanding the assembly line that makes up your DXP, you can see each system and step in your publishing process clearly, which will allow you to make intentional changes in your core technologies and people processes that will unlock scale. We are fortunate to be at a time when there have never been so many tools and options available to optimize and scale your DXP. From back-of-house big data, inventory and digital asset management tools to headless CMS, automation tools and instantaneous publishing on CDN geographically close to the user, the ability for digital teams to reassess their DXP implementation and optimize for scale has never been more within reach for everyone. Equipped with a firm grasp of what it truly means to scale and the steps outlined above, you and your teams should now be ready to unlock efficiencies that have previously held you back and embark on the exciting journey of scaling your DXP. Learn about our Developer Fast Track to see how you can start building today.

How to Fast Track Composable Digital Experience Development

Eric Broadwater, Senior Product Manager at Contentstack, explains how the Contentstack Developer Fast Track helps developers better evaluate and overcome the potential obstacles of transitioning to a composable architecture.

Building a scalable DXP - Part 2

Let’s start with a shared definition of the territory. Gartner has a nice definition of a digital experience platform (DXP): “A digital experience platform (DXP) is an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.”  There are three main aspects of this definition, each of which can vary depending on the specific needs of an organization:  The set of core technologies The content management processes The digital experience context Let’s unravel each of them separately. Core technologies of a DXP The core technologies of a DXP consist of things like a content management system (CMS), customer relationship management system (CRM), digital asset management system (DAM), inventory management system, website, web host, payment processor, mobile application and so on. Core technologies also include any code you write or maintain, DevOps, backups, redundancies, and the technical support required to maintain them.  The technologies that make up any given DXP typically take center stage in an organization, and staff can usually list several of them by name even if they aren’t on the digital team because, collectively, these technologies tend to touch almost every person in a modern organization in some way. Content management processes of a DXP Content management processes are a mix of automated and manual steps that transform, augment and assemble media from ideation to publication. These processes will vary widely from one organization to another, but they typically include things like selecting and editing images, writing and editing content, and updating and maintaining inventory data, like prices and product descriptions. Depending on the size and configuration of your digital team, content management processes can span across multiple teams, each providing their own expertise and applying their craft along the line from ideation to final publication.  While these processes are typically powered by people, they will also often include automated steps leveraging the core technologies mentioned above. For example, a photographer may manually capture several images for an upcoming article. When the photographer uploads the images to the DAM, the images are automatically resized, tagged and optimized for their publishing context, and an automated message is sent to an editor letting them know the images are ready to be used. The digital experience context of a DXP The contextual domain of the DXP refers to where the assembled content is published. Contexts include websites and parts of websites, social media, mobile applications, the Internet of Things (IoT), extended reality (XR) and more. The publication context is one of the more complex components of any DXP because of the variety of contexts in which a piece of content can appear, the amounts and myriad formats of data insights available for each context, and the limited visibility into the minds of individuals who are the end consumers of DX, where the content, context and technologies all come together to provide some sensory experience.  For example, one piece of content, like a blog or product entry, may appear in a mobile app, mobile website, desktop website, and digital display simultaneously, each with slightly different and nuanced requirements. Now that we’ve defined the space we’ll be exploring, we’re ready to begin building our scalable DXP. Most companies already have a DXP, so this process focuses on evolving your existing DXP to make it more scalable. The same principles apply to building a scalable DXP for a brand-new organization, but some steps you will need to come back to once you have your team in place. In general, it’s a good idea to come back to this process periodically because even subtle systems or structural changes can unlock new — or hinder existing — scalability over time. The 5 principles of building a DXP 1. Define your content and its components Taking a content inventory is the first step in implementing a scalable DXP. Your end-to-end DXP is a pathway for content to come together and be presented for your audience to experience, and ignoring the realities of the individual pieces that make up your content or that are needed to make it successful will ultimately inhibit scale. Think of content as anything you want your audience to encounter independent of the context in which they will experience it. Start by listing out each type of content, such as static pages, blog entries, product pages, etc. Then, list out the components that make up each of those types of content. Here, you want to capture details that show how the media is assembled for the end user. For instance, if a blog entry has a hero image, body text, excerpt, author and other metadata, document it. Likewise, if a product page includes five photos, a video, a 3D walkthrough, a price, a SKU and a call to action button, note these details, too. If your organization has a lot of existing content with a lot of variation, which is often true of large and growing companies, then you may want to consider creating one version of your inventory document reflecting your current content and dependencies and another version reflecting a more ideal and streamlined state. Similarly, if your business maintains hundreds of websites, you may only want to focus on one specific content segment in your organization, like your corporate newsroom or product catalog. A good rule of thumb is to try to keep your content inventory documentation simple and clear. At this step, you don’t need to list things like social media posts if those posts would just be redistributing content you originally published elsewhere, like on your brand website. The purpose of this step is to assess the breadth of your content and the components that comprise it, and to create an anchor for your team as you work toward a shared understanding of context and process. 2. Define your contexts Now that you have an idea of the content your team will be publishing, it’s time to document the contexts in which it will appear. In this exercise, start by writing down everywhere your content may appear to your audience. This document will likely include publishing destinations like the web, mobile apps, digital signage, social media, ads, mailing lists, voice UI, podcasts, etc., and it may also include subcontexts if there are important distinctions that affect content production for any given context, such as differently sized mobile devices, accessibility tools, and the variety of social media experiences. Contexts can become overwhelming very quickly; they include how content is presented through any device and how and when individuals interact with it, like in the morning or while driving. Because of this reality, the goal of this step is not to exhaustively list every possible context you can think of. Instead, focus on the contexts you can directly control that require significant differences in content assembly. For example, it might make sense for your list to include individual contexts for Twitter and Facebook because you actively craft different and unique content for each platform. But it may not be important for you to list iOS and Android as different contexts for your mobile website if the same technologies and content power both experiences. Referencing your content inventory, note which content appears in which contexts. While it’s common that most content appears in some fashion across each context, that’s not always the case. A voice UI app may read a blog post to your users, but the context doesn’t allow for images. Similarly, you may post blog entries that feature products to your social media accounts but opt not to post actual product page content on its own. The important insight to gather at this phase is the variety of contexts in which your content appears. This is important because content needs to be optimized for its context. For instance, the same blog hero image may appear across multiple contexts, but it may require different sizes when presented in each context to provide the best experience. It is a fundamental necessity to understand the content moving through your DXP to this level of detail. By having a firm grasp on your content’s components and the variety of contexts in which your users experience that content, you will be well equipped to design efficient systems and processes to create and publish that content. 3. Walk a mile Human-Centered Design (HCD or “design thinking”) is a powerful philosophy and rich set of tools that can empower any digital or technology team. One such tool is called a “walk-a-mile immersion”, which is the simple process of walking a mile in someone else’s shoes. Envision an assembly line where every step contributes some value to the end result of your content being published in a variety of contexts. The assembly line has stations where certain processes are performed by your team as components are created, put together, and modified before final delivery. In this step, you talk to each team involved in creating, editing and managing each content component. You get to know the systems in use, the scope of their functionality, and how the individuals on your team use the tools. If you are creating a new DXP or building a new team, then envisioning and jotting down hypothetical teams and content handoffs can work just as well. The goal of this step is to document each of the key steps and tools used along the path of creating your content, from ideation to publication. For example, if you maintain an inventory database, a DAM, a CMS, a CRM — or if you use desktop tools or a monolithic system — document all of them along with the nature of the work and effort involved in completing each step to produce your content. If ideation starts on a whiteboard and your content is published in five different places, document the steps, systems and effort required from the beginning to the end. At the conclusion of this step, you should have a clear understanding of your content and its components, the many and varied places your content appears, and the processes and systems your teams leverage to create, edit and publish content. 4. Analyze your assembly line By now, you’ve documented your content and contexts and have a map of the systems and processes required to take your content from ideation to publication. In this step, we analyze the content assembly line to highlight steps with high effort and low added value to set the stage for scalability. Start by looking for duplicative effort and content. For example, if your team has to create multiple different sizes of an image to publish in each of your contexts, or if your team has to perform manual, repetitive tasks that add low value and require significant effort, then these are opportunities for improvement. Look for how upstream ingredients, like product pricing and inventory systems, feed into your CMS and are married to descriptions, images, reviews and more.  In legacy DXPs, many of these steps and processes can occur in one or just a few systems, but modern DXPs will typically have various systems, allowing for specialized focus by team members at discrete touch points along the content assembly line. Identify steps and processes where teams typically report being blocked by other teams. Any team or process blocked by another team or a previous step in the assembly line often indicates that optimization is needed upstream. If the content publishers in the final step of your publishing process are always waiting or having multiple conversations for images to be resized, for instance, this step of the process is a potential opportunity for improvement.  Once you highlight areas with high effort, or “friction”, shift your focus to steps and processes that are efficient. For example, if you have a backlog of ideas that are waiting to be realized into articles or a backlog of products in need of descriptions, these surpluses likely indicate high efficiencies at these steps, which means other steps and processes could potentially improve to meet these efficiencies. At the conclusion of this step, you should have a clear picture of the end-to-end assembly line for creating and publishing your digital content, including all elements, assets, texts, metadata and other media coming together for final publication in each given context. You should clearly see each individual system used for each step in the assembly line, as well as every human process and general level of effort required along the way for a piece of content to be published.  For e-commerce DX, this might mean understanding the processes in the back-of-house where pricing and inventory levels are kept up to date, combining in a subsequent step to add ancillary product metadata and media, being checked in a following step for accuracy and legal compliance, and finally being deployed to a live site, where it is cached on a CDN for low latency access. For a media organization, your assembly line may instead start with ideation in a Trello board, followed by an outline, and then a draft, and finally combined with image assets and published in a CMS that feeds into a newsreader app.  The number of potential combinations of steps in creating an assembly line is virtually limitless, and at this time there is no single right way to structure these systems and processes. Though, as you may now be able to see in your assembly line, the number of wrong ways to do it is also myriad. 5. Strategies for scale Honing in on your digital experience assembly line and locating areas for improvement is enlightening, but without instituting real and intentional change, the friction remains. Now that we know where lie the strengths and weaknesses in our existing processes, how do we prioritize and implement changes that scale? If you’ve successfully completed each previous step, you should be able to readily identify two or three places in your assembly line that clearly stand out as higher effort or higher cost of input than other steps in your publishing workflow. In some cases, friction is expected, such as in the actual writing of articles or sending teams out in the field to gather photos or raw audio that must be edited by hand. In other cases, you may identify a step in the process that always seems to be blocked, such as a publishing team waiting on transcripts, translations, file format changes, image resizes, SEO metadata, and so on. Begin by prioritizing repetitive tasks. Any high volume of repetitions performed by a human often indicates that there is a more optimal process available. Examine the systems used at this step and determine if they provide the most up-to-date tools to perform these operations. For instance, many DAM and CMS solutions automatically resize images and store them in multiple formats optimized for various contexts. There are also very good tools that automatically transcribe audio and translate text into almost any language, which could significantly reduce these high-touch steps in your assembly line.  Optimizing your assembly line for scale will typically involve a combination of reorganizing processes and workflows to improve the pace of handoffs from one step to the next, along with updates to the core technologies your team uses to realize your digital experience. Composable DXPs are on the rise In recent years, there has been a trend toward composability, wherein digital teams are looking deeper into their publishing workflows in order to combine the best set of tools for each step of the process.  Composing a DXP is the opposite of purchasing one single off-the-shelf system. When you adopt a composable approach, you accept the reality that your business needs are unique, and it’s unrealistic to expect one or two products alone to offer everything your team needs exactly how you need it, given the variety of content and contexts your digital experience can take on.  The most essential need for the systems that make up your DXP is interoperability, which is often referred to as “API-first”. Application Program Interfaces (APIs) allow systems to talk to one another and share information in a safe and secure manner. For your business, this unlocks the possibility of automating hand-offs and removing blocks where content components are manually delivered to the next team for assembly. Webhooks and automation tools leverage APIs and are extremely handy to let you remove rote human-powered processes and exchange them for more efficient machine-driven processes.  Headless CMS is another popular solution, which focuses the content management in a single-purpose powerful solution designed for managing and shipping your content to virtually any context without needing to make any changes to your core systems — you simply deploy a new app, website or other technology that safely consumes content via your APIs. Where you find one single product doing most of the work in your assembly line, chances are that there is high friction between it and any adjoining steps in your publishing workflow. These systems also sometimes lead to siloed teams and ivory tower cultural friction between those with access to the monolith and those without access.  Benefits of composable solutions By replacing a monolith with a multi-product platform with focused independent interconnected tools or a variety of API-connected solutions that focus on doing one or just a few things extremely efficiently, you hedge against siloing and begin to move in the direction of more streamlined processes.  Moreover, many composable solutions are extendable, meaning that you can integrate them with other systems in a few clicks or lines of code. And if one solution becomes too costly or fails to unlock the efficiencies you are looking to gain, then it can be relatively easily replaced without the need for a wholesale migration or hugely disruptive technology change. What’s next? Unlock the scale of your DXP When you complete this step, you ought to finally have the complete picture of your end-to-end digital assembly line, along with each system, team and process that must work in concert to create and deliver your digital content across your chosen contexts. From this vantage point, you can easily identify where scale is blocked and where it is already well established, as well as which areas stand out as the highest priority to optimize first. You will be ready to begin taking action to unlock the scale of your DXP. In part three, we will cover the only question left to answer: Why should you scale? Stay tuned! To read part one, click here.

Power Productivity: Previewing digital experiences in a headless environment

Seeing is believing. Learn how comprehensive, live previewing of digital experiences can streamline workflows and supercharge productivity for creative and dev teams.

How content modeling powers creative teams and unburdens your dev team

As software engineers working in marketing, you're constantly seeking ways to easily deliver fresh, engaging content. One solution to this challenge is leveraging composable technology and a headless CMS, which can improve content modeling and significantly reduce repetitive tasks. In this post, we'll explore content modeling, how it works, and its benefits for your development team.What is content modeling?Content modeling is the process of defining the structure of content types and their relationships within a content management system (CMS). By organizing content types, properties and relationships, developers can create reusable templates to streamline the creation, management and delivery of content.A headless CMS plays a pivotal role in content modeling, as it decouples content delivery from presentation, allowing for more flexibility and scalability. In concert with a MACH architecture and composable technology, a headless CMS empowers developers and creative teams to build engaging content rapidly.How content modeling worksContent modeling follows a few key steps:Define content types: Identify the various types of content your organization creates. These can include blog posts, landing pages, product descriptions, etc.Specify properties for each content type: Break down each content type into attributes (e.g., title, author, image, etc.) and define the data types associated with them.Establish relationships: Map out relationships between different content types and properties, enabling content reuse through global components and streamlining the content creation process.Create templates: Use the content models to build reusable templates within the CMS. These templates help maintain consistency and simplify the content creation process for your team.Integrate with front-end technologies: One of the key benefits of content modeling with a composable tech stack is the flexibility to choose front-end technology that works best for your organization.Benefits of content modelingThere are plenty of reasons why you should consider content modeling for your development team:Efficiency: Developers and creative teams can quickly generate and manage content by using predefined templates and structures, drastically reducing time spent on repetitive tasks and reducing human error.Scalability: The MACH architecture enables seamless scalability, so teams can easily adapt to changing circumstances or expand their content needs.Flexibility: Headless CMS allows for more freedom in the choice of front-end technologies, ensuring developers can create omnichannel content experiences.Consistency: Predefined content models help maintain a consistent look, feel and structure for all content, reinforcing brand image and identity.Collaboration: Content modeling bridges the gap between developers and creative teams, fostering better communication, understanding and collaboration in the content creation process.Embracing content modeling can unburden your dev team and enable seamless content creation across all channels, keeping you ahead of the competition. By integrating a headless CMS, MACH architecture and composable technology, your team can deliver engaging, personalized and visually appealing content experiences, fueling your growth and innovation.

Putting the AI in Retail: Exploring its full potential with EPAM and Aprimo

Learn how retailers can create personalized, interactive digital experiences at scale by augmenting their composable tech stacks with generative-AI.

How retailers can create better digital experiences with composable technology

Learn how retailers can meet customers' demands for a fast, modern, secure and engaging online experience with composable technology.

Building a scalable DXP - Part 1

Scale is one of the most common and fundamental problems digital teams have to confront in order to grow their businesses. But more than just a key to unlocking growth, how a team thinks about scale can affect costs, ongoing resource capacity, feature roadmaps, and even an organization’s overall pace of innovation.  In the universe of digital experience (DX), which spans all the way from the devices at the frontier of your audience’s senses all the way to the cloud and hardware that powers your company’s back-of-house operations, scale applies in some way to nearly every facet between these two ends. Understanding how the systems, people and processes that make up this end-to-end DX assembly line fit together and affect each other is key to unlocking that scale. This article aims to explain how to scale your digital experience platform (DXP). In it, we will discuss the meaning of scale, how to approach scale within your organization, and why it’s important.  What exactly does it mean to scale? Simply put, scale is the relationship between the inputs and outputs of a given system. When people refer to scaling a business, they are typically talking about increasing outputs, like sales and revenue, while holding constant or decreasing inputs, like costs and materials.  In an engineering-oriented team, scale often refers to hardware and software, such as the ability to flex or expand capacity to process more operations. If you work on a content or marketing team, scale usually refers to growing your audience, increasing engagement, and publishing more and better content. On the business and leadership teams, scale usually means increasing revenue. But these definitions of scale are oversimplified because they focus only on the outputs of these systems while ignoring the inputs. Or to put it another way, when we are talking only about increasing the outputs of a system, we’re talking about growth. When we talk about increasing outputs relative to the inputs, we are talking about scale. A “scalable” case study Consider a digital agency as a hypothetical case study. The agency builds highly engaging promotional websites, and its revenue is directly tied to the number of websites it can implement for its customers. Let’s assume the agency is high touch and that each website takes a total of 1,000 hours to successfully design, build and launch.  Let’s also assume that the agency employs 10 people, for a total of 20,000 available hours per year (ignoring PTO) and enough resources and the proper staffing configuration to successfully sell and deploy a maximum of 20 new sites per year. A blunt approach to scaling this business model would be to demand more than 20 sites out of the talent. In this approach, leadership sees the staff as the enemies of scale and demands more output from them in the form of working faster and staying late to meet aggressive goals. Indeed many companies attempt this strategy at the cost of talent attrition, sloppy work, constant training of new employees, missed deadlines and lost customers. Launching just two additional sites per year would require every employee to work an average of about one extra half-day every week of the year, leaving scant time for family as well as the occasional urgent customer support request. Another approach is hiring additional talent and slowly scaling up output while demand catches up to the newly increased capacity. Although this approach is common, it comes with the risk of increasing investment before increasing revenue, and when applied responsibly it can take some time to pay off. Leaders who choose this tactic will hire, say, two more staff with the aim of selling and launching about four additional sites per year. While this approach is intuitive, once the full cost of two FTEs, the opportunity costs of training them, and the revenue from four additional sites are factored into the balance sheet, it’s easy to see that this approach could be slow to take off and perhaps actually decrease the agency’s profit margin over time if it doesn’t go well. Now consider a third approach, where leadership recommends that each team looks for opportunities to repurpose generic work developed for other customers in order to reduce the number of hours required to implement new websites. Over the course of building the next few sites, the teams are able to develop reusable components of their work, for example, in the form of code and design libraries for commonly requested solutions, which in turn results in an average reduction of 200 hours across all website deliverables. This means that the agency can now produce 20 sites of the same or better quality in only 16,000 hours, which increases output capacity to 25 websites in the same original 20,000 available hours without adding staff or increasing costs. Scale smarter, not harder While each of these three examples are strategies for how an agency might approach scaling up output, the third example is a clear frontrunner because it has the highest impact on increasing output while at the same time holding inputs relatively constant. The third approach is also the only example out of the three that can lead to economies of scale. Economies of scale describe the state of a relationship between an input, such as cost per unit, and an output, say, the number of units produced, where the cost per unit actually goes down as you create more units. This relationship between inputs and outputs is what people typically mean when they say they want to scale something. It is not just that they want outputs to grow, but that they want outputs to grow and the cost of inputs to stay flat or decrease at the same time. Although this case study centers around an agency and looks at three simplified approaches to scaling the overall business outputs, it’s useful to shed light on the fundamental concepts of scale before unpacking the specifics of scaling a DXP. Here we’ve highlighted two essential tenets that will benefit digital leaders as they work to scale nearly any system:  There are many ways to approach a problem of scale, some sustainable and some unsustainable. Scaling on the backs of employees, for instance, is not a sustainable approach. There is nothing wrong with hustling to achieve a goal, but hustle alone lacks the strategic thinking that unlocks scale, which leads us to our second tenet. Effective and durable scaling centers around creativity and is founded upon understanding — not brute force. But don’t be discouraged if you feel you or your team lacks creativity or your processes are too complex for anyone to understand. As we will see in the following articles, there are some tried and true methods for creating the conditions for creativity to emerge, and if you apply them with your teams you will have a higher likelihood of successfully achieving scale, no matter what it is you wish to scale. What’s next? Now that we’ve established a baseline understanding of scale, in Part 2 we will set the agency example aside and explore specifically what it means to scale a DXP. Stay tuned!

How to build the composable DXP you’ve always wanted

Michelle Grady, Senior Product Manager at Contentstack, shows us how the modern enterprise can leverage our ecosystem of composable partners to build the digital experience platform that uniquely suits their business needs.

How to simplify tech stack integrations

Christine Masters, Contentstack Senior Product Manager for Emerging Products, talks about composable and how integrating the right SaaS solutions for your application can take time. She gives a behind-the-scenes look at how Contentstack’s Automation Hub significantly simplifies complex integrations with clicks, not code and the multiple ways it can be used to save time.

Headless commerce vs. composable: What you need to know

The online world is constantly evolving, so companies must change how they work and develop new ideas to meet customers' changing needs. The e-commerce sector has witnessed the rise of two unique models: headless commerce and composable commerce. While they might appear similar at the outset, a deeper examination reveals critical distinctions. In this article, we'll demystify the two approaches, spotlight their respective pros and cons. And provide insights for organizations pondering a transition to a composable architecture. How headless commerce began In the early days of online shopping, businesses had two ways to sell their products: physical stores and online platforms. But as technology advanced, many companies didn't keep up with the changes. This made it hard for them to stay up with what customers wanted and take advantage of new trends. The problem was that their technology wasn't flexible enough to adapt to new ideas. To serve customers better, stores began separating their online behind-the-scenes system from what the public sees on their websites. They did this by using APIs to access the back end, which made their operations more flexible. Headless commerce is a way for brands to keep their complicated commerce systems while making the front end more flexible to changes in the market. Composable architecture means that each part of the system works independently and can be customized to fit a brand's specific needs. This gives businesses the power to choose which parts of their digital services to use to meet their unique business requirements best. Examining headless commerce architecture Headless is a new way of handling e-commerce that separates the parts that users see (the interface) from the parts that do the work behind the scenes (data, operations, applications). Most e-commerce systems combine these two parts, making it hard to keep up with the constantly changing digital market. Headless, by contrast, allows the front- and back-end systems to function independently.  Benefits of headless architecture Adopting a headless system introduces several advantages: It delivers a flexible and customizable front end. With the visual layer decoupled, developers are no longer tied to the constraints of the back end, allowing for the creation of custom user experiences.  It enables seamless integration with other systems. The back end operates independently, communicating simultaneously with multiple front ends. This allows businesses to provide a consistent omnichannel experience across various platforms like websites, mobile apps, smartwatches, and IoT devices. For instance, should a brand face difficulties in producing content for new products due to the constraints of its content model, the headless commerce system allows the integration of a different content management system with adjustable content models. This flexibility ensures a smoother operation by effectively mitigating the identified issue. It accelerates the speed of innovation. Changes to the front end won't impact the back end, and vice versa. This promotes quicker updates, experiments and iterations, all critical components in today's fast-paced digital landscape. Drawbacks of headless architecture While headless offers clear benefits, it also carries some drawbacks: This way of setting up a system can be challenging to handle. It needs someone with technical knowledge to take care of the different parts and keep them working. While the freedom to customize front-end interfaces is a benefit, it also means that businesses are responsible for designing and developing these interfaces, which can be time-consuming and costly. Depending on the chosen system, limited support or functionalities may be available. Understanding composable architecture Composable is an approach to building digital services that allows each component to exist independently. This includes things like managing product information, content and customer relationships. Businesses can choose which parts they need to create a custom digital platform. Advantages of composable architecture Composable e-commerce offers significant advantages. It provides extreme flexibility. Since all components are separate, they can be independently updated, replaced or reconfigured, enabling a truly agile e-commerce platform. This architecture allows for continuous optimization without fear of disrupting the entire system. Composable future-proofs your DXP stack by implementing task-oriented packaged business capabilities (PBCs), which are essential for faster time to market and better adoption of a digital experience. With the ability to add or replace components as needed, businesses can keep pace with technological advancements, customer demands or changes in business strategy. It promotes the best-of-breed approach. Businesses are no longer confined to the capabilities of a single vendor. They can select the best software for each component, maximizing functionality, efficiency and performance. Pivoting toward composable architecture: Points to ponder Embracing composable commerce vs. headless architecture is a significant decision you should not take lightly. Businesses should thoroughly analyze their current and future needs, evaluating whether the flexibility and adaptability of composable commerce align with their strategic goals. The appeal of composable architecture lies in its flexibility and potential for success. However, it's important to remember that just because something is possible doesn't mean it's a good idea. Composable architecture can be compared to Lego blocks, as it allows for the creation of many different structures. But the challenge lies in deciding what to build and how to make it happen. The challenge is twofold. First, there's the job of putting together all the components. Second, it's essential to ensure that each element chosen is not just a fun extra but helps create the desired digital experience is essential. It's crucial to tell the difference between the "must-have" and "nice-to-have" features. Focusing too much on the latter can take away your IT team's attention and resources from the essential functions. It's important to think about how much technical knowledge is needed. Composable gives you a lot of choices for customization. Still, it takes a skilled technical team to handle everything and ensure it works well. If you're thinking about using composable, you should ensure you have the right resources or get help from experts to make it easier. Additionally, companies must evaluate their current system's limitations. Are you finding it challenging to innovate due to a rigid, tightly coupled e-commerce platform? Does your business plan to expand into new channels or markets that your current platform cannot support? These pivotal questions can help determine if the transition to composable is warranted. When picking technology partners, it's crucial for organizations to choose carefully. The best partners will offer a variety of components that can be easily swapped out and will provide support and updates over time. The goal is to create an e-commerce platform that can grow and change as the business and customers do. Learn more Learn more about transitioning to composable in this episode of "Contentstack LIVE!" featuring Contentstack Vice President of Technical Solutions Pete Larsen. Schedule a free demo to see how Contentstack's composable digital experience platform can help your organization achieve its e-commerce goals.

The beauty of a composable digital experience platform: It can be whatever you need

Have you ever tried designing a website from a template? It can be challenging. First, there are so many options to scroll through (that all somehow look the same) your head will spin. When you do pick a template, you have to build it the way you want, meaning a lot of customization. When that doesn’t work — because inevitably, you always hit the end of what the template can offer — you have to puzzle your way through custom code. That can become a tangled web very quickly.Imagine that process for an established enterprise like Sephora or even a fast-growing start-up. Think about the manual process of integrating each tool needed for e-commerce or inventory management. You think you are “done” building,  but wait — the market is evolving and you need to start selling on a new-ish platform like TikTok or BeReal.A traditional legacy CMS environment is tricky: Change one thing and you risk the entire machine stalling. The beauty of composable architecture is that your website can become whatever you want, whenever you need it — easily. Jurre van Ruth, digital strategy consultant at PostNL, came on our podcast, “People Changing Enterprises,” to discuss how the company took that concept to heart and made their composable DXP work for them. But to make it work for your company like PostNL did, we need to level-set definitions and expectations. There’s a lot of confusion in the market about composable architectures — like what is a “composable DXP” in the first place — that I want to clear up. What is a composable DXP?I like how van Ruth said it in the podcast: “We see [composable] as an ecosystem of technologies that aim to create and offer a consistent digital experience for all our customer segments across all digital touchpoints.” I specifically love the word "ecosystem" he uses. CMSWire describes a composable DXP as providing “integrated, consistent solutions that are modular and tailored to microservices and yet connect the gaps of digital experience. This is a unified and seamless approach that eliminates siloed user experiences and all-in-one solutions.”To further flesh out that picture, I often describe composable architecture as a Lego tower: Each block is a tech tool and they each function together to make up one, larger tower, aka the customer’s digital experience. However, unlike a sculpture — or legacy enterprise suites — you can more easily change the look and function of the entire tower by swapping out each block within. For example, if your next marketing goal is to target potential consumers with more personalized advertising and content, those tools are easier to plug into a composable environment than traditional suites. Creative teams get to pursue the digital experience platform of their dreams, and there is much less frustration, less custom code and fewer heavy integration requirements for IT to handle on the back end.Then where does headless — AKA a headless CMS like Contentstack — come in? It’s simply a cornerstone block in your Lego tower. For a marketing environment, the headless CMS acts as a foundation. Every tool — like e-commerce, automated translation, or SEO tools — can integrate into it to make content the central hub of your ecosystem.Moving beyond one-size-fits-allEvery enterprise is different, which means that the capabilities they need will also be different. However, when it comes to traditional legacy martech systems, it tends to be one-size-fits-all. The problem is that one size actually doesn’t fit all, and those environments are slow and difficult to change. It takes extreme customization via code, contacting multiple vendors for help, and a lot of inter-dependencies that aren’t always caught until something breaks.  One of the best benefits of composable is that integration is much easier and more natural with APIs inherent to a composable environment. Like clicking a Lego into place, that tool is now part of the environment. For PostNL, they invested in tools for headless content and digital experience analytics, which were easily plugged into their composable environment.An e-commerce enterprise can integrate all the tools they require, whether it’s an online storefront platform, a product catalog with elements like descriptions or visual assets, or any personalization tools it might need. But, for example, a hospitality service will need a different set of tools, and they can have them inside a composable environment.Enterprises are no longer satisfied with a one-size-fits-all approach. The beauty of composable architectures is that, in a market that changes like the wind, organizations’ digital experiences can also evolve just as easily.

Eliminating friction and delays in digital experience delivery

Dean Haddock, Contentstack Senior Product Manager, discusses the main components behind delivering digital experiences at scale and Contentstack Launch, our new front-end hosting solution, can rapidly increase delivery rate

3 ways tech and business teams can help each other through a transformation

Not all great tech transformations are brought to the table by a developer, engineer, CTO or other technical person. We see great projects kick off because someone in marketing, sales or customer success raises the flag for change. Sometimes business people can see opportunities that aren’t as plain to the tech teams.That’s what happened when Booking.com decided to transition off its old systems to a headless CMS. Juliette Olah, senior manager of Editorial, realized that her teams had produced thousands of pieces of content over the years — but the capabilities of their current technology significantly limited the value that content produced in their local markets and possibilities for the future.Listening to her “People Changing Enterprises” episodes, I admired the way Juliette united Booking.com’s product and editorial teams from the beginning to pull off their transformation. Business and tech can either be each other’s biggest advocates or frustrating roadblocks.To avoid the latter, these are three examples of how tech and business teams can support each other throughout a transformation.Thoroughly debrief at the onsetAt the beginning of every project, we encourage organizations to sit down with their cross-functional teams and level set. Business and tech have their own KPIs and goals to achieve. In a project that bridges the two, there should be a frank discussion, ending in clear, written requirements of process and goals for both sides.Once Juliette realized a tech transformation was the answer to the editorial team’s needs, she became the living bridge between the editorial and product teams. Sitting down with tech stakeholders, they talked through what Juliette called a “comprehensive 360 view of the benefits to the technical side of the platform”:The editorial team’s strategy and the justification behind the new technologyReal-life examples of what execution would look likeThe business value of a central headless CMS would bring to each local marketOpportunities they were currently missing out on because of their current toolBecause she had clearly done her homework and demonstrated the need on both sides, the product team was eager to get started.Partner up to find and test new toolsFinding and testing new tools is an easy way for business and tech teams to partner effectively. When the new CMS was in place, the teams at Booking.com partnered to try out the new tool to make sure it worked for both sides.At Contentstack, once a new solution is initially developed, we pull in our business partners for User Acceptance Testing. They can test, catch bugs, or point out which workflows function trickier than anticipated — versus the tech teams doing it all themselves.Additionally, when you’re on the hunt for new tools, tag a business partner in for their opinion. From a different mindset, they might be able to raise questions or point out benefits you didn’t consider. Work together to phase out what isn’t neededA transition to composable is the perfect time to evaluate what tools you’re bringing into the new environment — and which ones you should retire. This is another area that tech and business teams should work together.A few years ago, we bought an analytics tool for the organization to use on their reports. It was low-cost and met some of our needs upfront, so we decided to take a chance on it. Six months down the road, we were spending a huge amount of time trying to force the tool to work. When a business person came to me and admitted the tool wasn’t helping their team meet their objectives, we decided to look into something else. On a composable project, it’s not always clear on the back end if a tool is working for teams as they need. That’s where our business partners come in. It’s a partnership.Babe Ruth once said, "The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don’t play together, the club won’t be worth a dime."It’s easy for business and tech teams to work in silos, but working together produces more value. Especially in a tech transformation, the two teams are different sides of one coin. Find ways to bridge the gap and you’ll see much more value in your resulting tech stack.

How to use a composable stack to drive digital marketing innovation

Auden Hinton, Contentstack Director of Digital Experience, reveals how our headless CMS and composable architecture has enabled different teams at Contentstack to quickly deliver at scale on innovative and collaborative initiatives. 

How switching to a composable DXP will affect security

The top priority for any business is protecting sensitive information from cyberattacks, and the effectiveness of your cybersecurity measures largely depends on your tech stack. There are a number of  benefits of going composable, and a key one is that composable DXPs can offer better security than monolithic solutions. Read on to learn: How going composable can improve your organization’s cybersecurity  What you need to know to make your composable tech stack as secure as possible What is composable architecture? Composable architecture breaks down the large and complex functions found in monolithic solutions into smaller, more manageable pieces. An API acts as the go-between for these smaller pieces, allowing them to communicate and transfer information more efficiently. In a composable CMS, the front-end and back-end layers are decoupled, so changes can be made to the front end independent of back-end functions.  There are a variety of benefits of moving to a composable DXP, including reduced IT costs, more streamlined processes and functions, easier updates and, when properly implemented, better security. What are the biggest threats businesses face? Cyberattacks have always posed a risk to businesses, but that threat has grown in the past decade. Businesses have beefed up their cybersecurity measures when it comes to some of the more common threats like phishing and malware; unfortunately, hackers have responded by developing more sophisticated cyberattacks that are harder to spot — and more difficult to guard against.  Today, businesses face a slew of cybersecurity threats. Ransomware attacks hold entire networks hostage. Endpoint attacks are on the rise, thanks to the shift toward remote work and, in turn, the number of off-site Internet of Things (IoT) devices connected to business systems. Supply chain attacks exploit security weaknesses in third-party vendors or providers to gain access to their partners’ systems. And even though we are better trained to spot phishing attempts and avoid malware, these strategies still work often enough that hackers continue to use them.  Composable DXPs provide the flexibility to employ cutting-edge cybersecurity measures to protect against cyber attacks and data breaches. The security benefits of going composable A strong cybersecurity strategy is especially important with composable DXPs. As noted above, a composable approach offers the ability to break the large, single-suite functions of monolithic platforms into smaller components. This allows for more customization options, as organizations can pick and choose the specific programs and functions they need to deliver a top-tier digital experience. But each individual piece has its own security requirements and vulnerabilities, and your cybersecurity strategy needs to account for all these differences so there are no holes to exploit.  When moving to a composable DXP, a key first step is to define your security needs and identify the security tech stack that best meets those needs. This will serve as the foundation of your cybersecurity framework, and all the functionality that follows needs to fit within it. The benefit is that it makes it much easier to identify and isolate any vulnerabilities in your security. With monolithic systems, spotting security risks or finding the source of a breach means combing through the entire system. With a composable DXP, it’s much faster and easier to go through each individual function and make the necessary adjustments to secure your system.  How to properly secure your composable tech stack Breaking out functions into individual components with a composable DXP solution creates more endpoints that can be vulnerable to cyberattacks. But even though there are more potential points of access, there are also more ways to secure your systems.  API management platforms make it easy to track API usage and integrate up-to-date security protocols like OAuth and OpenID. That allows you to control who can access and use critical applications and data stored in cloud services, and with authentication processes to verify user IDs, you can catch any security threats before a breach occurs. To secure your composable DXP, these functions are essential: End-to-end encryption Access controls  Authentication: Encryption keys; 2FA; securing IoT devices Data protection Detailed monitoring Implementing these functions and tailoring them to the unique needs of your composable DXP helps ensure that the sensitive data in your platform is protected from cyberattacks. Data security in your composable DXP When it comes to brand interactions, today’s consumer expects a personalized experience, but in order to create a robust customer journey, you need to gather data about your customers. Consumers are willing to provide that data if it means a better digital experience — but they also expect that their sensitive information will be safe in your hands.  The financial cost of a data breach can be massive, but it’s nothing compared to the damage your organization’s reputation will suffer if your customer data is exposed due to a security breach. Fortunately, your composable DXP strategies can help provide better data security.  With a monolithic system, if your critical infrastructure is breached, all your customer data is exposed. A composable DXP allows you to create modular data pipelines that connect to each individual component and the relevant data, rather than a single large block that contains all your data, as is the case with legacy systems. With composable, you can scale up or down and implement or remove components based on your security needs. And if a data breach does occur in one component, the scope of the data exposure is usually limited. Securely meeting consumer demands The customer experience is delivered across different parts of your composable DXP, from your headless CMS to your marketing stack — and it all needs to be supported by a robust cybersecurity strategy that meets or exceeds industry standards. Cybersecurity threats come in all shapes and sizes, and cyberattacks can come from anywhere. To combat those threats and protect your system, your cybersecurity strategy needs to address all the potential risks. Your technology also needs to be flexible and adaptable in order to guard against new threats as they arise. Going composable allows you to build your tech stack to match your security strategy, and vice versa. It’s important to remember that ensuring a safe and secure experience goes beyond adding security protocols to your tech stack. Rather, it’s about deploying the right technologies and data protection programs and practices for the unique needs of your organization.  Learn more Learn more about composable architecture in our blog post, “Why composable architecture is the future of digital experience.” Schedule a free demo to learn how Contentstack can help you create a secure composable DXP solution that best suits your organization’s needs.  

From legacy systems to microservices: Transforming auth architecture

HighlightsYou'll learn how to:Leverage modern design patterns: Use contemporary architectural patterns for developing efficient authentication and authorization solutions.Deploy access tokens efficiently: Transfer access tokens from the periphery to individual microservices, and you can ensure effective authentication in a microservices environment.Acknowledge authorization challenges: Developers must understand that while authentication issues are addressed by mature standards like OAuth2 and OIDC, authorization presents unique challenges.Customize access decision managers: Enhance your authorization architecture by personalizing your AccessDecisionManager or AccessDecisionVoter.Organizations can successfully transform their auth architecture by understanding and implementing these key points. Keep reading to learn more!Contentstack receives billions of API requests daily, and every request must be validated to be a valid Contentstack identity. It is a common industry practice to achieve this using some sort of “identity token" for every request. Imagine having multiple types of identity tokens, such as session tokens, OAuth tokens, delivery tokens, management tokens, etc.The problem of securing billions of API requests daily can be challenging. We decided to address this by spinning up a new team that handles the complex problems of user authentication and authorization in a token-agnostic platform.Our transition journeyContentstack started as an API-first headless CMS platform that allowed content managers to create and manage content while simultaneously and independently enabling developers to use Contentstack's delivery API to pull that content and render it to create websites and applications. This means that Contentstack’s traffic increases proportionately to the traffic received by our customers' websites and applications.With increased traffic and usage, we catered to various new use cases by developing new features. These features were powered by a set of microservices, each catering to a particular feature domain and needing support for processing multiple identity tokens that had roles and permissions associated with them. The whole system had turned out to be quite complex, and performing auth had become a great challenge. This prompted us to redesign our auth architecture, which addressed the issues of being a token-agnostic and low-latency platform.Read on to learn more about this journey and how we have been able to:Transition from a monolith to a low latency microservices-based auth (authentication plus authorization) and rate-limiting architecture.Set up centralized authentication for multiple (any domain) microservices that are part of the same Kubernetes cluster.Set up decentralized and self-serviced, policy-based authorization for internal services and teams.Increasing feature sets increased domain microservices, which increased the complexity of performing auth.Monolithic auth architectureMonolithic architectures can be difficult to maintain, scale and deploy. In a monolithic architecture, user authentication and authorization are typically tightly coupled with the application code, making it difficult to implement and maintain robust security measures. Monolithic architectures often rely on a single authentication and authorization mechanism for the entire application, which can limit the flexibility of the system to accommodate different types of users or access levels.{{nativeAd:3}}Performing auth in a typical monolithic architecture.In monolithic architectures, the steps involved in auth are the following:Users use their credentials at the client to generate a session token or use an existing identity token to generate other identity tokens.Users then use the generated identity token to perform a business operation by making a request to the application server.Once a request is received at the application server, the authentication middleware authenticates the token and forwards the request to the business module.The business module performs the business operation based on the authorization rules applied to the user identity.Problems with monolithic auth architecture:Authentication and authorization logic is mixed with the business logic.Changing the way an identity performs an operation on a resource involves a change in the associated auth-related logic.Each domain individually implements the authorization logic, causing a difference in implementation.Since authorization logic is deeply nested in business logic, we lack visibility into authorization rules applied to a resource.Shipping of new authorization logic requires a fresh deployment of the application image.New microservices require knowledge of various identity tokens and resource authorization rules to be applied.Microservices auth architectureMicroservices offer a more flexible, modular approach that allows for easier maintenance, scalability and deployment. With microservices, each service can be developed, deployed and scaled independently, allowing for faster time-to-market, improved fault tolerance, and better alignment with modern development practices. Additionally, microservices offer more efficient use of resources and better support for diverse technology stacks.AuthenticationWhy centralized authentication?Centralized authentication is a security model in which a central authority manages authentication, such as a server or service, rather than it being distributed across multiple systems or applications. There are several reasons why centralized authentication is commonly used and considered advantageous, including increased security, simplified management, improved user experience and lower costs.While there are some drawbacks to centralized authentication, such as the increased risk of a single point of failure and increased complexity in managing the central authority, the benefits often outweigh the risks.Centralized authentication and rate-limiting at the edge of the service mesh.The steps involved in the centralized authentication process are the following:Any incoming request to the Kubernetes cluster first lands at the Istio ingress gateway.The request containing the identity token is proxied to a central authentication gRPC service with the help of envoyproxy's external authorization filter.The central authentication service queries Redis with the identity token and metadata associated with the request.Redis responds with the identity associated with the token and the current rate-limit count based on the request metadata.The central authentication service responds to Istio with either of the following:Authenticated response with user context attached to the request in the form of request headersUnauthenticated responseRatelimit exceeded responseAn authenticated request containing the user context is then forwarded to the upstream service.Advantages over the monolithic architecture:Easier to onboard newer microservices to central authentication service by using label based istio-injection.All requests are authenticated and rate-limited at the edge of the service mesh, ensuring that each request entering the cluster is always rate-limited and authenticated.The request forwarded to the upstream microservice has user identity context attached to it in the request headers, which can be further used for applying authorization rules.Keeping centralized authentication eliminates the problem of multiple mutations performed by the upstream microservices on the identity of the token.AuthorizationCentralized authorizationWe tried a model where along with authentication and rate limiting, we also added authorization as a responsibility of the central authentication and rate limiting service. The service would first identify the incoming request’s identity from the token and apply rate limiting based on the request metadata. Once the user identity is known, authorization rules could be applied to the user’s identity, thereby performing the entire Auth at the edge of the service mesh.Problems with this model are the following:This model could only perform basic authorization at the edge based on the request metadata provided, such as validating organizations, stacks, etc. However, it could not perform fine-grained authorization, such as finding out which content types the logged-in user had access to.For RBAC, each domain has its roles and permissions associated with it; performing authorization for such requests requires knowledge of the upstream domain and leads to the addition of domain-specific logic in the centrally managed domain-agnostic platform.With newer domain microservice additions, this again would lead to the problem of lacking visibility into authorization rules applied to a resource.Distributed authorization with central authorization serviceWe then tried implementing a model where we distributed authorization to the upstream microservices where each upstream microservice makes a call to a central authorization service. The authorization service has access to all the roles and permissions of different domains and was able to give appropriate authorization results. Authorization could now be performed from the upstream service’s business module by making a network request using Kubernetes cluster networking to avoid making a call over the internet.Problems with this model are the following:The central authorization service becomes a single point of failure.Any change in the API contract defined by the central authorization service requires all the upstream services to abide by it and makes shipping these changes independently a complex task.Performing authorization adds a network hop, thereby increasing the latency.Distributed authorization with the sidecar patternLearning from the previously discussed disadvantages, we wanted to build a model that had authorization distributed, low latency and made shipping authorization logic an independent activity.ArchitectureThe architecture involves the following components:Auth sidecarCentral policy serviceAuth SDKArchitecture for authorizing an authenticated request with the sidecar pattern.{{nativeAd:9}}Auth sidecarThe auth sidecar is a gRPC service that gets injected along with the microservice’s application container in the same Kubernetes pod. Let’s understand how this architecture helped us tackle the previously mentioned problems.Single point of failure: The auth sidecar service runs with the application container in the same pod, and any case of failure is only limited to the current pod. Restarting the pod gives us a fresh set of application and auth sidecar containers.Independent delivery: Since the auth sidecar service container is shipped along with the application container, the application service can decide which version of the sidecar image to use, thereby making the delivery of newer versions of the authorization sidecar independent.Low latency: There is no network hop involved in making a gRPC call to the auth sidecar running in the same pod. This helps the application to get the authorization result with very low latency (in a few milliseconds).Updating authorization logic: The auth sidecar periodically downloads fresh policy bundles; any time there is a change in policy bundle coming from the central policy service, the auth sidecar updates its local policy cache with the new bundle.This way, updating authorization logic does not involve a fresh deployment/restart of the application container.Components involved in auth sidecarResponsibilities of the components involved in the authorization sidecar.Aggregator: The responsibility of the aggregator is to fetch authorization-related data for the current identity based on the metadata provided by the application service in the gRPC call. It then aggregates it to be evaluated against the authorization policy.OPA Engine: We use OPA (Open Policy Agent) to periodically download fresh policies and evaluate the policy path mentioned in the gRPC call against the aggregated data.Central policy serviceThe central policy service is a repository of policy bundles (*.rego files) which are independently managed by the domain microservices. The maintainers of the domain microservices create these policies for various resources that need authorization. Since these policies only involve rules, it greatly increases the visibility of authorization rules being applied to a particular resource.Auth SDKThe auth-sdk is an internal library that we developed that helps the developers of upstream microservices to easily communicate with different auth components. It can do the following:Extract user identity and other useful information attached in the request headers by the central authentication serviceDiscover various auth components and streamline communicating with themExpose different helper methods to perform any auth-related activity on behalf of the application serviceRedesigned (new) architecture:Tracing the request lifecycle in our redesigned auth architecture.ConclusionMicroservices-based architectures can help address some of these challenges of monolithic architecture by separating user authentication and authorization into individual services, which can be developed, deployed and maintained independently. This approach can provide greater flexibility, scalability and security for user authentication and authorization.However, it's important to note that transitioning to a microservices-based architecture can also come with some challenges, such as increased complexity and a need for more advanced DevOps practices. Proper planning, implementation and ongoing maintenance are crucial to ensuring a successful transition.

Bridging monolith and composable with automation, with Director of Engineering Keith Mazanec

Moving to composable technology almost never happens all at once. There is a transition period. How do you help teams make the most of the composable technology, while easing the transition between old and new? Keith Mazanec, Director of Software Engineering at Brad’s Deals shares how they used a composable content technology with automation capabilities (Contentstack) to create an easy transition that improved the lives of content editors straightaway - and created a better experience for everyone, customers included. Plus, hear about their favorite uses of Automation Hub to automate across the content lifecycle.Timestamps:1:05 The volume of content at Brad's Deals, and what that means for content editors1:56 Why Brad's Deals looked for a new content management technology2:27 An example of how automations helped reduce manual data entry for content editors3:57 The custom dashboard Brad's Deals built for their editors5:06 Example of automating a categorizing function to speed up content publishing process6:03 Versioning and automating making changes to the content model8:16 How Brad's Deals created continuity between their legacy technology and the new headless CMS9:57 Automating throughout the content lifecycle across different content & marketing applications

How to make the most of your composable DXP with ChatGPT

ChatGPT has gotten plenty of attention in recent months. The chatbot, developed by OpenAI, recently made headlines for (among other things) passing law exams, a Wharton business management exam, and parts of the US Medical Licensing Exam, all without any external input. ChatGPT reached 1 million users within five days of release; by comparison, it took Spotify five months to reach that threshold. For digital brands, the arrival of ChatGPT is a game-changer — especially when it comes to creating content and content management. Read on to learn how to use ChatGPT with a composable DXP.What is ChatGPT?ChatGPT is a natural language processing tool powered by AI technology. Using reams of text from the open internet, the program is asked to predict the next word in a text string, over and over. Over the course of trillions of predictions, GPT has learned not just how to predict the next word, but also use its training data to answer questions and complete tasks assigned to it. As you can imagine, this presents a lot of opportunities for brands to enhance their digital experience platforms.How can ChatGPT integrate with a composable CMS?Although ChatGPT was not designed specifically to work with content management systems, there are ways to integrate it into your CMS and leverage its capabilities to improve the digital experience.Chatbot engineWith most chatbots, user communication is on rails. Standard chatbots only recognize specific prompts, and depending on how the chatbot is designed, those prompts might not cover everything users may need. ChatGPT is able to have real, natural conversations with users for a more robust and personalized experience. Using ChatGPT as the conversational engine for the chatbot, the CMS can use relevant content — such as articles, FAQs, product information, and more — as training data, which ChatGPT can then use to answer user queries. ChatGPT can also enhance the chatbot's ability to understand and respond to natural language queries, so users can ask questions however they want and still get the answer they’re looking for. The benefit for your team is less time spent designing the chatbot to respond to every possible user query (and every possible variation of those queries). ChatGPT can also connect to your CMS via custom API integration. When users interact with your CMS, the web service can run the user’s query through ChatGPT, and ChatGPT’s response can then be returned to the web service to be displayed to users. Whether you use ChatGPT to power a chatbot or integrate it with your CMS, users benefit from a more engaging and personalized experience — and your customer support team benefits from the automation of some of their more time-intensive tasks.Marketing automation and personalizationGood marketing is informative. Great marketing is informative and has a personal touch. Generic or broad automated marketing is unlikely to win new customers; instead, your marketing needs to address each user’s unique preferences in order to win their business. Unfortunately, creating highly specific content that speaks to each individual user is incredibly time-consuming. ChatGPT can take information about your customers’ interests, preferences and behaviors and use it as training data to create more personalized and targeted marketing content in a fraction of the time. In other words, brands don’t have to choose between reach and personalization — ChatGPT can provide both.Coding suggestions for front-end and back-end developmentReviewing code is a necessary part of updating and enhancing your composable digital experience platform, but it can be a major time and resource drain for your DevOps team. Since ChatGPT is a language model, it can read and understand code written in a variety of programming languages — which can save you time and stress as you prepare to roll out new features or functions on your platform.Strictly speaking, ChatGPT is not able to “review” code in the way a developer would, because ChatGPT doesn’t understand the context of the code the way a human developer does. Still, ChatGPT can answer specific programming questions for developers, review code syntax and point out any potential logical flaws in the code that can save time on debugging. Content creation and testingEffective content helps attract new users to your site and delivers a quality experience that will encourage repeat visits. Producing high-quality content requires a lot of time, effort and resources. ChatGPT can handle many of the tasks that might otherwise require you to hire a team of writers or content specialists.ChatGPT’s role in content creation is entirely up to you and your needs. You can use ChatGPT to generate content ideas by providing prompts and suggestions related to your business and letting ChatGPT suggest topics that will resonate with your target audience. ChatGPT can also be used to test existing content: Simply provide the AI model with existing pieces of content and ask for suggestions, and ChatGPT will offer suggestions to make the content more engaging, more informative or more SEO-friendly. On the other end of the spectrum, ChatGPT can also be used to create outlines or even entire pieces of content from scratch. With a bit of guidance in the form of prompts or content topics, ChatGPT can write full articles and blog posts, which can then be edited and customized to match your brand’s voice and messaging. It’s important to note, however, that while ChatGPT can drastically reduce the amount of time spent on content creation, there is still value in a human element. Users may eventually learn to spot AI-generated content, and your SEO can suffer if your content bears too many AI fingerprints. When used effectively, ChatGPT can help reduce the time your team spends on content creation and the tedious tasks that go with it.How Contentstack AI Assistant leverages the power of ChatGPTContent creation is a crucial part of building a connection with your audience, and ChatGPT is poised to transform the content creation and publishing experience. The new Contentstack AI Assistant harnesses the power of ChatGPT to help teams create brand-specific content in seconds. By adding ChatGPT to your entry editor through in-line UI extensions, the Contentstack AI Assistant makes it easy for content teams to leverage ChatGPT’s capabilities however they choose. Want to experiment with content creation? Quickly and easily build outlines for content writers? Create summaries, outlines, metadata tags, and headlines so editors and publishers can move on to other tasks? Translate content for global users? All this (and much more) is possible with just a single prompt to the Contentstack AI Assistant. The possibilities for your content are endless. With Contentstack AI Assistant, it’s never been easier to tap into those possibilities to take your content to a whole new level and get the most from your composable DXP. Learn moreWatch this episode of "Contentstack LIVE” with Contentstack VP of Product Conor Egan to learn more about the power of generative AI.Schedule a free demo to see how Contentstack can help you leverage the power of automation to launch digital experiences at the speed of your imagination.

What developers should know about composable DXPs

As enterprises strive to create a unified digital experience for their customers, it is essential to understand the fundamentals of composable DXPs. This blog post will explain what these platforms are, how they work, and how they can help create an effective customer experience. What is a composable DXP? A composable DXP (digital experience platform) is a technology stack that supports the development and deployment of applications across various channels such as web, mobile, voice assistants, wearables and more. It consists of different components such as content management systems (CMSes), microservices architecture, APIs, analytics tools, customer data platforms (CDPs), marketing automation tools and more. These components work together to enable developers to rapidly build and deploy applications with minimum effort. How does it work?The key to making a composable DXP successful is having the right components in place. Components of a composable DXP include:A CMS that is the foundation for managing content across multiple channels APIs that provide access to data stored in other systems such as databases or cloud services. Microservices architecture that helps break down large applications into smaller services that can be deployed independently. Analytics tools that allow developers to gain insights into user behaviorMarketing automation tools help automate tasks such as sending emails or messages on social media platformsA customer data platform to store customer data securely and easily access it when neededBenefits of adopting a composable DXPUsing a composable DXP has several benefits for developers including:Increased agility:  With a composable DXP in place, developers can quickly build apps without spending time on coding from scratch or integrating multiple technologies together. This increases agility by allowing them to respond quickly to market needs or changes in customer preferences. Scalability: Composable DXPs are highly scalable so they can handle large amounts of traffic without compromising performance or reliability.Cost savings: Using a single platform reduces costs by eliminating the need for multiple technologies and license fees associated with them. Challenges for developersIntegrating multiple components One of the biggest challenges with composing a DXP is integrating all the different components together in a way that works seamlessly with each other. This requires extensive knowledge of web technologies, coding best practices, and design principles. It also requires developers to have an understanding of how different software interacts with each other and how they can be integrated into a single platform. Additionally, if there are any compatibility issues between two components or systems, then the developer will need to find a workaround or replace one component with another.  Maintaining quality standards Another challenge that developers face when implementing a composable DXP is maintaining quality standards throughout the process. Since they are dealing with multiple pieces of software that may come from various sources, it’s important to ensure that all components meet certain quality standards before they can be used in production. This means making sure that all code is up-to-date and bug-free; all third-party APIs are secure; and all data sources have been tested for accuracy and completeness before being integrated into the platform.  Testing for performance issues Finally, when creating a composable DXP, developers must also test for potential performance issues. As more components are added to the platform, there is an increased likelihood that some parts may not perform as expected due to memory usage or runtime errors. Therefore, it’s important for developers to thoroughly test their composable DXP before launching it in production to ensure its stability and eliminate any potential issues from arising later on down the line.  ConclusionImplementing a composable DXP offers many advantages over traditional monolithic applications but comes with its own set of challenges. Developers must make sure each component functions properly and meets quality standards before being implemented into the system. They must also test their platform for potential performance issues before launch. You can overcome these challenges by carefully planning your architecture and understanding how each component integrates with one another so you can create an effective solution for your customers’ needs.Learn moreLearn more about going composable in our guide, “How to go composable in 6 steps.”Schedule a free demo to see how Contentstack's composable content experience platform can help your organization benefit from the flexibility and scalability of a composable DXP.

Composable vs. monolithic: Which is right for you?

Businesses are trying to create better customer experiences, so composable digital experience platforms (DXPs) are becoming more popular. But what are they? How do they compare to monolithic platforms? And how do you choose the right one for your business? In this blog post, we will answer these questions and more.What is a digital experience platform (DXP)?Digital experience platforms (DXP) are purpose-built technology solutions for creating, managing, delivering and optimizing consistent digital experiences across different customer touchpoints. These tools offer businesses a valuable way to communicate with their users through content and obtain customer feedback through data collection.Companies can utilize DXPs to create content tailored to websites, email campaigns, mobile apps, social media channels, e-commerce sites, IoT devices, digital signage systems and more. Beyond simply broadcasting content on each platform, DXPs also allow marketers to automate marketing activities and develop a unified digital experience that can take users toward their desired goals or objectives.DXPs help companies understand what customers want and need. They can do this by looking at how customers act online on websites, social media, and other online places. Businesses can then use this information to reach out in new ways or to improve their relationships with existing customers. Ultimately, using a DXP helps organizations make more sales or conversions by providing a better user experience across multiple channels.What is composable architecture?Composable architecture is an innovative way of organizing and managing software development that separates front-end and back-end code. This technique enables teams to create, modify and launch content without relying on developers for coding. This method of organization helps speed up development and make it more efficient. Composable architecture makes developing software easier while encouraging teamwork between different departments. For example, if you use a composable content management system, the marketing team can make changes and publish their work without waiting for developers to finish coding. This way, teams can post new content more quickly. Additionally, developers can focus on creating unique experiences and features instead of being bogged down with marketing tasks or fixes.What is a monolithic DXP?A monolithic DXP solution is an all-in-one platform that provides a suite of tools for managing content. These platforms are designed to enable users to store, manage and publish content quickly and easily. They typically offer features such as content editing options, user permissions and roles and media asset management.Monolithic content management solution platforms can be rigid in terms of how they operate and may not be able to keep up with the ever-changing needs of a business. Additionally, they tend to take longer to customize than composable DXP systems.What is a composable DXP?The composable DXP concept is still relatively new and has become increasingly popular recently. A composable DXP is a platform that allows digital teams to assemble individual services or microservices into an experience that meets their specific needs. This innovative type of DXP is essentially an assembly of best-of-breed solutions to deliver content and digital experiences to customers in a much more agile, flexible and efficient way than a single monolithic platform.As opposed to the traditional monolithic approach taken with DXPs, this microservices approach enables companies to cost-effectively customize their DXP according to their business needs. Furthermore, allowing for a greater level of scalability and interoperability allows faster time-to-market for new features or services, as well as improved customer satisfaction.The composable approach gives organizations better control over their digital experiences and helps them stay ahead of their competition by enabling them to focus on innovation instead of maintenance. A composable solution makes it easier for businesses to move quickly while keeping up with the ever-changing technology landscape.What to consider when comparing a composable and monolithic DXPsCan the platform integrate with solutions your team currently uses?Monolithic suites are large programs often made up of products obtained through acquisitions and then given a makeover in terms of branding and user experience to fit into the overarching process. Such products lack the open-source code needed to integrate them seamlessly with other solutions, which can limit their utility as part of a more comprehensive DXP solution. This technique makes it simple for internal integration, but external integration can be difficult or even impossible.On the other hand, with a composable DXP, external integration is better facilitated due to its ability to connect with existing best-of-breed solutions more readily. As such, organizations have more control over how their digital experiences are created and tailored for their specific audiences. Furthermore, each individual component can be monitored separately from the rest of the system, allowing for greater visibility into performance and ease of scalability when needed. Ultimately, a composable DXP offers organizations greater flexibility and agility compared to monolithic platforms by providing enhanced external integrations and visibility into performance metrics on an individual basis.How much time will it take to deploy the platform?Deploying a new monolithic suite can require significant time and effort — sometimes months — and demands constant monitoring for unexpected changes or challenges during set-up.Moreover, it's necessary to ensure that all employees acquire the required skills to work effectively in this new environment. Besides the technical implications of such large-scale transition projects, there are also social and psychological implications that business leaders should take into consideration. Companies must be aware that transition periods affect team dynamics and thus must create an atmosphere of collaboration that encourages employee engagement and satisfaction throughout the process.On the other hand, a composable DXP approach allows companies to start quickly, taking advantage of the existing knowledge their staff already has. This strategy eliminates the need for extensive training since they can be up and running with a condensed feature set using workflows they're already familiar with.How will we keep the platform up-to-date?Companies can easily keep their composable DXPs up-to-date as the various vendors focus solely on perfecting their solutions. Additionally, organizations can frequently enhance open-source products with improved customizations and updates that won't depend on the vendor.For monolithic suites, a single vendor provides updates and new features; however, some of these “nice-to-have” additions may take an extended amount of time to be implemented to the platform  — if at all. Even minor bugs can be left without resolution until suite-wide updates are rolled out. Companies should be aware that they may not always get timely fixes for any issues they encounter while using DXPs with a single-source provider.How secure are these platforms?A composable architecture allows security updates and patching solutions to be implemented quickly for each component without hindering other systems. This expedited process allows for swift response times in case a breach or vulnerability is discovered. However, if a security flaw is found in one component of an entire suite, it can likely extend to the whole system, thereby rendering the entire suite susceptible to exploitation. Consequently, organizations must take extra care when monitoring their suites for security flaws to ensure that all corners of their system are protected from malicious actors.On the other hand, monolithic solutions can be patched as a single software package. Still, patches may need to happen when the system is not being used, causing extended exposure to vulnerabilities.ConclusionComposable DXPs offer more flexibility and agility compared to monolithic platforms. This means they can scale better, have new features and services faster and improve customer satisfaction. They also provide shorter deployment times, easier updates and enable responsive security updates. However, while they may be more flexible than a single-vendor platform, companies must still carefully monitor their systems for any potential security flaws or vulnerabilities that could put their entire suite at risk. Ultimately, businesses can make informed decisions about which type of system best meets their needs by understanding the differences between these two approaches to digital experience delivery and the pros and cons of each.Learn moreLearn more about composable architecture in our guide, “The ultimate marketer’s guide to composable DXPs.”Schedule a free demo to see how Contentstack’s composable DXP can help your organization deliver the digital experiences your customers crave.

How to switch from a monolithic to a composable architecture in 7 steps

Learn how to switch from a monolithic CMS to a composable content management platform in this step-by-step guide.