Building Dynamic MongoDB Dashboards Using SlamData’s Chained and Nested Cards
I think probably one of the most useful is the fact that you can do what we call nesting of decks inside of other decks. The reason I say it’s the most useful is because if you remember in version 2.5 and earlier, our approach to this was using a notebook which is a fairly two dimensional way of approaching analytics workflow. You had one cell, followed by another cell and they would build on top of each other physically and literally in the screen, and what would happen is, to interact with users, you would have these markdown cells where you could select something and that could impact the next query based on what they select. And that’s great and we still allow that in our workspaces version as well here in version 3 but there’s two key things now that enable much better workflow and user interaction here.
That is, one, markdown cards can now be nested or chained together so selecting something from the first markdown card can affect the second markdown card. As an example you’d select a state in the first one and then you’d select a city from that state in the second one. Previously you couldn’t do that because we didn’t have the coding inside the [inaudible 01:09] so we had that. The second thing is now that we can nest these, what we’ll call a deck of cards, and I’ll get to that in a minute, inside of another deck, you can actually combine two markdown cards or two markdown decks next to each other, below each other, however, and it’ll appear as one interface so really what you’re building here [inaudible 01:30] has an application builder in that sense. It allows you to interact with the data, it allows you to get very technical with it, view the results, chart it, all that kind of stuff. That’s what I’m going to do with the demo today.
Are you going to show us a quick chained markdown?
Yeah, I sure will. In fact let me go into my workspaces here and what I’ve got is a number of different examples obviously but let me go into chained markdown here and what you’ll see is three separate decks. The first deck has a query and in fact let me zoom out a little bit so it can be seen and I’ll move these around so we can actually see the code in most of these. Here’s my original markdown source. I have the header which is just three pound signs and then something else, and that’s just standard markdown. I create a variable called state and inside of that state I populate that, or excuse me inside of that variable, I populate it with the results of this query. This basically says select all the distinct states from this collection and order it in descending order. You’ll notice we assign the variable name here. Then once I’ve typed that in, I would type run query and then I would slide over… I created a show markdown card and you can see here now that we have all the different states.
From there what I did is, I flipped the deck and then I did a mirror deck and what happened is it came up with a new deck and I’ll show you this one. You can see it looks just like the first one so if I change this one in here you’ll see that it updates over here as well. So they’re changed or synchronized or mirrored up to this point. Now this new deck I added another markdown so what I’ve done is I’ll slide over now to show you the actual code. This one’s a little bit different, I defined city and now I’m selecting all the distinct cities from that same collection, but now I’m saying or the state field is equal to colon state and then the colon of course is the preface key used, the preface you use for variable. Now when I click run query on this one, now the drop down shows you just the cities inside of Georgia or whatever state you’re looking in.
This collection has a very small data set, probably about 10,000 I think. If we go and we look at Boulder for example, you’ll see this third deck update here in just a second. Let me slide these back a little bit to make them smaller and you’ll see why I’m doing this. I’ve got these three separate decks and you’ll notice they’re inside of this kind of white border here. This is also a deck, or a card, excuse me, and that is inside of another one. The reason I’ve done this is so that when you put these all next to each other inside of a draft board card, it makes it appear as if it’s all one application. You can see these are all separate decks, you know in the workspace area here, you can see the lines delineating the response. Now if I flip the deck and I go to Publish you can see that you can do a preview. Now you go back to it in Publish mode, it looks like just one application so you don’t see the [inaudible 04:34], you can’t move things around, you can’t see the code behind it, or anything like that.
This literally is like a miniature application builder.
Yeah so you would then share that around your company or stick that, embed that in application and that’s exactly what you would see.
Yeah exactly and I should change what I said. I said it was kind of like a mini application builder, no, it truly is an application builder, it’s just focused at analytics at this point so. Yeah you can have all sorts of interaction, you can embed this, you can secure it and lock it down. All sorts of things like you said.
Every time you select a different city, is that going to MongoDB and pulling the freshest data? Is that like initiating a fundamentally new query each time?
That’s exactly right Chris. Everything we do in SendData is on live data. If you look at the original deck, I’ll look at this workspace, and you’ll see that I mirrored this, the second deck, I mirrored it into a new one. All I did basically was take the results from a query, so I wrote this query, I selected all the count and the gender type from that collection where state is equal to the variable, city is equal to that variable, and then I grouped it by gender. Then I created a set-up chart card. We have a number of different options here for this. We actually have quite a few other charts available but the data set that is presented from the previous card isn’t applicable to a lot of chart types so only half a dozen show up here. I selected the gender, at this point we don’t have a third option for series so we just leave that blank then we go to Show Chart Card.
If I choose Denver instead of Boulder, you’ll see that… It should update here in one second. Again this is fetching over AWS and… just like all of our charts, you can interact with it in the legend. You can even take certain data sets out. Yeah.
Does that morph into the nested decks or is that a uniquely separate feature?
You can use what we just did, which is the chain markdown, and I kind of showed you all in one. The chain markdown allows you to have one cell impact another cell if they’re both markdown. The other option was to, and I’ll show you what this looks like from scratch, was to merge those windows into one window. As an example, and this can be with any of the different decks, I’ll create a query card. I’ll just do something like select from AWS Data Patients, then I will run that query. I’ll go and I’ll do a Show Table and this is just standard Slam Data type of stuff we’re doing. I’m going to flip the deck, I’m going to wrap it. Now this is the first step. You want to wrap it so you get this big draftboard in the background. Now you’ll see we have this deck.
If I were to Publish this deck just like it is, you would see just this window. In fact, if I flip the deck, we go to Publish, and we’ll preview it, you’ll see that window and it looks just like it did in the other spot except the handles are gone on the left, right, and top. You can’t move it or resize it. Now if I go in, flip this back in, and create a new deck down here, let’s just say it’s a completely different query table. Select Star From Olympics, and we’ll put this right next to the other one, zoom out a little bit so it makes more sense for anyone watching. I run the query, when I put it in a Show Table, and so now you can see we’ve got two separate decks. They’re not even dependent on each other, showing. Now if we look at it in Publish mode, you’ll see that we have two separate decks so it looks like exactly like I created it in two separate decks.
If you wanted to have maybe a selector up here, a chart here, a row of tables over here, then you wouldn’t necessarily want it to be in separate things like this, right? You may want to have a title against the top of this query down here that sets something about that data set. Well to do that, that’s when you use the draftboard card. Now we’re back to this deck in edit mode, I’ll go over here, create a new deck by clicking, and now I do a Set Up draftboard. What that does is basically create a draftboard inside of a draftboard. To move this stuff around, I’m going to make these smaller just so it’s easier to move them around, I’ll resize this guy so they can all be pulled in. I accidentally created a new deck inside of there by doing such. Now I’m going to grab both of these tables and slide them into here. You still have all the freedom that you had before in terms of jumping between the cards inside of the deck and resizing. I’ll put this right next to the other one. Finally I’m going to slide this guy up into the left.
Now, because they’re inside of a draftboard card, now if I Publish this, now they actually are kind of merged to look like one inside of an application. They both have their own controls at the bottom of their screen but it looks like one screen to the user, so yeah. There you go. It’s very slick, it definitely merges and combines and makes this nice cohesive type of application out of multiple windows. It really is an application builder for analytics.
Yeah literally you can build out an entire dashboard and have that be a page or header, goes at the top of your footer, and everything else in between is constructed in this draftboard.
You’re exactly right and that published dashboard could have controls in it too where somebody selects the parameters for it so, yeah, it works really well.
Latest posts by Chris Dima (see all)
- SlamData Secures $6.7MM Series A to Support Modern Data in the Enterprise - February 22, 2017
- SlamData 4.1 Includes New Charts, Updated Connectors for Couchbase, MarkLogic and Spark/Hadoop - January 26, 2017
- SlamData Makes the List: 2017 DBTA Trend-Setting Products - December 14, 2016
Native Analytics On MongoDb, Couchbase, MarkLogic and Hadoop.
No mapping. No ETL.
Recent News & Blogs
Boulder, Colo., February 23, 2017 – SlamData Inc., the leading open source analytics company for modern unstructured data today announced that it has raised a $6.7M Series A funding round, led by Shasta Ventures. The investment will drive further development of the firm’s breakthrough analytics solution: a single application for natively exploring, visualizing and embedding analytics against unstructured data sources including NoSQL, Hadoop, and cloud API’s.read more
SlamData just released its first update of 2017, SlamData 4.1.1. It delivers a number of new UI enhancements, performance improvements, new charts, as well as commercial releases for the Couchbase, MarkLogic and Spark/Hadoop connectors.read more
Welcome to the SlamData getting started video. Let’s jump right in. By default, SlamData runs on port 20223. You can change the port it runs on by modifying the quasar-config.json file. By default, this file is located in the following directories on Windows, Mac and Linux.read more
To help shed light on where customers can go to address their data-driven challenges, Database Trends and Applications magazine assembles an annual list of solutions…read more
The following is an interview I conducted with Jeff Carr, CEO and Founder of SlamData regarding the trends in enterprise business intelligence.read more
Enterprise Business Intelligence solutions are failing, and the reasons are very obvious. Leading analyst firms including Gartner and G2 have published rankings which show virtually no leadership and scant challengers in the market.read more
Who Is Using SlamData?
Whitepaper: The Characteristics of NoSQL Analytics Systems
by John De Goes, CTO and Co-Founder of SlamData
Semistructured data, called NoSQL data in this paper, is growing at an unprecedented rate. This growth is fueled, in part, by the proliferation of web and mobile applications, APIs, event-oriented data, sensor data, machine learning, and the Internet of Things, all of which are disproportionately powered by NoSQL technologies and data models.
This paper carves out a single concern, by focusing on the system-level capabilities required to derive maximum analytic value from a generalized model of NoSQL data. This approach leads to eight well-defined, objective characteristics, which collectively form a precise capabilities-based definition of a NoSQL analytics system.
These capabilities are inextricably motivated by use cases, but other considerations are explicitly ignored. They are ignored not because they are unimportant (quite the contrary), but because they are orthogonal to the raw capabilities a system must possess to be capable of deriving analytic value from NoSQL data.
Table of Contents
- The Nature of NoSQL Data
- NoSQL Databases
- Big Data
- A Generic Data Model for NoSQL
- Approaches to NoSQL Analytics
- Coding & ETL
- Real-Time Analytics
- Relational Model Virtualization
- First-Class NoSQL Analytics
- Characteristics of NoSQL Analytics Systems
- Generic Data Model
- Isomorphic Data Model
- Unified Schema/Data
- Polymorphic Queries
- Dynamic Type Discovery & Conversion
- Structural Patterns