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 :-)
Fair enough, I don't know anything about Delphi except its price tag. Given OPs request for a friendly UI to sit on top of cube I thought retool could fit well that use case. And thanks for sharing the guide, I use and love Cube but I didn't want to pass as a shill :)
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.
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.
That makes a lot of sense to me, and I see why it would be hard to coalesce all of that functionality into one or two sentences that would make sense to a more general, non-data, tech audience.
My understanding is that it's essentially Looker minus the dashboarding. What you would define via LookML is essentially the "semantic layer" that this is addressing. DBT is attempting to do similar work: https://www.getdbt.com/product/semantic-layer/
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 :-)
My understanding of Cube is that iterating on the data model requires the user to (1) write SQL to develop a metric (2) edit YAML or JS config to incorporate the new metric (3) issue API request to Cube server and (4) compare results to raw SQL. Am I mistaken? Does Cube offer a smoother way to do this exploration/iteration?
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.
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.)
Not just lack of OSI approval, they're attempting to redefine the long accepted meaning of open source to include their new licenses. They want the goodwill of being "open source" without the obligations. The only sorts of licenses that have consistently been considered open source are either copyleft licenses like the GPL and do whatever the hell you want licenses like MIT and Apache. Do whatever you want... unless you're a big corporation... or unless you're part of a group the authors deem evil/immoral/unethical... etc. is a massive departure from the spirit of the term open source.
As you say in that section, "Open source licenses usually grant users permission to use open source software for any purpose." These source-available licenses (SSPL/BSL) are not open source exactly because of that: they place restrictions on users from using the software for any purpose. For example in the case of SSPL, it includes purposefully draconian language in the license that basically means that it can't be used freely to provide a "service". These kinds of "poison pills" obviously stop you from using the software for certain purposes.
It is most likely in the "Additional Use Grant" which is tricky - because this additional use grant is distinct to each product licensed under the BSL. This additional use grant is also not that easy to find, since some licenses display it prominently, and others hide it under some additional legal fineprint[1,2].
A: The usage is limited to non-production use, or production use within the limits of the “Additional Use Grant” defined by the vendor using BSL and specific to each BSL product."
[2] it is extremely difficult to find the Additional Use Grant for Mariadb products themselves. For MaxScale, which is their proxy product, it is buried in a file within the source code (which on the surface level might be a good place for it, but it's not very easy to find and I had to go through lots of legal print to get to it) : https://github.com/mariadb-corporation/MaxScale/blob/2.5/LIC... or https://github.com/mariadb-corporation/MaxScale/blob/6.3/LIC... depending on which version you are trying to use, etc.
I wasn't referring to the BSL specifically with that comment, I was referring to recent attempts to call licenses like the Hippocratic License "open source" despite being anything but. The BSL is just a different example of a similar thing.
> they shouldn't be there because they're not OSI-approved, right
No, they shouldn't be there because they aren't open source; OSI approval has nothing to do with it. (Though it's still a good indicator, similar to how FDA approval doesn't change whether/how well a drug works/is safe.)
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!