Improving Dolt's First Hour Experience
Introduction
Dolt is on its way to becoming a production grade version-controlled MySQL database. Most developers associate "production grade" software with performance, but to us, it includes user experience (UX). Our current UX challenge is getting Dolt to work perfectly within the first hour of use, enough time for developers to get to that first "wow experience" with diffs or merges.
You don't know what you don't know
When Dolt was originally a "Git For Data" CLI tool we really focused on making the CLI experience as flawless as possible with a substantial amount of BATs tests. When we put a SQL Engine on top of Dolt we augmented our correctness work with a wide variety of hand written engine tests and the Sqllogictests. As we became more of an OLTP database with server capabilities we wrote a significant amount of tests to ensure that MySQL Clients would work with Dolt.
As adoption has picked up we've started to see Dolt fail quickly in situations we just didn't really think about prioritizing before. Databases sit in a complex stack ranging from simple clients to complex data science tools. We've seen users churn because their tools are broken within the first hour of connecting them to Dolt. What we need to do is be proactive with a wide variety of tooling to at least get a better sense of what works and what doesn't work. In the next two months we are focused on improving UX for two main tools 1) Database Editors 2) ORMs.
The Work To Do
The first step in this is getting a large swath of Database editors to really work. These editors generate all sorts of wacky queries and hit more untested parts of the code base, particularly the information_schema. This is tough for us because we always wrote tests for human SQL not programmatic SQL. We want to get the following editors completely functional for every single feature they offer. And if a feature is really far off, then we can at least document it.
This type of work will compound greatly and will ensure Dolt's robustness for years to come.
The second step is testing Dolt against more ORMs. ORMs are pieces of software that allow users to model their databases in terms of code. They support a wide range of modeling behavior and have neat features like eager loading that make join queries easy. Pretty much all web applications developers interact with databases via an ORM.
We've done some of this work before with Django and it was immensely valuable for improving our product. ORMs have pushed us to think harder about the full life-cycle of the product from initialization to migration to deployment.
We think the following ORMs are really worth investing in. Our goal is make sure there core feature sets successfully execute against Dolt with a ton of tests.
Conclusion
It's easy to get lost in the beautiful Computer Science that exists in the development of a database, but we are more interested in building a world-class product. We will make sure that users have a sublime experience working with Dolt.