The way organizations access and manage their data can significantly impact their efficiency, security, and overall success. Traditionally, many organizations have relied on direct database connections to interact with their data warehouses. 

As data environments become more complex and security needs grow, API-based data access to cloud data warehouses is emerging as a superior alternative. This blog explores why transitioning from direct database access to API-based access is not just beneficial but necessary for modern data management and how you can move to API-based access with Cube Cloud.

## What’s wrong with direct database connections?

While direct database connections have been the norm for years, they come with several drawbacks:

- Connecting directly to a database requires knowledge of the database schema, relationships between tables, and calculations, increasing the risk of inconsistencies in business logic.
- Duplication of direct database connections across analytics tools becomes extremely likely and highly unmanageable when changes are needed.
- Every direct connection reduces flexibility when the time comes to replatform the data or analytics technology, increasing the effort needed to migrate.
- Direct connections can expose databases to unauthorized access and potential breaches, especially if access controls are not consistently managed. 
- Handling high volumes of concurrent queries and data requests can strain the database, leading to performance bottlenecks. 

![](https://ucarecdn.com/c9063aa6-04c2-4599-ab7d-778a581ab509/-/quality/smart/-/format/auto/)

## Why is API-based data access better?

API-based access provides a more secure, scalable, and user-friendly approach to data management. APIs offer robust authentication and authorization mechanisms, such as OAuth and API keys, providing an additional layer of security. Fine-grained data access controls can be enforced, ensuring that users and applications have only the necessary permissions, reducing the risk of unauthorized access. 

APIs abstract the complexities of the underlying data structure, offering a simplified and consistent interface for developers, data analysts, and business users. This abstraction reduces the need for deep database knowledge, allowing developers to focus on building applications and data analysts and business users to focus on insights, rather than managing data access intricacies. In addition, APIs facilitate easier integration with various platforms and services, promoting interoperability within the data ecosystem.

APIs are designed to handle high concurrency and large volumes of requests efficiently. They can optimize queries and data retrieval processes, ensuring better performance compared to direct database queries. Techniques such as caching further enhance performance and user experience. API usage can be monitored and logged, providing valuable insights into data access patterns, performance metrics, and potential security issues. This monitoring enables better governance and management of data access, allowing organizations to identify and address problems proactively.

APIs can ensure consistency and reusability across different applications and use cases. This reduces the risk of errors and inconsistencies that might arise from direct access and ad-hoc queries. APIs can help manage and control costs by limiting the number of queries, reducing data transfer volumes, and optimizing resource usage of cloud data sources. Better visibility and management of data access costs are particularly important in cloud environments where data egress and query execution can incur significant charges.

![](https://ucarecdn.com/d083b993-64ff-400f-930e-6e2458a82d4f/-/quality/smart/-/format/auto/)

## Connect to data with Cube Cloud’s Data APIs
Cube Cloud provides extensive data API coverage for a variety of use cases, whether it’s AI, BI, spreadsheets, or embedded apps. [Data APIs](https://cube.dev/product/data-apis) are used to run queries against the data models you define. Despite using various transports and query formats, all data APIs share common [querying concepts](https://cube.dev/docs/product/apis-integrations/queries).

- __[SQL API](https://cube.dev/docs/product/apis-integrations/sql-api)__ - Delivers data over the [Postgres-compatible protocol](https://www.postgresql.org/docs/current/protocol.html) to BI tools. 
- __[REST API](https://cube.dev/docs/product/apis-integrations/rest-api)__ - Delivers data over the HTTP protocol to embedded analytics applications. 
- __[GraphQL API](https://cube.dev/docs/product/apis-integrations/graphql-api)__ - Delivers data over the HTTP protocol to [GraphQL](https://graphql.org/)-enabled data applications. 
- __[MDX API](https://cube.dev/docs/product/apis-integrations/mdx-api)__ - Provides a native interface for Microsoft Excel connections via the XMLA standard.  
- __[AI API](https://cube.dev/docs/product/apis-integrations/ai-api)__ - Provides a standard interface for interacting with large language models (LLMs) as a turnkey solution for text-to-semantic layer queries.

![](https://ucarecdn.com/196989ec-b515-4be1-bbfd-96945c04ffd4/-/quality/smart/-/format/auto/)

## How to Transition to API-based Data Access with Cube Cloud

Transitioning from direct database access to API-based access is a strategic move that requires careful planning, execution, and change management. Use the step-by-step guide for data leaders to manage this transition effectively:

1. __Assess the Current State__ - Conduct a thorough assessment of the existing data architecture and connections. Identify the systems and applications that rely on direct database access. Understand the specific requirements and use cases for Cube Cloud as the new integration point.
2. __Define Clear Objectives__ - Establish clear objectives for the transition, such as delivering consistent data definitions, centralizing data governance, and enhancing scalability. Align these objectives with the organization’s broader strategic goals.
3. __Engage Stakeholders__ - Involve key stakeholders early in the process, including developers, database administrators, data analysts, business users, and security teams. Communicate the benefits of moving to Cube Cloud API-based access and address any concerns or resistance to change.
4. __Plan the Transition__ - Develop a comprehensive transition plan with timelines, milestones, and resource allocation. Consider a phased approach, starting with less critical systems to minimize risk.
5. __Create Data Models__ - Unify fragmented business definitions with Cube Cloud’s code-first approach to [data modeling](https://cube.dev/docs/product/data-modeling/overview). Build data models for ease of use and understandability by data analysts, business users, and AI.
6. __Implement Data Access Controls__ - Centralize and enforce fine-grained [data access controls](https://cube.dev/docs/product/auth) for governance and security. Use logging for monitoring and auditing.
7. __Design for Performance and Scalability__ - Design for high performance and scale, using optimization techniques, such as [pre-aggregation caching](https://cube.dev/docs/product/caching), to improve performance and save on cloud data usage costs.
8. __Provide Documentation and Training__ - Develop comprehensive documentation for connecting with Cube Cloud, including usage guides, examples, and best practices. Offer training sessions to help developers and users transition smoothly to API-based access.
9. __Monitor and Optimize__ - Implement monitoring and analytics with real-time diagnostics to track Cube Cloud usage, performance, and potential issues. Continuously optimize data models based on feedback and usage patterns to improve efficiency and user experience.
10. __Ensure Compliance__ - Make sure your implementation complies with relevant data protection regulations and industry standards. Regularly review and update security and compliance measures to address evolving threats and requirements.

## Make the Move to Cube Cloud

Transitioning from direct database access to API-based access is a key step for organizations looking to modernize their data management practices. Cube Cloud’s data APIs offer numerous benefits, including enhanced security, simplified development, improved performance, and better cost management. 

By carefully planning and executing this transition, data leaders can unlock the full potential of their data, driving greater efficiency, security, and innovation within their organizations. [Contact sales](https://cube.dev/contact) to learn more about how Cube Cloud can be used to unify, govern, optimize, and integrate every data experience with API-based data access. 

Michael Hetrick

APIs

Why API-Based Data Access is Essential for Modern Data Management

## Intro
The MDX API in Cube Cloud is a strategic enhancement designed to meet the evolving needs of our enterprise customers. Many users are accustomed to the seamless integration and robust analytics capabilities of traditional OLAP solutions like SQL Server Analysis Services.

By enabling direct connections from Excel to Cube Cloud using MDX queries, anyone with Excel skills can perform sophisticated data analysis in a familiar environment. This integration facilitates the visualization of data in pivot tables and the utilization of Excel (or any other tool that speaks MDX) as a powerful front-end tool for slicing and dicing data across dimensions and measures.

## What is MDX
Multidimensional Expressions (MDX) is a query language specifically designed for querying and managing multidimensional data structures, such as OLAP cubes. Originally developed by a team of engineers, including Mosha Pasumansky, one of the principal architects behind SQL Server Analysis Services (SSAS), MDX was introduced with the release of OLAP Services 7.0 in the late 1990s.

Unlike SQL, which is tailored for two-dimensional, tabular datasets, MDX is designed to work with complex, multi-dimensional data structures. These structures utilize measures, dimensions, hierarchies, and attributes to support advanced data analysis. Although MDX and SQL both use clauses like SELECT, FROM, and WHERE, their purposes and applications are quite distinct, reflecting the different types of data they are intended to query.

## Architecture overview
![](https://ucarecdn.com/b0f9a26e-c4df-4952-a1a1-e3bcd08b5691/-/quality/smart/-/format/auto/)

The native MDX API in Cube Cloud enhances the universal semantic layer by enabling seamless integration with Excel's analytical tools. This support allows users to leverage Excel's powerful data analysis features while maintaining a connection to Cube’s robust data infrastructure.
Traditionally, analysts faced challenges when dealing with large datasets in Excel. They often had to pre-process and aggregate data before analysis, which disconnected their workbooks from live data sources. This process could have been more convenient and efficient, especially when updates or sharing were required.

With Cube Cloud's MDX API, Excel can directly query large datasets through the universal semantic layer. The MDX queries are translated into optimized SQL, processed by Cube, and the results are returned in a format Excel can interpret. 

Customers can extend the benefits of the universal semantic layer by allowing anyone to connect to and reuse trusted data assets and perform multi-dimensional analysis on governed data with Microsoft Excel using a live connection–no exports needed. This integration eliminates the need for pre-processing, ensures real-time data access, and streamlines complex data transformations, allowing analysts to focus on deriving insights and storytelling. 

![](https://ucarecdn.com/8abd1ce1-2ab3-45a3-96d9-6b714d29c32a/-/quality/smart/-/format/auto/)

## Enhanced Data Analysis
The MDX API in Cube Cloud unlocks advanced analytical capabilities, empowering users to perform more sophisticated and meaningful data analysis. Just like everything in Cube Cloud, the data model is the flexible foundation upon which everything else is derived. Users can gain deeper insights and more precise control over their data by leveraging features such as dimension hierarchies, measure groups, and key-based hierarchies defined in the data model.

### Dimension hierarchies
Dimension hierarchies allow users to define and navigate multiple levels of data granularity within their analyses. This powerful feature enables structured and intuitive data exploration, making uncovering insights and trends across different dimensions easier.

For example, consider a view in Cube Cloud named <code>orders_view</code> that contains data about orders, including the amount, count, and breakdown by status and geography. By defining a `Geography` hierarchy, this data can be organized into levels such as country, state, and city. This hierarchical structure facilitates a standardized drill-down path in Excel for deeper and more granular analysis.

```Python
views:
  - name: orders_view
    description: "Data about orders, amount, count and breakdown by status and geography."
    meta:
      hierarchies:
        - name: "Geography"
          levels:
            - country
            - state
            - city
```

### Measure groups
Measure groups, supported by the MDX API, allow for the organization of measures into logical groups or folders within the dataset's schema. This organizational feature enhances the clarity and usability of data analyses by grouping related metrics together.

You can define measure groups in the view's schema file:
```python
views:
  - name: orders_view
    description: "Data about orders, amount, count and breakdown by status and geography."
    meta:
      folders:
          - name: "Folder A"
            members:
              - total_amount
              - average_order_value
          - name: "Folder B"
            members:
              - completed_count
              - completed_percentage
```

### Key-Based Hierarchies
Utilize the <code>label_member</code> data model param to create key-based hierarchies, ensuring that business-friendly text names are uniquely identifiable by their keys, even when multiple entries share the same text name.

You can define measure groups in the view's schema file:
```python
dimensions:
  - name: status
    sql: STATUS
    type: string
    description: The status of the order (completed etc)
    meta:
      label_member: <another dimension name here>
```

## Security and data access controls
Authentication and authorization work the same as for the [SQL API](https://cube.dev/docs/product/apis-integrations/sql-api/security). While this may seem obvious or not particularly special, it brings significant value for enterprise-grade companies that need fine-grained data access policies that are compliant with organizational policies.

Once you set up security policies using Cube’s data modeling techniques, you instantly get the same policies across all your APIs - REST, SQL, MDX, and even AI. To maximize its use, utilize the full power of modeling techniques provided by the Cube semantic layer, like [Row-Level Security](https://cube.dev/docs/product/apis-integrations/sql-api/security#security-context-row-level-security) and query rewrite with the current user’s permissions.

### Authenticating Requests with an LDAP Catalog
In enterprise environments, LDAP (Lightweight Directory Access Protocol) is commonly used to authenticate and manage users. Integrating LDAP authentication with the MDX API ensures that user access is consistent with organizational policies and that sensitive data remains protected.
To authenticate requests to the MDX API using an LDAP catalog, [check this recipe](https://cube.dev/docs/guides/recipes/auth/sql-api-ldap).

![](https://ucarecdn.com/ea117519-36f9-4e35-8da6-fec27e57f8f8/-/quality/smart/-/format/auto/)

## Caching
Caching is essential for enhancing the performance and responsiveness of the MDX API in Cube Cloud. It minimizes redundant database access, which saves money, and speeds up data retrieval, improving user experience. Cube Cloud implements two primary levels of caching: in-memory caching and pre-aggregations.

### In-Memory Caching
In-memory caching, enabled by default, stores query results in memory for quick retrieval. When a query is made, Cube Cloud checks the in-memory cache first. If the result is available and valid, it returns instantly, bypassing the database and reducing latency.

### Pre-Aggregations
Pre-aggregations require explicit configuration and pre-compute aggregated data, drastically speeding up query performance. Defined in the data model, they are stored in the [Cube Store](https://cube.dev/blog/introducing-cubestore). When a query is received, Cube Cloud checks for relevant pre-aggregations. If found, it serves the query from pre-aggregated data; if not, the database executes it, and the result is cached.

Caching in Cube Cloud offers significant advantages: it improves performance by minimizing database queries, scales efficiently to handle more users and larger datasets without performance degradation, and reduces operational costs by lowering query frequency. Additionally, it enhances user experience by delivering faster query responses, allowing analysts to focus on insights. Leveraging both in-memory caching and pre-aggregations, Cube Cloud ensures fast, scalable, and efficient data analysis, even with large datasets in Excel.

## Conclusion
Cube Cloud’s MDX API not only enhances data analysis capabilities but also integrates seamlessly with Excel and underlying data sources, leveraging the power of the universal semantic layer. This layer serves as a bridge between data sources and data consumers, ensuring consistent and trusted insights across all endpoints—from BI tools to embedded analytics and AI agents.

Cube Cloud, designed with a code-first, developer-oriented approach, supports a wide range of deployment options, data connectivity, and native APIs. It empowers data engineers to apply software engineering best practices like CI/CD, version control, and code reviews, thereby boosting productivity and performance in data management.

By utilizing Cube Cloud’s Semantic Catalog, users gain a unified view of connected data assets that they can analyze in Excel, facilitating effortless exploration and understanding of data lineage, entities, relationships, dimensions, and metrics. This comprehensive approach not only enhances collaboration between data engineers and analysts but also streamlines data modeling and analysis processes.

In summary, Cube Cloud’s MDX API feature, combined with its universal semantic layer and robust capabilities, sets a new standard for modern multidimensional analysis in spreadsheets. It enables organizations to make informed business decisions faster, with confidence in their data integrity and insights derived from a unified data environment.

Mikhail Nitsenko

All Things Cube

MDX API in Cube Cloud unlocks advanced analytical capabilities

How to Directly Query Large Datasets with Excel 

Today, Cube is announcing the public preview of our latest API endpoint: MDX. MDX (MultiDimensional eXpression) is a query language designed to retrieve data from multidimensional OLAP cube technologies. MDX was pioneered by Microsoft in the 1990s and has proven to be a remarkably durable language, seeing broad adoption by OLAP cube vendors and downstream analytics applications. 

Conceptually, MDX is related to the SQL language in that they are both query languages, but they differ in their usage. Where SQL is oriented towards querying relational database management systems, MDX is oriented towards querying multidimensional cubes and retrieving aggregate measure values. 

A traditional spreadsheet view is an easy to understand example of a two-dimensional cube representation. In this case a measure is aggregated by dimensions as rows and columns. As a quick example, think about a SUM of Sales measure in each cell of a spreadsheet with region on the rows, and a time dimension, perhaps each month of a transaction date, along the columns.

Multidimensional cubes are interesting in that they can represent data in more dimensions than two. Imagine our prior example, but let us add an additional dimension for a product category. This becomes difficult to visualize, of course, but it is useful in many analytical contexts. 

![](https://ucarecdn.com/7b42b250-b9a1-4a12-b794-8e8fe6efacb3/-/quality/smart/-/format/auto/)

Multidimensional analysis is frequently seen in areas such as scenario planning, supply chain optimization, logistics and various financial processes. It is such a common need in finance departments, that cubes have become nearly synonymous with financial planning and analysis (FP&A) functions within enterprises. Excel is, by a wide margin, the most commonly used front-end application for users performing this type of analysis. The common pivot table within Excel is a great example of how many users experience multidimensional analysis.

## The challenge of migrating 

A major problem that we have observed here at Cube is that while these OLAP cube technologies provide a powerful analysis capability, they are tied to relational database technologies such as SQL Server, Oracle, or SAP HANA. The three most common cube technologies are tied directly to these relational databases as sources. The challenge arises when enterprises undertake migrating their data warehouse to modern cloud data warehouse or lakehouse platforms. Users then lose this baseline capability they had before to perform this type of analysis on modeled, secured, and well governed data because these modern data platforms don’t natively speak MDX as a language. Without this capability, Excel cannot perform this type of analysis in a direct connection, instead forcing users to deal with exported snapshots of data

![](https://ucarecdn.com/4341a025-c212-4db1-b0ae-20d59eda3afb/-/quality/smart/-/format/auto/)

## Ensuring direct connection to Excel

With the [new MDX endpoint](https://cube.dev/blog/how-to-directly-query-large-datasets-with-excel), Cube can effectively restore the direct connection to Excel capability that was lost, or impaired by customers who have migrated to more modern cloud data warehouse or lakehouse technologies. Cube will act as the OLAP engine in the place of technologies like SQL Server Analysis Services, Oracle Essbase, SAP HANA, and others that maintain multidimensional data models and aggregated measures. Users will simply point their MDX-speaking tools, such as Excel, at the new endpoint within Cube Cloud.

However, we are not simply replacing direct connectivity to Excel. We are also modernizing multidimensional analysis by improving it in several ways. With our pre-aggregation and caching capabilities in Cube Store we can meet and exceed the performance characteristics of older OLAP cube technologies. With our code based data modeling experience we can bring these multidimensional models into a modern data engineering work flow including version control and code review. With our advanced query rewrite capabilities, we enable Excel, and other applications that speak MDX, to query our long list of data sources live, if users choose to not use our pre-aggregations. 

We are also now the first technology to enable querying of the same data models transparently via REST, GraphQL, SQL and now MDX API endpoints. These APIs are all secured and governed in a unified security model, share a unified caching technology, and share unified performance profiling and query history capabilities. 

MDX as a supported language and API endpoint is a logical extension of Cube. In fact, we were so inspired by the concept of the multidimensional cube that it influenced the name of the open source project, and the company many years ago. We have been testing MDX heavily within Cube, and we have several customers who are using it and have provided invaluable feedback. If you would like to be a part of the public preview for this feature, please contact your Cube Cloud account team or [reach out to us via our contact form](https://cube.dev/contact?utm_source=blog&utm_content=MDX%20API%20Announcement). 

We look forward to hearing your feedback and continuing to work with you to solve your toughest analytics challenges.

Brian Bickell

Direct connectivity to Excel via a semantic layer modernizes legacy data stacks and improves data users capabilities 

Announcing the native MDX API and Excel integration for Cube Cloud

Cube’s AI API is here, and it is available on Cube Cloud Premium and higher tiers. In our newest native API, we built the ideal architecture to extend the value of your Cube Cloud investment and accelerate the development of natural language capabilities with a turnkey solution, starting with OpenAI. 

The AI API includes Retrieval Augmented Generation (RAG) and prompt engineering, for an LLM to interface with the Cube’s universal semantic layer. This simplifies the development of AI applications and features in your data products.  

We leverage our deep knowledge of Cube’s universal semantic layer, its APIs, and metadata. You benefit from this API without needing to build your own RAG, prompt engineering, or vector store of your own. This saves a huge amount of time, effort, and cost compared to developing in-house. Now, you can focus on developing the best AI agents and chatbot experiences for your customers.

## Why Is Text-to-Semantic Layer Better?

The semantic layer is the foundation for trustworthy AI access to data using LLMs. With the public preview release of our new AI API you can now use Cube’s universal semantic layer with AI. The new AI API interfaces with our existing REST API to request the data the user has asked for; it does not generate raw SQL.

The semantic layer provides the ideal middleware to stand between LLMs and data. When asking an LLM to generate raw SQL on a database schema, it’s far too easy for it to hallucinate or get small things wrong as we saw in our webinar, [Delivering on the Promise of AI](https://cube.dev/events/delivering-on-the-promise-of-ai-increasing-accuracy-with-a-semantic-layer). 

The semantic layer provides context and also constrains what the LLM can answer with. LLMs have been trained on language itself–nouns, adjectives,  etc. Semantic layers provide LLMs with objects that are equivalent to these language elements: entities for nouns, dimensions/attributes for adjectives,  and measures for quantitative description. The LLM has the choice of the objects in the semantic layer and their attributes defined there, to answer questions with - not the whole knowledge it has been trained on.

This is just the first part, and is true of providing knowledge graph access to an LLM too. Semantic layers are special knowledge graphs, designed for querying data. Semantic layers, like Cube, provide APIs which have much more constrained input than raw SQL. If an LLM is forced to generate such an API request, it is much less likely to make a technically valid hallucination. Add to this, the fact that Cube is still compiling the request into raw SQL, doing the joins, aggregation, and filtering deterministically with our best-in-class compiler. The LLM is again constrained from work that it couldn’t reliably get correct.

![](https://ucarecdn.com/35b2c82f-5ba9-43c9-a13e-f470d8bc076d/-/quality/smart/-/format/auto/)

## Preparing Cube Data Models for Generative AI
You will use existing views within Cube Cloud to keep it DRY (Don’t Repeat Yourself); however, there are likely some modifications needed to work with the new AI API, as compared to other use cases.

Imagine that a data engineer from another company is reviewing your data model. The baseline test for preparing your data model for Generative AI is: **Is it clear enough that a data engineer from another company would understand it?** If the answer is yes because you’ve used clear, plain-language, readable terms and don’t have a lot of acronyms or company lingo, then it is likely that it can work with this API.

Don’t worry if this isn’t the case though, a few simple modifications can make all the difference. You don’t need to rework your whole semantic layer, just the parts that you want to expose to the AI API. First, ensure that you are working with Views in Cube Cloud, then use the following best practices to prepare it for use with the AI API:

- **Use clear, standard names.** Make names understandable, i.e. call a customer a Customer not some strange acronym like CustAcctNm that only people in your company use.
- **Add verbose descriptions.** Explain the member's purpose clearly. If you don’t want to put too much in the description field, in case it confuses human users, you can use a meta-tag to add more detail for the Cube AI API to pick up on. It’s helpful to mention in either if people use synonyms or acronyms to refer to that entity or member, if specific values for the field have special meanings etc. 
- **Make member names distinct.** If you have multiples of the same type of member, such as timestamp fields, try to make it very clear as to the use case for the field. For example, order_timestamp for when the order was made, and shipped_timestamp for when an order was shipped. Again, where there is ambiguity, you can describe how to treat it in the descriptions or meta-tag as if you were talking to a colleague.

![](https://ucarecdn.com/6dc9578a-9e83-4d6d-93f1-997a68cd5ed1/-/preview/932x295/)
## Testing the AI API with Postman
Once you have your views built and the AI API enabled (see the topic for the AI API in docs for more info on that), you’ll naturally want to try it out. An easy way to test is to use an API testing tool like Postman that lets you send API requests and inspect responses.

To get started, click the “Import” button in the top left or press Command+O. Then, paste the following example request in and hit enter:

```
curl \
 -X POST  \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer EXAMPLE-API-TOKEN" \
 --data '{ "messages": [{ "role": "user", "content": "what cities do we have the most sales in?" }]}' \
 https://YOUR_CUBE_API/cubejs-api/v1/ai/query/completions
 ```

This brings up a request. Replace YOUR_CUBE_API in the URL with your own Cube Cloud API, and EXAMPLE-API-TOKEN in the authorization header with a valid JWT for your Cube deployment.

In the request body, replace the question in “content” with something relevant to your own data set and the view(s) that you created.

After you hit Run, you will get a response that looks like the following: 
![](https://ucarecdn.com/50f63e71-5c35-41c9-ad1b-0bb93952cae3/-/preview/1000x561/)

This is a Cube query on your data, generated by AI! To run it, just copy the Cube query into a request to Cube’s REST API’s /load endpoint. Alternatively, you can add` "runQuery": true` to the AI API request body to run it inline.

<video width="100%" controls><source src="https://ucarecdn.com/16eee2fd-02ea-4311-90e7-ae3f4142c7c3/" type="video/mp4"/></video>

For example, in the video above, we ask the AI API for the cities where we have the most sales. It gives us back a Cube query using the Line Items view: total amount by city, top 10 descending. When we run the query, we can see that Los Angeles is where we have the most sales, followed by Seattle and Mountain View.

And now you’ve run your first Cube query using AI! Feel free to explore, add more messages to the conversation, and ask other questions to get a feel for what it can do.

## Get Started with the AI API
The release of Cube Cloud’s new AI API simplifies the development of Generative AI experiences for embedded developers and data engineers, while natural language interactions lower the barrier for every user of your product or solution–both inside or outside of your organization. 

We will continue to invest in the AI API and improve it over time, allowing all teams who deploy using our AI API to benefit from these enhancements as we release them. When it comes to how to use the Cube Cloud’s universal semantic layer with AI, we’ll do the heavy lifting, so you can focus on building sophisticated data experiences. To get started with the AI API in preview, [contact sales to learn more!](https://cube.dev/contact?utm_source=blog&utm_medium=site&UTM_Publisher=Cube&leads[…]tion&campaignid=701UH000009UsImYAK&utm_content=Contact%20Request)

David Jayatillake 

Artificial Intelligence

A Practical Guide to Getting Started with Cube's AI API

Adnan Rahic

GraphQL

Building extremely fast, low-latency GraphQL APIs with Apollo and Cube.

GraphQL federation example with Apollo Federation and Apollo GraphOS

Use Hasura Remote Schemas to build a low-latency data application.

GraphQL federation with Hasura GraphQL Engine

You're bound to have heard the term GraphQL. Unless you live under a rock. I doubt that though. GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.

This tutorial will show you a step-by-step guide on how to use a GraphQL API to build Postgres metrics dashboards.

Here's what the end product will look like. You can also check out the [live preview](https://graphql-postgres-metrics-dashboard.netlify.app/).

![frame_chrome_mac_light - 2021-12-16T143822.307.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8a8507fb-4c19-4069-a178-9bd1036f7e06.png)

GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more. GraphQL makes it easier to evolve APIs over time and enables powerful developer tools.

The incredible growth in GraphQL's popularity has been noticed by the amazing Cube community. Our community longed for a GraphQL integration, and we listened.

### How the GraphQL API was added to Cube

I'd like to give a huge shout-out to [Luc Vauvillier](https://twitter.com/lvauvillier) who contributed initial support for the GraphQL API and laid out the principal design. Luc is the co-founder at [Gadsme](https://www.gadsme.com/). Check [this out to read more](https://cube.dev/blog/gadsme-runs-on-cube/) about how Gadsme builds awesome stuff with Cube[.](https://cube.dev/blog/gadsme-runs-on-cube/)

We at Cube were thrilled to jump on the problem at hand and build out a GraphQL API. As of the `0.29` release of Cube, you can use the GraphQL API!

### Set up Cube with GraphQL and Postgres

To configure Cube, I first needed to connect a database. I used a demo Postgres database with e-commerce data. The process of connecting a database is identical whether you're using a self-hosted instance of Cube, or Cube Cloud.

I selected PostgreSQL from the list of database options. Cube [supports dozens of databases](https://cube.dev/docs/config/databases), you can select from any mainstream database or data warehouse on the market.

![frame_chrome_mac_light_(37).png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/9ca37d9b-cdc4-4ebd-a41b-31b1ded693e5.png)

Next, I had to add values to connect to my sample PostgreSQL e-commerce database. If you're using a self-hosted Cube instance, you need to [configure a few environment variables](https://cube.dev/docs/config/databases/postgres).

In Cube Cloud, it looks like this.

![frame_chrome_mac_light_(50).png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/f44924c6-b117-4d50-9d78-11625238b4b9.png)

Once the connection is established, I have to generate a data schema. Selecting the `public` table and clicking generate will build a Cube data schema for me to work with.

![frame_chrome_mac_light_(51).png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/ec5c7697-c698-4d8c-938e-8fdeb2193b7f.png)

Now I have access to my Cube cluster. In Cube Cloud you should always enable cluster mode for improved performance if you want to run reliably in production.

This will make sure your resources will autoscale based on the load. There's no additional cost for autoscaling, and the [pricing model for Cube Cloud](https://cube.dev/pricing) is based on throughput.

![frame_chrome_mac_light_(22).png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/00d52f17-d1c7-4768-b692-6fbb78954d33.png)

Next up, I ran a set of queries in the Cube Playground to determine what data I need to make the metrics dashboard.

First of all, I want to run a sample query to list orders by status grouped by day.

![frame_chrome_mac_light - 2021-12-16T143829.494.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/e23359d8-70a7-4a60-b842-4632c8a0680c.png)

Let's open up the Cube GraphiQL interface and run this same query with GraphQL. You can [read more about the GraphQL API in our docs](https://cube.dev/docs/backend/graphql/).

Here's what the GraphQL query looks like for the example above.

![frame_chrome_mac_light - 2021-12-16T143831.756.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/efd2ca84-0c97-4118-8743-96b6066a3830.png)

```graphql
query CubeQuery {
  cube(limit: 10) {
    orders(orderBy: { count: desc }) {
      count
      status
      createdAt {
        day
      }
    }
  }
}
```

Running this query in GraphiQL will return the values just like in the playground. Now we're done with the setup, let's move on to some more complex queries.

### Running Analytical GraphQL Queries

Lets add a `where` clause with a time dimension to the GraphQL query.

```graphql
query CubeQuery {
  cube(
    limit: 10
    where: { orders: { createdAt: { inDateRange: "This year" } } }
  ) {
    orders(orderBy: { count: desc }) {
      count
      status
      createdAt {
        day
      }
    }
  }
}
```

Running this query in GraphiQL will return this result set.

![frame_chrome_mac_light - 2021-12-16T143833.925.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/66776d34-964a-4956-8148-77ba785fec95.png)

I also want to run another query with only completed order statuses.

```graphql
query CubeQuery {
  cube(
    limit: 10
    where: {
      orders: {
        status: { equals: "completed" }
        createdAt: { inDateRange: "This year" }
      }
    }
  ) {
    orders(orderBy: { count: desc }) {
      count
      status
      createdAt {
        day
      }
    }
  }
}
```

![frame_chrome_mac_light - 2021-12-16T143836.210.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/2965b57a-2d0a-4d28-95a9-c8d03e5e9afc.png)

These queries will be perfect for building my metrics dashboard. Next, we need to build an app to display the metrics.

### Visualize Postgres Data with GraphQL

I'll start by building a React app and using Chart.js to display the metrics.

```bash
npx create-react-app dashboard-app
cd dashboard-app
yarn add @apollo/client graphql chart.js react-chartjs-2 apollo-link-http
npm start
```

This will give me a blank React app. I then add the Apollo client and all the required dependencies for building the charts.

Next up, create the file **`src/ApolloClient/client.js`** and insert the following code.

```jsx
import { ApolloClient, ApolloLink, InMemoryCache } from "@apollo/client";
import { HttpLink } from "apollo-link-http";

const uri = 'https://tan-rooster.aws-eu-central-1.cubecloudapp.dev/cubejs-api/graphql'
const httpLink = new HttpLink({ uri });

let appJWTToken = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoiYWRtaW4ifQ.UHnffynBjuE3dcwEUyqldVbN-5QzMT-oiyXqkRbWJOI'
const authMiddleware = new ApolloLink((operation, forward)=> {
  if (appJWTToken) {
    operation.setContext({
      headers: {
        Authorization: `${appJWTToken}`
      }
    });
  } 
  return forward(operation);
});

export const clientWithCubeCloud = new ApolloClient({
  cache: new InMemoryCache(),
  link: authMiddleware.concat(httpLink),
});
```

Make sure to edit your `uri` and `appJWTToken` to use your values from Cube Cloud. You can get those values from the Overview tab by clicking the `How to connect` button.

![frame_chrome_mac_light - 2021-12-16T143824.985.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/b499ee43-e261-4086-a8d4-0e7dfb4ed812.png)

Now you have to make the Apollo client available to the rest of your app. Update your **`src/index.js`** to look as follows.

```jsx
import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import App from './App';
import reportWebVitals from './reportWebVitals';
import { client } from './ApolloClient/client';
import { ApolloProvider } from '@apollo/client';

ReactDOM.render(
  <ApolloProvider client={clientWithCubeCloud}>
    <App />
  </ApolloProvider>,
  document.getElementById('root')
);

// If you want to start measuring performance in your app, pass a function
// to log results (for example: reportWebVitals(console.log))
// or send to an analytics endpoint. Learn more: https://bit.ly/CRA-vitals
reportWebVitals();
```

Nice! Now you can move on to create the chart component, and then call the GraphQL query from the chart itself.

Create a folder called `src/Charts` and create a file called `src/Charts/BarChart.js`. Paste this code into it.

```jsx
import React from "react";
import { gql, useQuery } from '@apollo/client';
import { getRandomColor, formatDate } from './Helpers'
import { Bar } from 'react-chartjs-2';
import { Chart as ChartJS, BarElement, Title, CategoryScale, LinearScale, Tooltip, Legend } from 'chart.js';
ChartJS.register(BarElement, Title, CategoryScale, LinearScale, Tooltip, Legend);

const COMPLETEDORDERS = gql`
  query CubeQuery {
    cube(
      limit: 10
      where: {
        orders: {
          status: { equals: "completed" }
          createdAt: { inDateRange: "This year" }
        }
      }
    ) {
      orders(orderBy: { count: desc }) {
        count
        status
        createdAt {
          day
        }
      }
    }
  }
`;

const GenerateChart = () => {
  const { data, loading, error } = useQuery(COMPLETEDORDERS);

  if (loading) {
    return <div>loading</div>;
  }

  if (error) {
    return <div>{error}</div>;
  }

  if (!data) {
    return null;
  }

  const chartData = {
    labels: ['Daily Completed Orders in 2021'],
    datasets: data.cube
      .map(o => o.orders)
      .map(o => {
        return {
          data: [o.count],
          label: formatDate(new Date(o.createdAt.day)),
          backgroundColor: [getRandomColor()],
        };
      })
  }

  return (
    <Bar
      data={chartData}
    />
  );
}

const BarChart = () => {
  return (
    <div style={{ margin: "10px", paddingTop: "65px" }}>
      <h2 style={{ margin: "10px", textAlign: "center" }}>
        Bar Chart
      </h2>
      <div style={{ margin: "10px 100px", padding: "10px 100px" }}>
        <GenerateChart />
      </div>
    </div>
  );
};

export { BarChart };
```

You'll also need to create a file called `src/Charts/Helpers.js`. Paste this code.

```jsx
function getRandomColor() {
  function hexToRgbA(hex){
    let c;
    if(/^#([A-Fa-f0-9]{3}){1,2}$/.test(hex)){
        c= hex.substring(1).split('');
        if(c.length === 3){
            c= [c[0], c[0], c[1], c[1], c[2], c[2]];
        }
        c= '0x'+c.join('');
        return 'rgba('+[(c>>16)&255, (c>>8)&255, c&255].join(',')+',0.5)';
    }
    throw new Error('Bad Hex');
  }

  const letters = '0123456789ABCDEF';
  let color = '#';
  for (let i = 0; i < 6; i++) {
    color += letters[Math.floor(Math.random() * 16)];
  }

  return hexToRgbA(color);
}

function formatDate(date) {
  let d = new Date(date),
      month = '' + (d.getMonth() + 1),
      day = '' + d.getDate(),
      year = d.getFullYear();

  if (month.length < 2) 
      month = '0' + month;
  if (day.length < 2) 
      day = '0' + day;

  return [day, month, year].join('-');
}

export {
  getRandomColor,
  formatDate
};
```

Once you're done with that, you need to create a file called `src/Charts/index.js` to export the chart.

```jsx
export { BarChart } from './BarChart';
```

Lastly, edit the `App.js` and import the chart.

```jsx
import './App.css';
import {
  BarChart,
} from './Charts';

function App() {
  return (
    <div className="App">
      <BarChart />
    </div>
  );
}

export default App;
```

Go back to the browser where the React app is running. You should see this fancy chart pop up!

![frame_chrome_mac_light - 2021-12-16T143822.307.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8a8507fb-4c19-4069-a178-9bd1036f7e06.png)

As of today, this means you can use Cube's GraphQL API for building any type of metrics dashboard. Alongside the REST API and SQL API, you have an entire toolset at your disposal to choose from.

But I'm not done here yet. Let's add some role-based access control, also called RBAC.

### Add Role-Based Access Control with JWT Tokens

You get [multi-tenancy and RBAC in Cube](https://cube.dev/docs/security/context#top) out of the box. Let's add a security context in the Apollo client to enable RBAC.

Just like with the REST API you can add security and RBAC with JWT tokens. First open up the Env vars tab in your Cube Cloud deployment settings.

![frame_chrome_mac_light - 2021-12-16T143827.204.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/c96be748-74ef-453d-ba38-f0019cd23345.png)

Find the `CUBEJS_API_SECRET` environment variable and copy it. This is the API secret that secures your API. Take the value and create a JWT token with [jwt.io](http://jwt.io) , make sure to add `{ "role": "admin" }` to the payload.

![frame_chrome_mac_light - 2021-12-16T143840.773.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/2b4bf733-fb93-4576-af03-8a28e400337e.png)

You can now copy the JWT token and open up the `src/ApolloClient/client.js` file. Add the token value to the `appJWTToken` variable. Here's what it should look like.

```jsx
import { ApolloClient, ApolloLink, InMemoryCache } from "@apollo/client";
import { HttpLink } from "apollo-link-http";
const uri = 'http://localhost:4000/cubejs-api/graphql'

const httpLink = new HttpLink({ uri });

let appJWTToken = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJyb2xlIjoiYWRtaW4ifQ.FUewE3jySlmMD3DnOeDaMPBqTqirLQeuRG_--O5oPNw';
const authMiddleware = new ApolloLink((operation, forward)=> {
  if (appJWTToken) {
    operation.setContext({
      headers: {
        Authorization: `${appJWTToken}`
      }
    });
  } 
  return forward(operation);
});

export const clientWithJwt = new ApolloClient({
  cache: new InMemoryCache(),
  link: authMiddleware.concat(httpLink),
});
```

Next, add the security context and RBAC to the `cube.js` file.

```js
// Cube.js configuration options: https://cube.dev/docs/config
module.exports = {
  queryRewrite: (query, { securityContext }) => {
    if (!securityContext.role) {
      throw new Error('No role found in Security Context!');
    }

    if (!securityContext.role === 'admin') {
      throw new Error('You\'re not the Admin!');
    }

    return query;
  },
};
```

Here's what it looks like in Cube Cloud.

![frame_chrome_mac_light - 2021-12-16T143838.484.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/2d108149-e4bf-436f-bf61-ca0396daaa44.png)

You can add any particular logic you might want like RBAC, multi-tenancy, row-level access, and more.

Now, jump back to the dashboard-app. Restart it, and voila, you've added RBAC. The end outcome is this lovely chart showing orders per day for the whole of 2021 that you can only access with the `admin` role. If you remove the `appJWTToken`, your dashboard-app won't be able to fetch data anymore.

If you want to check out the source code in one place, here's the [GitHub repo](https://github.com/cube-js/cube.js/tree/master/examples/graphql-api-metrics-dashboard). And, you can also have a look at the [live preview here](https://graphql-postgres-metrics-dashboard.netlify.app/).

![frame_chrome_mac_light - 2021-12-16T143822.307.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/8a8507fb-4c19-4069-a178-9bd1036f7e06.png)

### Conclusion

In this tutorial, I wanted to show a step-by-step guide on how to use Cube's GraphQL API to build a metrics dashboard with data from a Postgres database.

With Cube Cloud you get a metrics layer that integrates with every major data visualization library including GraphQL compatible tools like [Chart.js](https://www.chartjs.org/) and [react-chartjs-2](https://react-chartjs-2.netlify.app/). On top of all that, it also comes with multi-tenancy support out-of-the-box. Among the different multi-tenancy options, you can enable tenant-based row-level security, role-based access, using multiple database instances, multiple schemas, and more.

If you want to learn more about GraphQL with [Cube](https://cube.dev/) check out [our announcement](https://cube.dev/blog/introducing-cube-graphql) that explains how we added the GraphQL API to Cube.

You can [register for Cube Cloud](https://cube.dev/cloud) right away if you want to have a look!

I'd love to hear your feedback about using GraphQL with Cube Cloud in the Cube Community Slack. [Click here to join](https://slack.cube.dev/)!

Until next time, stay curious, and have fun coding. Also, feel free to [leave Cube a ⭐ on GitHub](https://github.com/cube-js/cube.js) if you liked this article. ✌️

PostgreSQL

GraphQL Postgres Metrics Dashboard with Cube

At Cube, we’ve been excited to watch GraphQL’s growth in popularity and the rise of a rich and mature ecosystem of GraphQL front-end integrations and back-end tools. GraphQL has quickly become the most popular query language for APIs because it provides a complete description of the data in your API—giving clients the power to ask for exactly the data they need and nothing more.

However, I believe that while the GraphQL ecosystem is rich in tools focused on creating transactional (a.k.a. CRUD) GraphQL servers, analytical workloads are still underserved. This is particularly true for workloads designed on top of data warehouses.

For more than a year, a Cube GraphQL API has been the top requested feature from the Cube community. There’s clearly tremendous value for GraphQL users in having a uniform way to access both transactional and analytical APIs, in order to keep the data layer unified and organized. 

**Today, we are excited to announce GraphQL API support in Cube.** With this release, you can use Cube as part of your GraphQL layer to deliver metrics to your application.

We owe tremendous thanks to [Luc Vauvillier](https://twitter.com/lvauvillier), the COO and a co-founder at [Gadsme](https://cube.dev/blog/gadsme-runs-on-cube/), who contributed initial support for this GraphQL API and layed out the principal design:

> “With GraphQL support in Cube we can have a unified typed API for our frontend clients and be able to run code generators”. We built a GraphQL proxy on top of the Cube REST API internally first. Then we started to share our API design with the community, and when we realized that the additional work to make it generic would not be too substantial, we decided to contribute to have it officially supported. At [Gadsme](https://www.gadsme.com/), contributing to open source projects is part of our values and we really enjoyed working on this.”

With this API and [our recently-released SQL API](https://cube.dev/blog/introducing-cube-sql/), Cube can provide analytics data to a wide variety of tools and clients building towards our vision of a universal, headless analytics layer to provide metrics to any application. 

![image2.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/c957b4c8-5ea0-4d61-a610-21749d799953.png)

### Getting Started with the GraphQL API

Cube uses a JSON-based metrics framework to describe data calculations that can be exposed via GraphQL. Once defined, Cube will use these definitions to translate an incoming GraphQL query into a native SQL query to the underlying data storage layer.

Let’s consider the following example of Cube’s metrics framework that can be used to model orders in a hypothetical ecommerce data store:

```js
cube(`Orders`, {
  sql: `SELECT * FROM public.orders`,

  measures: {
    count: {
      type: `count`,
    },
  },

  dimensions: {
    status: {
      sql: `status`,
      type: `string`,
    },

    createdAt: {
      sql: `created_at`,
      type: `time`,
    },
  },
});
```

The main object in Cube’s merics framework is **cube**. Cubes always have the **sql** property. Usually, this points to the SQL table to which this configuration applies, but in more sophisticated use cases, a custom SQL query can be used as a property.

**Measures** are quantitative data—such as the number of units sold, unique visits, profit, and so forth. **Dimensions** are categorical data, such as state, gender, product name, or units of time. (You can learn more about Cube’s data schema [in our docs](https://cube.dev/docs/schema/fundamentals/concepts).)

Once the above definitions are created, we can start querying Cube via the GraphQL API. To get **“Number of orders grouped by status,”** we can use the following query:

```graphql
{
  cube {
    orders {
      count
      status
    }
  }
}
```

Cube will translate the above GraphQL query into a native SQL for your database and execute it. For example, if your database is Postgres, it would be the following SQL query: 


```sql
SELECT
  "orders".status "orders__status",
  count("orders".id) "orders__count"
FROM
  public.orders AS "orders"
GROUP BY
  1
ORDER BY
  2 DESC
LIMIT
  10000
```

Cube users probably are aware that Cube comes with [Developer Playground](https://cube.dev/docs/dev-tools/dev-playground), a useful tool to build and test metrics layer. Now, the Playground includes a built-in GraphiQL to test GraphQL API calls.

![image3.png](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/ab96e549-46c4-42d5-889b-f4edfc530256.png)

To get started with the GraphQL API from scratch, you can follow this [step-by-step guide](https://cube.dev/blog/graphql-postgres-metrics-dashboard-with-cube/). 

We’re excited about finally bringing GraphQL support to Cube, and we hope you are, too!  We’d love to hear your feature requests and use cases; please provide your feedback in our [Slack](http://slack.cube.dev/).

Want to learn more? [Give Cube a free try](https://cubecloud.dev/auth/signup).

Artyom Keydunov

News

Introducing the Cube GraphQL API: Building GraphQL Endpoints for Metrics

[Gadsme](https://www.gadsme.com/) (literally Ads in Game) was founded in 2019 to provide an advertising platform designed for the gaming and e-sports industries. We are engaged in the serving of non-intrusive advertising embedded within scenes of video games.

Gadsme work with major video game studios and serve millions of ads every day. We keep innovating to bring new brand experiences to this area.

![Gadsme stock photo](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/66b39395-d91d-469c-a29d-7af29f21f708.jpeg)

## How Gadsme started using Cube

The Gadsme team first heard of Cube in 2019 after reading a post on Hacker News. At the time, we were focusing more on developing our cross-platform advertising SDK. When it came to building our [real-time analytics](https://cube.dev/use-cases/real-time-analytics) solution, Cube was the perfect tool to ease iterations around how data insights can be exposed efficiently to our clients. Now, all our dashboards (e.g., for ad requests, impression, fill rate, [eCPM](https://en.wikipedia.org/wiki/Cost_per_mille#Effective_cost_per_mille), etc.) and reporting API use Cube under the hood.

As an AdTech company, Gadsme collects millions of events every day. All those events are stored in BigQuery. With Cube and its built-in pre-aggregations feature, we were able to expose meaningful data with speed and maintain complete control of analytics costs.

## How Cube was implemented at Gadsme 

Our team used pre-aggregations since day one. We were first using Postgres as an external [pre-aggregations database](https://cube.dev/docs/caching/using-pre-aggregations#pre-aggregations-storage) and now we have been using Cube Store in production since July 2021. This last move to Cube Store brought a noticeable speed-up in the loading times of data and graphs for our client dashboards.

We run Cube on Kubernetes, and we spent some time improving the deployment automation of Cube using Helm Charts.

We also use GraphQL to build all our APIs. We decided not to expose Cube directly and preferred building a GraphQL proxy on top of Cube's [REST API](https://cube.dev/docs/rest-api) (see our architecture diagram below).

![Architecture Diagram](https://cubedev-blog-images.s3.us-east-2.amazonaws.com/63a6a07f-4d68-4925-a0d9-1c1df168e888.png)

In November, we started a new [contribution](https://github.com/cube-js/cube.js/pull/3555) to the Cube project to bring the first official support of a GraphQL API. This new API is available since Cube [v0.28.58](https://github.com/cube-js/cube.js/releases/tag/v0.28.58) and supports the following features:

* API autogeneration based on Cube definitions
* Directives support
* Compatibility with the authorization layer (e.g., [JSON Web Tokens](https://cube.dev/docs/security/context), [queryRewrite](https://cube.dev/docs/config#query-rewrite), [multitenancy](https://cube.dev/docs/product/configuration/advanced/multitenancy), etc.)

We also had the opportunity to discuss our GraphQL contribution during the [November community call](https://www.youtube.com/watch?v=EQ5Wl4yn71c&list=PLtdXl_QTQjpb1dHZCM09qKTsgvgqjSvc9), and we’d welcome your feedback on our contributions not only for GraphQL, but also for Helm Charts. 

## Interested in joining Gadsme's success with Cube?

Explore Cube [examples & tutorials](https://cube.dev/docs/examples) and [get started](https://cube.dev/docs/getting-started) today. To jumpstart your efforts, please join us on [Discourse](https://forum.cube.dev/) & [Slack](https://slack.cube.dev/), follow us on [Twitter](https://twitter.com/thecubejs), and get engaged with the growing Cube community. 

APIs

GraphQL

Why API-Based Data Access is Essential for Modern Data Management

How to Directly Query Large Datasets with Excel

Announcing the native MDX API and Excel integration for Cube Cloud

A Practical Guide to Getting Started with Cube's AI API

GraphQL federation example with Apollo Federation and Apollo GraphOS

Get Cube updates to your inbox

GraphQL federation with Hasura GraphQL Engine

GraphQL Postgres Metrics Dashboard with Cube

Introducing the Cube GraphQL API: Building GraphQL Endpoints for Metrics

How Gadsme is using Cube for analytics on their in-game advertising platform

Upgrade your data stack today

D3 Dashboard Tutorial

React Dashboard: an Ultimate Guide