Frontend as in "access layer" or "API"? Yes, kind of (more than that). Frontend as in "HTML/SVG/JavaScript in the browser"? Certainly not :)
Re: Salesforce. The best way to integrate two is to move (ETL) the data from Salesforce to a data warehouse and have Cube connect to that data warehouse. Works really well in the real world!
Here's the Retool guide (https://cube.dev/blog/building-an-internal-dashboard-with-re...) but I don't think Retool should be compared to Delphi; one is a low-code tool builder; the other one is a conversational interface for the semantic layer. Both are great for their purposes, both can be used with Cube, even at the same time :-)
I think ORMs have got some bad press because they were intended to be used bi-directionally: map data from the data source to business objects and back. With semantic layers, data is only mapped to metrics and rarely back - which makes things much simpler, IMO.
Hey, Carlin! Nice to see you here in comments! (Waving "hi" to the Malloy team.)
Usually, the experience would look like this: one directly develops the data model in YAML (with only bits of SQL, if needed) and instantly explores metrics. No need to start with SQL in a separate tool/place (1), no need to use the API to check metrics (2) (for that, we have Playground, an interactive UI tool), and, thus, no need to compare results to raw SQL (4). You iterate but changing the data model and seeing the metrics in an instant, quite similar to how you work with Malloy, if I may.
As part of the Cube team, I have to admit that all descriptions in the sibling comments make a lot of sense. Of course, the "semantic layer" thing is quite known to data engineers/analysts and other data folks in general (they also know things like "metrics store", "headless BI", etc.) but not that well known outside of the data space. Probably, it would be best to describe what are the major use cases Cube is created for.
1. Embedded analytics — you have your data somewhere (data warehouse, database, etc.) and you'd like to embed it into a data app. Cube would provide connectivity to data sources, data modeling to define the metrics, caching to make your analytics fast, and APIs and SDKs to deliver them to the data app. E.g., if you decided to add a chart to your front-end app, fetching the data from the API would be as easy as sending a JSON query to Cube.
2. Semantic layer for the internal BI — you have your data somewhere and you'd like to provide access to insights based on that data to business users. Cube would provide connectivity to data sources, data modeling to define the metrics, access control to make sure only ones who need access to metrics have it, caching to make sure every dashboard loads instantly, and APIs to deliver the data to BI tools, notebooks, etc. E.g., if you want to create some dashboards in Superset, Metabase, Tableau, or Power BI, you'd just need to connect Cube's SQL API as if it was a regular database and start creating charts/dashboards.
So good you brought Malloy here. I like it quite a bit because the folks really try to innovate (heck, they even have their own data querying syntax to replace SQL). But what I like even more — being part of the Cube team — that the "cons" of existing solutions that Carlin mentions in his blog are actually already solved by Cube.
With Cube, Data exploration, ideation on the data model, querying, and bringing the insights all the way down to BI tools or data apps takes minutes rather than hours or days. Done, case closed :-)
Oh, it's interesting to meet a Statsbot user in the wild! Indeed, Cube was spun off Statsbot and became the foundation on which others can build products like the one mentioned in the sibling comment: Delphi.
(Igor from the Cube team here.) Whoa! Great to see Cube here. Would love to take questions about all things Cube, use cases, our docs, developer experience, etc.
Author of the blog post in question here. Let me clarify: they shouldn't be there because they're not OSI-approved, right? Just wanna get your point here.
(While I understand that BSL/SSPL lack certain liberties, I deemed it okay to mark them as "open source" for the purposes of this post.)
I think someone from Oracle would be more informed on that matter. JK. On a more serious note, who would dare to displease a multibillion corp with hundreds of lawyers (without being backed by a similar co & lawyers)?
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.
Re: Salesforce. The best way to integrate two is to move (ETL) the data from Salesforce to a data warehouse and have Cube connect to that data warehouse. Works really well in the real world!