Skip to main content

Frequently Asked Questions

Build vs. Buy​

Q: Why should I buy my orchestration layer as opposed to building a Backend-for-Frontend (BFF) myself?​

A: The concept of Backend for Frontend (BFF) has been around for a while, presenting a solution to the complexities arising from interfacing with multiple backend services. At its core, BFF abstracts the frontend from the backend, eliminating the need for the frontend to handle intricate business or integration logic. However, let's break down why using a DXO is better than building your channel-specific/app-specific BFF.

  1. DXO vs BFF: At a surface level, DXO might sound similar to BFF, but they're inherently different. BFFs are custom-built by engineering teams for specific frontend applications. On the other hand, Conscia's DXO offers a zero-code, Software-as-a-Service (SaaS) solution, which significantly speeds up the time-to-market.

  2. Build vs Buy: Building a BFF demands substantial resources in terms of time, money, and engineering talent. In contrast, configuring Conscia's DXO can be done in hours, ensuring faster deployment and reduced operational costs.

  3. The GraphQL Misconception: Many believe that with GraphQL, they don’t need a BFF or DXO. But while GraphQL offers flexibility in querying data, it necessitates building GraphQL servers, which is resource-intensive. Engineers must implement resolver functions, handle errors, manage deployments, and oversee monitoring – all of which come with associated costs and complexity. Moreover, maintaining GraphQL servers demands DevOps resources, further escalating expenses.

  4. Comparing Capabilities:

    • Centralized Control: DXO empowers marketing teams with centralized control across all channels. Traditional BFFs don’t offer such capabilities unless you invest more in developing custom applications.
    • Universal API Connector: With DXO, you can seamlessly connect to any backend API without coding. BFF development, in comparison, requires constant code writing and deployment.
    • Performance Optimization: DXO enhances performance without the need for data migrations. With a BFF, performance boosts often mean adding caching layers or integrating with engines like Elasticsearch.
    • Configurable Abstraction Layer: DXO offers a configurable layer that can cater to any frontend or backend without coding. BFFs are usually restricted to specific backends and are tightly knit with the frontend.

  5. Flexibility and Scalability: A BFF is designed for a particular frontend, making generalization challenging. In contrast, DXO boasts of features beyond BFF, providing a zero-code orchestration layer tailored for multiple frontends.

In essence, while BFFs serve their purpose, Conscia's DXO extends beyond, offering capabilities that are broader and more flexible. It is more than just an orchestration layer; it's a comprehensive solution that addresses diverse frontend needs without the challenges of traditional development.

By opting for Conscia's DXO, you're not just choosing an alternative to BFF; you're investing in a powerful, scalable, and versatile tool that future-proofs your digital experiences.

Q: Where does Conscia sit within the overall Composable stack?​

A: Conscia sits in between your frontend and your backend. Conscia’s offers orchestration as-a-service, allowing developers to connect to a collection of backend services via a single Experience API and marketing teams to manage their composable experiences in a centralized intuitive interface.

Q: When would I use the vendor specific Orchestration Components as opposed to the Universal API Component?​

A: When you want to offer an intuitive user interface to product and marketing teams to define the experience that sources content and product information from a CMS, Commerce Engine, etc, it is best to create a Vendor-specific Connection. An example would be if you want the business user to manually select a set of content items from a specific content type within Contentful.

On the other hand, if you only need to connect to a webservice API endpoint to retrieve data that doesn't require a business user interface to view/discover/select, you can use a Universal API Connector.

Here is a list of examples where you don't need a vendor specific Connection:

  • Fetch customer's profile and set their customer segment as a real-time context.
  • Add or Remove and item to/from Cart
  • Retrieve prices from a pricing engine

In these examples, there is no need for non-technical users to provide their input in the API orchestration.

Orchestration Flow​

Q: What guidelines exist for defining versus reusing a Component in an orchestration flow?​

A: Components calling a backend data source are restricted to one API-endpoint. Therefore, distinct endpoints like Cart API, Pricing API, and Checkout API would necessitate separate Components. However, creating a new Component is extremely simple and does not require any coding.

Q: How does Conscia's caching approach differ from Valhalla and a standard caching approach with complex keys?​

  • Conscia's Caching: Conscia offers a flexible and advanced caching mechanism. Each Component within the platform can cache its output, allowing for tailored and efficient content delivery.

  • Standard Caching with Complex Keys: This traditional method uses intricate keys for data storage and retrieval, often leading to rigid cache structures.

  • Valhalla: It serves as a database primarily designed for faster JAMstack builds by syncing from a source datastore. It acts as a "pseudo" transient cache. Conscia's roadmap aims to offer a Component to query Valhalla as another datastore.

Q: Can users invalidate the cache for specific objects in Conscia?​

A: Yes, users can invalidate specific objects in the cache. They have the flexibility to define a custom cache key based on parameters like the product ID and relevant context values. Using this custom cache key, they can then invalidate specific objects as required.

Q: Is it possible to invalidate Conscia's cache using an API, or do users have to rely on a TTL strategy?​

A: Conscia offers both options. Users can choose to invalidate the cache using Conscia's API. However, if preferred, they can also implement a TTL (Time-To-Live) strategy to manage cache durations and expirations.

Environment Management​

Q: Does Conscia allow for environment management through APIs and the creation/destruction of non-production environments?​

A: Configurations can be exported as JSON files, allowing for version control. You can also create or delete an entire environment in the UI or via API.

Platform Resilience and Uptime​

Q: How does Conscia ensure high uptime and resilience in its platform?​

A: Conscia offers up to a 99.99% SLA. The engine nodes are globally distributed and use latency-based DNS load balancing. We employ several strategies, including health checks and traffic redirection, to ensure the platform remains robust. For additional assurance, users can cache payloads from Conscia or implement page-level caching.

Q: How is Conscia hosted and scalable, especially during traffic spikes?​

A: Conscia ensures high availability of its query nodes across various regions. We employ DNS load balancing based on latency, ensuring optimal user experiences. Traffic is also seamlessly redirected between nodes based on their health status. Furthermore, Conscia's internal dependency tree ensures that components execute in the most efficient sequence for optimal performance.

Q: How does Conscia manage latency in intricate orchestration scenarios?​

A: Each Component in Conscia can cache its output for a set duration. The latency introduced by the DXO Engine operations is minimal due to several optimization techniques. In benchmark tests involving 20+ components evaluating complex logic, response times were noted to be less than 20ms.

MACH Alliance and Certification​

Q: Is Conscia a part of the MACH alliance

A: Yes, Conscia is now a member of the MACH alliance.

Product Roadmap​

Q: What features or improvements can we expect from Conscia in the near future?

A: In the upcoming months, Conscia will introduce:

  • An observability dashboard for real-time metrics on API requests.
  • An Orchestration Component that can call an Orchestration Flow.
  • Sub Component visualization.
  • OAuth-based authentication for backend systems, among others.

Backend Integrations​

Q: What are the different ways in which I can connect to backend systems wtih Conscia?​

A: There are two ways in which you want to interact with a backend system within an Orchestration Flow:

  1. You want to provide control to the business user to select content/data for display on some frontend. For example, a CMS, a PIM, DAM, etc.
  2. You need to connect to the backend in order to read and write from it as part of an overall orchestration approach. For example, a CDP that you may want to call to pull customer segment based on a customer ID only to use it later to fetch relevant content from a CMS.

When there is no need for a business user interface in DX Engine UI, you can use the Universal API connector to connect to any backend system as long as it has an API and it provides a JSON response.

When an editor interface is required, we already have a connector for all popular CMSs, Ecommerce Engines, DAMs, Promotion Engines etc. If a new connector is required, we have a no-code connector configuration process that maps the backend APIs to the user interface controls.

We offer two different ways for business users to select content/data from a backend system. 1) Manually select a set of items 2) Provide a dynamic criteria for record selection. Most backend systems offer an API to retrieve a single record by ID and other attributes such as name, description, etc. For the dynamic selector, we require that the backend offers an API that offers a search/refine API that allows you to set the criteria that matches one or more items.

Q: How long would it take me to connect to a backend that Conscia does not have an existing recipe for?​

A: Conscia is a zero-code platform, which means that if you need to build a brand new connector to a backend, there is no code required to do so. The hardest and the most tedious part is to understand the API parameters and responses offered by the backend application. Once that is understood, configuring the connector is a matter of minutes.

Q: Does Conscia ingest data from the backend systems?​

A: Conscia's DXO offers two modules: DX Engine and DX Graph. The DX Engine is a real-time DX Orchestration engine and fetches data from backend systems offering APIs in real-time. The DX Engine does not store any data from backend systems, however, you do have the ability to cache responses to the Experience API at a very granular level.

For legacy systems or systems that do not offer APIs, DX Graph can sync with the backend through batch methods and make the data available to the DX Engine via real-time APIs.

Q: How does Conscia integrate with JAMstack, and how are static rendering and server-side rendering managed?

A: Static rendering involves a build process that pulls data from sources to generate HTML using templates/frameworks. In contrast, server-side rendering constructs the page upon a real-time request. With Conscia as the DXO layer, the DXO Engine serves as one of (or the sole) data sources during this build phase. The page variants are built according to dynamic contexts like location or customer segment, derived from the DXO Engine. The finished page is then cached. Interestingly, the permutations of all contexts that the DXO Engine addresses can be pre-computed and used as input during the build process, which Conscia is advancing through an API for this purpose.

GraphQL Mesh Versus DXO Engine​

Q: How does the DXO Engine differentiate from a GraphQL Mesh?​

A: The primary differences are:

  1. Design Philosophy: While Mesh is more of a framework requiring some coding, the DXO Engine is a running engine that's primarily configured. The nearest interaction with code are JavaScript expressions, which we believe are "extremely-low-code".
  2. Complex Logic Handling: The DXO Engine allows for intricate conditional logic. For instance, based on conditions met from a Segment CDP call, it can fetch content from one CMS over another and merge outputs from different sources.
  3. Infrastructure: DXO Engine is a SaaS offering, whereas GraphQL is a framework, and you'd need to manage its infrastructure.
  4. User Interface: DXO Engine offers both Developer and Business user interfaces.
  5. Caching: DXO Engine supports Component-level caching, allowing flexible caching strategies through configuration.

Pricing and Licensing​

Q: Can you detail your licensing model?​

A: Conscia's DX Engine is licensed based on the number of API calls, premium support, Uptime SLAs, production support response requirements, and number of backend connections.

Q: Are all components offered as SaaS?​

A: Yes.

Experimentation and Testing​

Q: Does Conscia support A/B testing or similar experimentation capabilities?​

A: Yes, Conscia allows for traffic distribution among different variants when setting personalization rules.

Analytics​

Q: Do you have any alerts that help us identify if a backend system is taking too long to respond?​

A: All data processed by the DX Engine is logged and stored for up to four weeks. These logs can be exported by Conscia upon request or on a schedule. You also have the option of using our webhooks to send the orchestration responses (including response times, errors,etc) to a logging/notification service of your choice.

Data Protection and Security​

Q: How can we control where our data is stored and for how long within Conscia?​

A: There are three ways in which data may be stored within the DX Engine:

  • DX Engine Cache: Session-specific details, e.g., visitor ID, session status, etc., are stored in an internal cache. This cache is temporary and can be deleted through our Cache Invalidation API. The user has control over whether and how long to store any state in this cache, ensuring compliance with various data protection regulations.

  • DX Engine State: The state holds on to any information that you choose to hold on to during the session. The data within the State is available to all components in every orchestration flow defined within the application and hence is more versatile in its use than the cache. The Cache is limited to the response of a specific Component and the Component must be part of the orchestration flow in order for it to be able to access it. You should use Cache when you want to hold on to data from backends that are slow and you want to avoid sending unnecessary API requests to them. You should use State when several components within different orchestration flows need to be able to access and update the information within a session. An example would be items in cart, products viewed, categories clicked, etc.

  • DX Engine Logs: All data processed by the DX Engine is logged and stored for up to four weeks. When calling the DX Engine, you have the option to not store the DX Engine response in the logs via the responseLogged=false flag. These logs can be exported by Conscia upon request or on a schedule. You also have the option of routing the logs to your own logging service using the core capabilities of API orchestration.

While Conscia equips the DX Engine with robust data security features, the ultimate responsibility for configuration and usage lies with you. The DX Engine's data handling is determined by your setup, allowing you to selectively process information from various backend systems. This includes the option to exclude Personally Identifiable Information (PII) entirely, focusing only on necessary data for orchestrating digital experiences. In instances where PII is involved, such as when fetching customer data from a CRM, the DX Engine can facilitate its flow through the system. However, you can leverage the provided security mechanisms to prevent PII from being stored on our servers.

Q: What measures does Conscia employ to protect data on its platform?​

A: Conscia emphasizes both high-level and low-level security measures:

Conscia is dedicated to upholding the highest standards of data security and privacy in its operations and offerings. Our security posture is anchored in a comprehensive framework that encompasses state-of-the-art technological safeguards, rigorous compliance with global data protection regulations, and continuous risk assessment and mitigation strategies. We deploy robust encryption protocols to protect data both in transit and at rest, ensuring the confidentiality and integrity of our client's information. Our platform's infrastructure, built on secure and reliable cloud services, is regularly audited and updated to guard against evolving cyber threats. Furthermore, our commitment to security extends to our partners and vendors, ensuring a unified defense against potential vulnerabilities. At Conscia, we recognize the critical importance of trust in our client relationships, and we continuously invest in advanced security measures to maintain and strengthen this trust.

  • ISO 27001 and GDPR: Conscia is proud to maintain its ISO 27001 compliance for the last three years. ISO 27001 is an internationally recognized standard for managing information security. This compliance demonstrates our rigorous approach to securing data, managing risks, and ensuring the highest level of data protection. Additionally, we adhere to the General Data Protection Regulation (GDPR) protocols, ensuring robust privacy and data protection for our users, particularly in the European Union. This commitment to GDPR compliance reflects our dedication to upholding the privacy rights of individuals and handling data responsibly.

  • Enrcyption at Rest and in Transit: Conscia ensures the security of data through robust encryption practices. All data in transit to and from the DX Engine is encrypted (via HTTPS), ensuring that sensitive information remains protected from unauthorized access or interception. This encryption applies to all data moving between our internal systems, backend integrations, and client interfaces.

All sensitive data such as Customer Secrets such as API tokens, usernames and passwords, etc to be used to connect to backend systems are encrypted at rest.

All credentials to the DX Engine itself are managed via Keycloak, which is a widely-used open-source identity and access management solution. Keycloak stores user credentials, such as passwords, in a secure manner. It hashes passwords, ensuring that they are not stored in plain text. This means even if the data store is compromised, the hashed passwords would not be immediately usable by an attacker.

  • Limiting Data Access: All DX Engine configurations are secured via robust access controls. Access is granted at the most granular level, i.e Components and Rules, which ensures that only the authorized members of the team are given access to certain resources.

  • Deployment on Security Compliant Infrastructure The DX Engine is deployed on the robust, industry-leading infrastructure of Amazon Web Services (AWS). AWS is renowned for its comprehensive compliance and security framework, adhering to global security standards. This infrastructure includes advanced safeguards and a multi-layered security model, providing a secure foundation for our services. By deploying on AWS, Conscia benefits from the stringent security measures, data protection protocols, and continuous compliance monitoring that AWS offers, ensuring the highest level of security for our clients' data and digital experiences.

  • AWS Foundational Technical Review Our deployment on AWS infrastructure is not only about leveraging its advanced security and compliance capabilities; it also involves our adherence to AWS's Foundational Technical Review (FTR). The FTR approval signifies that our DX Engine aligns with AWS's best practices for security, reliability, and operational excellence. This review process ensures that our services are architecturally sound and optimized for high performance on AWS. Being FTR approved and listed on the AWS Marketplace underscores our commitment to delivering a secure, efficient, and robust digital experience orchestration platform, providing our clients with the assurance of a solution that meets stringent AWS standards.

Q: What security mechanisms are currently in place for the API?​

A: Our web service APIs use an Auth token for security. The DX Engine UI interface is secured using our internal OAuth provider.

Q: Is integration with IDPs and SSO authentication feasible?​

A: Yes, clients can authenticate using SSO. Presently, we handle this configuration as part of the onboarding process. We support the OpenID Connect (OIDC) Standard as well as the Security Assertion Markup Language (SAML) Standard, so clients can use their existing Enterprise IDP, such as:

  • Google Identity
  • Microsoft Azure AD
  • Okta
  • Auth0
  • GitHub
  • AWS Cognito
  • Ping Identity
  • OneLogin
  • Keycloak