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.
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.
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.
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.
- 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.
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.
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.ai 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.ai, 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 Experience Studio interface is secured using our internal OAuth provider.
Q: Is integration with IDMs and SSO authentication feasible?
A: Yes. Clients can authenticate using SSO. Presently, we handle this configuration as part of the onboarding process, but we aim to allow our partners and clients to manage this in the future.
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 through API calls, allowing for version control. You can also create or delete an entire environment via the Admin UI or the 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.
Platform Scalability and Performance
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 10ms.
MACH Alliance and Certification
Q: Is Conscia a part of the MACH alliance
A: Yes, Conscia is now a member of the MACH alliance.
Q: What features or improvements can we expect from Conscia in the near future?
A: In the upcoming months, Conscia will introduce:
- A visual canvas for orchestrating flows.
- An observability dashboard for real-time metrics on API requests.
- OAuth-based authentication for backend systems, among others.
Q: How does Conscia integrate with variosu backend APIs including Commerce Engines and Payment Gateways?
A: Conscia's DX Engine seamlessly connects to any web service endpoint through the Universal API Connector. This facilitates smooth integration and real-time communication between systems like commerce engines, payment gateways, inventory systems, promotion engines, and more, allowing for an optimized and comprehensive checkout flow.
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:
- 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.
- Infrastructure: DXO Engine is a SaaS offering, whereas GraphQL is a framework, and you'd need to manage its infrastructure.
- User Interface: DXO Engine offers both Developer and Business user interfaces.
- 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?
Q: What guidelines exist for defining versus reusing a Component?
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: Where and how is a Component created?
A: Components are JSON configurations uploaded to the DXO Engine, mainly via APIs. We're refining the documentation for this process, aiming to release it in a few weeks. If the business user UI isn't essential for the Component, the Generic Webservice Component can be employed.
Q: What are components composed of, especially regarding business rules?
A: Components can either call to an external system or modify/massage data. Business rules, which are behaviors set by users through the UI, are based on attributes defined by IT on the Component.
Q: How does Conscia.ai'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 How does Conscia manage user journeys, especially on an e-commerce front-end?
- Banners: Banners tailored for recognized users (warm user/logged user) are displayed. This involves two DXO Engine Components - one to call the Customer Data Platform (CDP) and extract customer segments, and the other to retrieve banners from the CMS based on business rules.
Product Listing Page (PLP):
- Product Display: Products are showcased based on user journeys and context. Data is sourced from various systems, including search engines, PIM systems, DAM, CMS, and commerce engines. Conscia allows two approaches for this: one that retrieves information for all product IDs collectively and another that pulls data for one record at a time.
Product Detail Page (PDP):
- Product Display: Products are displayed based on user data and context, complemented by product recommendations.
Q: Does Conscia.ai have a datastore to serve static content?
No, Conscia does not have its own datastore for static content. However, it can pre-generate payloads, allowing users to load this data into their preferred datastore.
Q: Can users invalidate the cache for specific objects in Conscia?
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?
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.
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.