Cube.js – Open-Source Analytics API for Building Data Apps | Hacker News Reader

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

github.com

93 pointschetangoti15 comments

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.

I am building a BI solution, with a different approach. What were you looking for in those solutions?

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.

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.

Long time ago, it was possible to built Cube into a Node.js app. However, the team decided to deprecate it: https://github.com/cube-js/cube.js/blob/master/DEPRECATION.m...

The motivation is diverse but one of the reasons is that a Cube app should be scaled differently from a client-facing app. Noone probably wants their app to hang when Cube serves a ton of requests or refreshes cached data (and vice versa). That’s why it’s recommended to run Cube as microservices. I hope it’s not a big deal since a lot of cloud platforms provide container environments.

Also, just recently, we’ve launched Cube Cloud which provides serverless experience for Cube apps and has a free tier: https://cube.dev/cloud/

Hey! Igor from the Cube team here. Coincidentally, in a few days, we’re having a workshop on multitenancy where we’ll cover dynamic schemas: https://cube.dev/events/multitenancy. We’ll show how to customize schemas using pure JavaScript.

Do you have recordings or transcripts of the workshops? Multitenancy is huge for us and I’d love to see what CubeJS is offering now but I can’t make the workshop

we will, yes! here's our last workshop's recording, for pre-aggregations: https://www.youtube.com/watch?v=1_BP3B_wbec

What do you mean by dynamic scheams ?

Have you evaluated PivotData Microservice (https://www.nrecosite.com/pivotdata_service.aspx) too? It supports dynamic schemas and beyond just API it comes with sample report builders (for end-users) and built-in pivot tables.

I came to the same conclusion around the same timeframe. All the current solutions are not great but CubeJS just didn’t have enough maturity yet. I decided to just hold off on making any changes for a year or two and reevaluate.

Hopefully they are still going strong in the spring/summer and then maybe we will go all in.

Cube.js fills a need I've heard many times in ClickHouse work--how to build a clean data delivery API that mediates application access to analytic databases. There's a basic impedenance mismatch between highly concurrent apps that may have 10s of thousands of users and backend data warehouses that run massivley parallel queries in order to get predictably fast response.

Just as a shameless plug, Pavel Tiunov is going to be talking about design decisions on Cube Store at OSA Con on November 2. [0] We feel this type of technology is fundamental to scaling analytic apps, which is why we picked Pavel's session for inclusion.

[0] https://altinity.com/osa-con-2021/

Disclaimer: I work at Altinity on ClickHouse.

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.

how does it compare to Hasura?

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/

Reply on news.ycombinator.com