The other day we had a customer request support for a view that used to work fine, but now was not loading. It turned out to be a connectivity issue.
Basedash keeps track of the schemas and tables within a database that you connect. The current implementation of this functionality is basic but viable for the majority of situations. We hope to make things more sophisticated down the road, but here’s how it currently works:
The Basedash user interface only presents schemas and tables which are “found”. So, if you delete or rename a schema or table in your database, it will no longer be present in the Basedash user interface, say by browsing in the sidebar of the “Data” tab. Likewise, a table which is “not found” won’t be an option to use as the basis of a view.
This implementation has been working adequately. If you delete or rename a schema or table in your database itself, it remains known to Basedash but is simply marked as “not found” under the hood.
There are cases which are not handled so gracefully at the moment, such as, for an existing view, if the table that it is based on is renamed or deleted in your database itself, the view will be unable to load. (Under the hood, the view points to a table known to Basedash but marked as “not found”). We have plans to improve error messages when a view fails to load, and this is one case where an improved error message would go a long way, something along the lines of “This view is based on a table which is not found in the database X”.
This customer turned out to have a view where the base table had been renamed in their database. The view failed to load.
As we often do in customer support cases, we use Basedash ourselves to help get to the bottom of things. With a bit of browsing, we can pull up the faulty view in question, find the user database, schema, and table it is based on, and take a look. Sure enough, that particular table was marked “not found”. We helped this customer to create the view anew with the desired table (the one with the new name) and the case was resolved.
Down the road we plan to more gracefully handle this edge case of table renaming, but being a startup and having to make hard choices about what to prioritize, at the moment we have this gap in functionality.
This support case underscored the importance of being able to quickly pull up user schemas and tables and see at a glance their “found” or “not found” status. So, as we often do, we created a view in Basedash—in this case an SQL view, which takes a user database ID, and reports on the schemas and tables within and their connection status.
Note the “id = 3” line. To use this SQL view, we replace that with the ID of the user database in question. Down the road we intend to support dynamic parameters to SQL views, so for example, a non-admin could make use of this view by setting an input in a field of the UI and seeing the results accordingly.
And here’s a related SQL view, for viewing the tables within a given schema and seeing their “found” status. Likewise note the line where we specify the ID of the schema in question.
It can be extremely liberating to be able to take the power and expressiveness of custom SQL and create an internal tool to help you and your team get a picture of whats going on with your application, with your customers, and with issues that come up. We believe that the best products are ones that you make because you yourself find them useful. This is a nice case in point, a situation known as “dogfooding”, which we’ve written more about here: https://www.basedash.com/blog/dogfooding-using-basedash-to-build-basedash
An index is a data structure you can add to your SQL database that allows for quick retrieval of certain information. For example, if you have a database of names and phone numbers, an index might be created on the name column so that the database could quickly be searched for a particular student's phone number. You can think of this in the same way that a physical phone book works.
If you're working on a startup, chances are you've got a lot of internal tools that you've built or are in the process of building. And if you're like most startups, those tools are probably a hot mess. What tools will startups use in the next few years? We have a prediction on trends, tech, and emerging ideas in the space.
Refactoring our tables to be virutalized was a huge undertaking, with a huge upside. It sped up table performance by 500% and allowed Basedash to load tables that had previously caused the app to crash.
Internal tooling can be a quick solution to satisfy requirements for colleagues that lack the technical knowledge to build their own custom software. Let's look at how we can beyond simply viewing admin panels, audit logs, and simple CRUD operations -- and into the world of building for the end users that work alongside us each day.
There are many different types of internal tools that you can build. You might want to create a reporting tool for your marketing team, or maybe you need a way to quickly get customer data visible for your customer support team. Or, any number of business apps to help your colleagues manipulate data.
Inheritance is a design pattern commonly used in object-oriented programming which allows you to model entities that inherit certain properties or functions from a parent class. This can be incredibly useful for modeling entities which have multiple types, such as different types of activities to show in a feed.
You've built a solid DB, but your colleagues need to edit data without knowing SQL. Here's how to enabler them to make edits:
How we wrote our own utility with Typescript to take the Date primitive and transform it into a string for use inside of Basedash.
A breakdown of the process of how the engineers at Basedash added the feature to allow workspaces to restrict signups based off of user email address.
Using our own product to query our databases speeds up our development time and gives us more opportunities to spot new ideas for features and improve our user's experience.
We recently added an easter egg to Basedash which shows ASCII art of our logo in the browser console. Here's how we we able to style our console.log message with CSS.
At Basedash we use Basedash itself for managing, adding, and removing feature flags for our product. These help use beta test new features, catch bugs, and get feedback before shipping new features.
I had the opportunity to chat with Liau Jian Jie, CTO & co-founder of Mobbin and talk about their migration from Firebase to SQL on Supabase earlier this year. Mobbin is a tool for designers to see and track UI flows from mobile applications to help with real-world inspiration for their own design work. I used it personally...
There aren’t many designers out there who would advocate for working with less or no information about the product they’re building. We want to know who is using our product, what their motivations are, what kind of frustrations they might have, what work environment are they in, and what other tools...
Recently, we refactored our codebase at Basedash to fetch our server data with React Query and optimize our REST API calls in the process. The transition to React Query allowed for better code readability and the optimization of our API calls resulted in half the number of data fetching API calls...
Startups can use whatever tools they want to do their job. We're not burdened by legacy contracts, enterprise-wide procurements, existing monolithic workflows, or the burden of training hundreds or thousands of staff for a new tool. We can change workflows on a dime. We can try something new...
See how removing barriers can change the way your team works.
No credit card required