Creating Powerful Low-Code Data Dashboards with Superblocks
Build and deploy a low-code data reporting web app using SuperBlocks and MongoDB in minutes.
Superblocks is a powerful new way to create Data Dashboards and custom data solutions.
TLDR: Superblocks allows the creation of next generation data apps — characterized by low code, easy deployments, fine grained access control, and full integrations with Prod environments. Also, I built this app using Superblocks and had a really great experience.
Building data reporting dashboards using BI tools such as Looker or Tableau are great low-code solutions for answering business questions. However, if you need something more customized, more integrated, or high-performance (e.g. ML dashboards), these solutions fall short.
In cases where customization is necessary, most data teams resolve to customized web-app based applications, like Streamlit or Plotly Dash Apps. However, these tools have gaps too — deployment can be challenging, access control (RBAC) and data governance mandates are difficult, plus they take a long time to build.
The only solution which checks all the boxes is a custom web app, which probably falls into the categorization of web development, less so data dashboarding.
Thus, the solutions available to current data dashboarding teams are limited and fall short. Until now. [Drumroll] In this article, I will discuss Superblocks, a new low-code data dashboarding technology which is quickly changing the data dashboarding landscape. [Clever voice] At the end of this article, you’ll like Superblocks a lot, I hope.
Before diving into what Superblocks does, let’s take a step back and describe the types of tooling available to data dashboarding teams.
Generally, live data reporting is done with one of the following tools:
- Business Intelligence (non-programmers):
Ex: Tableau, Looker, Google Data Studio
- Next-Generation Dashboards (programmers):
Ex: Streamlit, Plotly, Bokeh
- Fully-Customized Web Apps (programmers++):
Ex: Microservice deployed on Heroku.
2.1 Dashboard Characterization:
- Interactive: Reports change based on user interaction
- Real-time: Data is refreshed automatically and consistently
- Stateful: Dashboard can “remember” where you left off
- Read only access: Performs
SELECTqueries on a DB.
- Siloed from software release processes: Dashboards almost never go through rigorous testing and automated QA found in software release processes. This decoupling allows for more agile creation and utilization of dashboards, at the expense of frangible business logic.
- Siloed from production environment: Things are contained within the dashboard’s ecosystem. These dashboards rarely have access to Production API endpoints (precluding analytical endpoints).
Any functionality needed not already provided by available dashboarding solutions (ex: multi-page excel export in Tableau, user-password authentication in Streamlit) must be built by a developer, resulting in dramatically fractured development processes (since these tools are siloed from software release process). This results in extraordinarily sophisticated duct-tape programming — an unreasonable practice — and the accumulation of technical debt in a domain often not governed by technical review.
Note: Customized Web Apps do not follow the above.
2.2 Next Generation Dashboard Characterization:
- Examples: Streamlit and Plotly Dash both fall into this category.
- Designed for programmers: which represent but a subset of data practitioners
- Deployment anti-patterns
- Limitations with RBAC
- Challenges with maintaining statefulness: Ex: add a new column to a table
These tools work well in limited use cases, but once access to databases, authenticated credentials, or RBAC is required, they become as challenging as regular web development.
☝️ Has been my experience, if you have had a diff experience, gimme a holler in the comments section.
2.3 Fully Customized Web App Characterization:
- This is a web app and requires web development.
- Requires advanced expertise in domains not related to data per se.
- Slow development process (compared to other options)
💡 Time to create and deploy such applications ranged from 40–60 hours.
2.4 Gap in available tooling:
- Security / RBAC: Centrally controlled, enforced on the web app level
- Customized Statefulness: Building a DB facing backend is too difficult
- Fully Managed Deployment: Efficiency of existing BI tooling, without the deployment headaches
- Low-Code Tooling: Imagine a BI tool, but with the ability to customize interactions, pipelines, and procedures with code. (The big BI players are making progress to this aim, but they have not quite solved it yet.)
- Procedural Release Process: Ability to create in development environments + create automated tests before releasing
- Interaction with Production Ecosystem: Ability (and trust) to interact with Production environment API’s and Databases.
3. MEET SUPERBLOCKS
It may sound too good to be true, but Superblocks solves all points raised in the previous section.
I will demonstrate by sharing how I built the following data app:
3.1 What I wanted to build:
A dynamic user directory for Artists Who Code (a community of professional artists who’ve transitioned into tech) where people can add their names and key information about themselves, such as their arts background and what they are doing in tech now. I also wanted the ability to search for specific users and perform reporting on the entire population.
3.2 Technical requirements:
- A form where people can add their information
- Multi-select dropdown elements whose options are determined by a database
- Ability for a user to modify options in above dropdown elements
- Search capabilities
- Analytical capabilities — visualize based on custom filters
3.3 How I built it
Superblocks has 18 pre-built components which you can click and drag in their GUI, which I used to build all of the above. Additionally, Superblocks allows you to program your own react components and include in their service/interface.
3.3.1 Create a user facing form:
- Form: acts more like organized container
- Input: Text input to capture Name, LinedIn url, and email.
- Multi-select Dropdown: values are fetched from a mongoDB collection. User can choose as many options as they’d like.
- Checkboxes: for boolean values
- Image Url: Text input to capture image, plus an image preview to show the user what they selected. (Easier than building a service to store the image somewhere.)
- Buttons: To submit the form, or reset the input values.
3.3.2 Restrict options in multi-select:
- I wanted to restrict the options for
- Presently, all users can alter these options, but eventually, I could restrict access to only elevated roles.
- Values from these multi-select dropdowns are stored in their own mongoDB collections (good short term solution).
- A user can add values by clicking a “add thingy” button, which opens a Slideout element (fancy popup type), in which I built an additional form for specifically this.
- On slideout-form submit, new option is added to the DB (this is elaborated below), then any references to this option is refreshed.
I will comment that the above was a bit tedious to do — but no more tedious than any other dev work. (But a lot more tedious than Google Forms.)
3.3.3 Add a new user to my DB on form submit:
On form submit I execute the following API flow:
- Python function to dynamically create the document (I want to explicitly remove
nullvalues from my documents)
- MongoDB operation to
insertOnedocument to my
3.3.4 View Directory:
I wanted a nice way to get a glimpse of each person in the “database.” Superblocks offers a Grid component which does all of this for me.
I also created a “table format” provided to me by the Table component. I was delighted to see that this component has built in filtering, sorting, and search.
3.3.5 On Click, Open an Individual’s Profile:
The grid component allows an “api call” when a cell is focused (or clicked). I created a new Slideout and populated information based on the currently focused cell.
Note: In the future, I can add super customized behavior to this view — such as “send this person an email.”
I chose not to do this for the table view too, only because this is a POC.
3.3.6 Visualize Users (Data Dashboard Component)
Superblocks’ Chart component is best in class. You can either configure your data visualization through their UI, or provide Plotly Dash config json! This is truly the best of both worlds for data visualization designers.
I built filters for this visualization using Multi-select Dropdowns (the same components I used earlier).
When any filter changes, I execute the following API flow:
- Query MongoDB for any documents which match the filter criteria
- Transform this data to “tall form” which can be appropriately graphed
It is not best practice to make a round trip to the database on each change. I’m realizing now, I could probably add the filtering logic to my
aggregate python function (or create a new function) which would be downstream and separate from the original
get_data_from_db operation. My data is currently tiny, so this isn’t too much of a concern. But it could be a breaking point in larger data apps.
Wow this was easy.
3.5 Managing Credentials
This was super easy too. (I’m showing you demo creds fyi…)
3.6 Managing Access (RBAC)
This ⬆ is a simple implementation of RBAC. More advanced methods are available (documentation). I could do a whole article just on RBAC (it is extremely important for building sensitive data applications), but let’s just agree that Superblocks meets both the basic and advanced requirements here.
💡 Especially important for enterprise clients, Superblocks supports SSO + user groups.
⚠️ Superblocks’ access control is super impressive and is total game changer for building sensitive data applications.
3.7 Interaction with Production Environment
As shown above, credentials are centrally managed. Granular controls can be applied per credential, per application, per user. (Relief for all InfoSec people.) This means, data apps’ access to Production API’s or databases can be centrally managed.
This can negate or alleviate apprehension for Production-environment access by data apps. It also opens the door for DB write access by data apps, which is truly revolutionary.
⚠️ I mentioned this above, but will mention again. The central management of credentials is crucial for the green-light of data application access to Prod environments by InfoSec teams.
3.8 Automated Testing
Some testing for automated workflows is supported, though I haven’t used these in my POC. I imagine these operate more like data pipelines, testing can ensure your pipeline functions end-to-end.
From an SRE standpoint, there isn’t a ton of support yet — aside from human QA people playing around. I imagine you could build your own Selenium driver to review UI elements + overall functionality. Otherwise, automated testing, which remains an unsolved problem in the data dashboarding space, remains unsolved here too.
Perhaps this gap in automated testing is demonstrative of data leaders wanting to avoid being slowed down by testing? Is automated testing of dashboards valuable? I’d like to think so…
3.8.1 Preview + Rollback
The creators of Superblocks have super strong engineering backgrounds, so I am not surprised to see a
preview/rollback feature, which allows you to restore the state of an application. This is a really powerful feature!
I’d like to see more of this in all data dashboarding tools.
3.9 Customizable Branding
I didn’t get to test this in my POC, but I believe this is possible to do, though the feature may be in beta?
Building this application (and learning how to work with each component) took me maybe 3 hours total. For comparison, it would take me between 40 and 70 hours to build a similar custom web app. That’s a lot of time saved! 🎉
Okay, so maybe I lied a little in the Article’s subtitle… Though technically, any unit of time can be measured in minutes.
4.1 Goodbye Heroku, Hello SuperBlocks
I don’t think I’ll be building custom web apps without Superblocks again:
- Exeunt: Plotly + Flask + Heroku + Postgres (for state)
- Enter: Superblocks + MongoDB (for state)
4.2 Opening the Door to Production for Data Apps
After building an application with Superblocks, I get the impression that its creators are intimately familiar with how and why data applications tend to get siloed from Production environments. I am deeply impressed with the level of security, control, and granularity they’ve taken into consideration to provide. Functionality like this will shift the paradigm of siloed data apps and pave the way for more integrated builds.
4.3 Data Dashboarding is Entering a New Phase
If there’s one thing you take away from this article (aside from Superblocks being a dang cool tool), it’s that the next generation of data apps will be more integrated in Prod environments.
💡 Superblocks’s headway in providing advanced security features and granular access control sets a new precedent for data apps + data dashboards.
4.4 Data is Beautiful
I’m always enthused when a tool allows me to share stories told with data in a new way. The app I’ve built throughout this article tells a simple story — but it is a beautiful one nonetheless. Thank you Superblocks for this beautiful experience.
🧠 I’d love to see what data apps + data stories you’re building → share them in the comments!
4.5 In Case You Forgot
Here’s the link to view the application I built: https://app.superblocks.com/applications/9e80434c-64a6-480f-bac3-0093f0139dbf/pages/ecb00eea-214d-4877-8c62-f88f999b5f94
5. PRODUCT FEEDBACK
For a newly released tool, Superblocks is outstanding. Plus their logo of a koala is really cute.
As the product gets more mature, I would want the following:
- Custom URL / endpoint (like Github pages)
- Better support for automated testing (unprecedented tbh)
- Better support for more advanced MongoDB functionality (ex:
- More “built-in” logic for user-input elements. (enforce constraints on input, kinda like google forms)
- Fully-managed Mongo DB as a service to manage “state.” It was really easy for me to create a DB and several collections for this POC. But I imagine what I created will be more generic, so maybe offer that as a service. (Heroku + Postgres model)
- Fully managed dropdown menus (limit my options to
some database.collection/tableand Superblocks builds the ability to add more values, edit existing ones etc). This is probably only doable in No-SQL db’s. who knows, this one is more of a dream shot.
- [New Component] DataTable or “Cache.” I would love the ability to have data “in memory” which I can apply dynamic filters. I’m realizing that I could probs just have this as a single “API” which then other “API’s” are downstream and consume from. Welp! Maybe more explicit documentation on this?