17 ms·

Cube.js – Open-Source Analytics API for Building Data Apps

93 points by chetangoti 5y ago

peiback 5y ago
Thanks for sharing! I'm on Cube's product team and we'd love your feedback on what else we can do to improve Cube. We also welcome your input on our Slack/GH. I've worked on a few open-source projects, so I'll just share what I personally love about Cube and what drew me to the project in the first place: 1) It has an un-opinionated but well supported front-end dev experience focused around an intuitive OLAP-based API. OLAP = think measures, dimensions, etc. What I mean by "un-opinionated" is we expect most developers want to create their own visualization layer, whether that's a dashboard, a report, or just any kind of data-intensive app you can imagine, instead of being forced to embed a hardset iframe, for example. But this is still a well-supported workflow in Cube, despite the customizability, as we enabled code-generation features that also work for most major JS UI frameworks (Angular, React, Vue). And, we're now actively working on a SQL connector for Cube, too, so if you want to query Cube with a SQL-driven BI tool like Apache Superset, that'll soon be doable, too. Additionally, a GraphQL interface is potentially coming soon, too (Cube's API is currently REST). 2) It has the ability to read data from all the major modern databases, warehouses, and query engines. I saw a comment above about Snowflake, and yea, that and other big data platforms out there have been our primary focus this year, so we've made recent improvements here, in terms of performance and reliability. We're now working on integrations for streaming datasources, e.g Kafka. I'm particularly excited about this! 3) Slow queries are problematic, especially in dashboards. I don't know about you, but it really bugs me to see wonderful apps everywhere with poor analytics user-experiences, with load times at half a minute or more. One of Cube's best features here (and, admittedly, perhaps one of the more complex ones to understand, which we're working on, too :), is made possible by pre-aggregations and Cube Store, the caching component of Cube specifically designed and fine-tuned for querying large datasets. You can think of a pre-aggregation as a condensed, materialized view of your query results that can serve multiple permutations of queries, and yet are decently efficient with data freshness as well as minimizing your backend data processing costs. We’re also extremely fortunate to have such a supportive open-source community that propelled this project forward much further than we could have imagined; y’all’s trust in this project and its continued enhancement is what has really kept it going and growing.
danielvaughn 5y ago
Last year my (former) team and I spent months evaluating BI solutions. Every week we were having meetings with companies like Tableau, Looker, etc. In the end, my opinion was that we should just use CubeJS. Unfortunately it wasn’t mature enough at that time, as it had only recently begun to support Snowflake (our backend). If I were a betting man, I’d say they’ve got a very bright future ahead of them. Really cool product and idea.
- mrwnmonm 5y ago
  I am building a BI solution, with a different approach. What were you looking for in those solutions?
  - deleted 5y ago
    [deleted]
  - tenaciousDaniel 5y ago
    Nice! The space is pretty ripe for disruption because basically all of the tools are pretty old-school. Here are the things I really wanted: 1. Create dynamic schemas. Some of our clients had their own dimensions that they cared about. 2. Pick the level of integration. Imagine having an out-of-the-box integration available, but then offering fully customizable solutions for one-off scenarios. Really it comes down to those two things, which basically means "flexibility". Like I said, we spent months evaluating products, and while we found several companies claim to offer the above, no one actually did.
    - tenaciousDaniel 5y ago
      One thing I did not like about CubeJS (not sure if they've changed this), is that their integration is its own standalone server. Like, if you have an existing server, it didn't seem possible to just integrate it into what you already have. That was kind of a bummer, but it wasn't a deal breaker.
      - igorlukanin 5y ago
ushakov 5y ago
how does it compare to Hasura?
- peiback 5y ago
  In essence, you may want Hasura/GraphQL if you have no idea how the end-users' query format will look, whereas Cube is well-suited for providing performant results for somewhat predictable sets of queries. Disclaimer: I work on Cube. My colleague Igor explains it better: Hasura is for CRUD with reasonable performance, Cube is for fetching analytical (quantitative) data with sub-second latency and high concurrency. Hasura is great as a general-purpose data backend, Cube is great as an API for analytics. Obviously, they can be used in the same app, e.g., a blog can serve posts and comments from Hasura and show an upvotes/downvotes chart or a rating of most productive commenters via Cube. And here are a few user stories: https://cube.dev/blog/category/user-stories/ https://cube.dev/blog/category/user-stories/

93 points by chetangoti 5y ago

Thanks for sharing! I'm on Cube's product team and we'd love your feedback on what else we can do to improve Cube. We also welcome your input on our Slack/GH. I've worked on a few open-source projects, so I'll just share what I personally love about Cube and what drew me to the project in the first place: 1) It has an un-opinionated but well supported front-end dev experience focused around an intuitive OLAP-based API. OLAP = think measures, dimensions, etc. What I mean by "un-opinionated" is we expect most developers want to create their own visualization layer, whether that's a dashboard, a report, or just any kind of data-intensive app you can imagine, instead of being forced to embed a hardset iframe, for example. But this is still a well-supported workflow in Cube, despite the customizability, as we enabled code-generation features that also work for most major JS UI frameworks (Angular, React, Vue). And, we're now actively working on a SQL connector for Cube, too, so if you want to query Cube with a SQL-driven BI tool like Apache Superset, that'll soon be doable, too. Additionally, a GraphQL interface is potentially coming soon, too (Cube's API is currently REST). 2) It has the ability to read data from all the major modern databases, warehouses, and query engines. I saw a comment above about Snowflake, and yea, that and other big data platforms out there have been our primary focus this year, so we've made recent improvements here, in terms of performance and reliability. We're now working on integrations for streaming datasources, e.g Kafka. I'm particularly excited about this! 3) Slow queries are problematic, especially in dashboards. I don't know about you, but it really bugs me to see wonderful apps everywhere with poor analytics user-experiences, with load times at half a minute or more. One of Cube's best features here (and, admittedly, perhaps one of the more complex ones to understand, which we're working on, too :), is made possible by pre-aggregations and Cube Store, the caching component of Cube specifically designed and fine-tuned for querying large datasets. You can think of a pre-aggregation as a condensed, materialized view of your query results that can serve multiple permutations of queries, and yet are decently efficient with data freshness as well as minimizing your backend data processing costs. We’re also extremely fortunate to have such a supportive open-source community that propelled this project forward much further than we could have imagined; y’all’s trust in this project and its continued enhancement is what has really kept it going and growing.

danielvaughn 5y ago

Last year my (former) team and I spent months evaluating BI solutions. Every week we were having meetings with companies like Tableau, Looker, etc. In the end, my opinion was that we should just use CubeJS. Unfortunately it wasn’t mature enough at that time, as it had only recently begun to support Snowflake (our backend). If I were a betting man, I’d say they’ve got a very bright future ahead of them. Really cool product and idea.

mrwnmonm 5y ago
I am building a BI solution, with a different approach. What were you looking for in those solutions?
- deleted 5y ago
  [deleted]
- tenaciousDaniel 5y ago
  Nice! The space is pretty ripe for disruption because basically all of the tools are pretty old-school. Here are the things I really wanted: 1. Create dynamic schemas. Some of our clients had their own dimensions that they cared about. 2. Pick the level of integration. Imagine having an out-of-the-box integration available, but then offering fully customizable solutions for one-off scenarios. Really it comes down to those two things, which basically means "flexibility". Like I said, we spent months evaluating products, and while we found several companies claim to offer the above, no one actually did.
  - tenaciousDaniel 5y ago
    One thing I did not like about CubeJS (not sure if they've changed this), is that their integration is its own standalone server. Like, if you have an existing server, it didn't seem possible to just integrate it into what you already have. That was kind of a bummer, but it wasn't a deal breaker.
    - igorlukanin 5y ago

ushakov 5y ago

how does it compare to Hasura?

peiback 5y ago
In essence, you may want Hasura/GraphQL if you have no idea how the end-users' query format will look, whereas Cube is well-suited for providing performant results for somewhat predictable sets of queries. Disclaimer: I work on Cube. My colleague Igor explains it better: Hasura is for CRUD with reasonable performance, Cube is for fetching analytical (quantitative) data with sub-second latency and high concurrency. Hasura is great as a general-purpose data backend, Cube is great as an API for analytics. Obviously, they can be used in the same app, e.g., a blog can serve posts and comments from Hasura and show an upvotes/downvotes chart or a rating of most productive commenters via Cube. And here are a few user stories: https://cube.dev/blog/category/user-stories/ https://cube.dev/blog/category/user-stories/