We’re a middle ground between Airplane and Retool—simpler UI creation than Airplane, more code-centered than Retool. UI building is declarative and you can bind Python scripts/functions to UI components. You can write Python scripts/functions using our App Studio with support from a Python Language Server Protocol (LSP) for linting. Since the self-hosted worker directly references .py or .sql files in the filesystem, you can even write them on VSCode directly or import any other Python script or library.
Our app layout is highly opinionated to speed up app building. Instead of an open canvas for UI building, we just give you a main table view and a widget sidebar. This approach significantly reduces app-building time while still covering what most tools need: see some data and take actions based on it. It’s not flexible enough to do absolutely anything, but that’s the point—there’s a tradeoff between flexibility and speed. Dropbase gives you most of what you need, plus speed!
A neat feature we are experimenting with to build admin panels fast is “Smart Tables”. We convert any SQL SELECT statement (even across multiple joins and filters) into an inline editable table, like spreadsheets, without any additional code.
We have a hybrid hosting model that combines a self-hosted client and a worker server, with a backend API for app/component definitions hosted by us to simplify pushing feature updates. The worker server sits in your machines so your sensitive data doesn’t leave your infra.
We’re Python-centric for now, but plan to add support for Rust, Go, and others later.
We made a few demo videos building common tools: - Customer approval tool: https://youtu.be/A1MIIRNkv3Q - Data editing tool (with Smart Table): https://youtu.be/R1cHO9lMRXo
To try Dropbase, create an account at https://app.dropbase.io and generate a token, then follow these instructions for local setup: https://docs.dropbase.io/setup/developer.
We are very early so we're really excited to get your feedback, especially on our approach to tools building with Python! My co-founder Ayazhan and some of our teammates will be around to answer questions.
For example, one of the limitations is that we have a highly opinionated app layout, with a data (table view) on the left, and a sidebar on the right to perform actions. Only a small fraction of all external apps have this layout (e.g. database lookup tools, CRMs, data editing tools) but on the other hand, almost all internal apps look this way.
Nothing wrong with commercial offerings, but the trend of posting a GitHub URL to fool people into an open source first impression when there’s nothing in the “repo” really irks me.
It's used specifically for making simple UIs for machine learning apps. But I guess technically you could use it for anything.
> I'm one of the engineers behind Dropbase.
So I hope this isn't the first time you've seen this.
The comment you are referring to is most likely from a really old post. He was an intern at Dropbase a few years ago, back when we were working on a very different product!
At my company we have recently started using NiceGUI which is a python wrapper for quasars+tailwind and seems like a very similar product. I’ve found it has a great level of abstraction that enables you to do Python only web App development without too much magic, but also lets you sprinkle in some CSS and javascript if needed.
I also think there's a good number of people who have basic Python skills coming from data analytics and data science backgrounds, who might not be doing hardcore ML research but who nonetheless want to build simple web apps. One of our hypotheses is that our product would be a good fit for them.
what kind of apps are you building with it?
Some examples:
- Another non-technical team needs to know if our test covers specific genetic variants. The code to answer this is 10 lines of Python + a 100 line CSV. We can solve this with a CLI on our local computers but to serve it to the other team was a huge blocker until we started using NiceGUI. Now its 10 lines of Python + 10 more lines of NiceGUI Python and they have a website to go to so they can self-serve the answer to that question. All done in a 2-4 hours.
- More complicated, we have a workflow where we want to select data from a database via a series of filters, run some automated algorithms on it to generate new data, denormalize and view the data, manipulate it using an Excel-like interface, and then update the database with the edits that were made. NiceGUI + their AG Grid integration let me build an application that has all the great GUI features of Excel when it comes to grid-based data manipulation but is fully programmable with 99% Python (and like 1% JavaScript).
- I also built a data hub that integrates and displays data from a bunch of our different data sources and displays it based on some queries. If I can write a tool in Python to do something, I can now easily deploy an internal app that does that too, without knowing any front-end code. It even has the flexibility that when needed I could dive into a bit of HTML with the help of ChatGPT to embed iframes of PDF files getting served directly from S3 links.
The great thing is that this is all done in Python, all version controlled in the same repo as the rest of our codebase, uses open source software, and can be deployed easily within our VPC using terraform+docker. So it's a very maintainable dev ops experience compared to most other no-code/low-code tools, while at the same time enabling people who have programming (but not really engineering) experience and are subject matter experts in other areas to build fairly complex and customized GUIs.
It's also using FastAPI under the hood so you can implement some things at that layer as well. I know that's how they suggest implementing Auth, but I haven't dabbled with that as well.
internal app builder is certainly a challenging market to break into, but we believe we have something interesting to offer and are quite optimistic about our approach.
were you a customer of the previous dropbase version (csv to database)?
thanks again for your interest, it is always appreciated!
I pivoted in the reverse direction from:
https://github.com/pycob/pyvibe
To
I looked at alternatives like tkinter and it was the most compelling
I've written some stuff in Python but it seems like keeping up with Python and its near-infinite PEPs is half the job. They still can't get on the same page about how to package and share things on PyPI, or which tooling a developer should use to test integration or build packages, etc. I'm somewhat realizing what I enjoy about Python is more its dynamism and lack of verbose syntax. Or, cool stuff like list comprehensions and decorators.
The community is insufferable. I wish I could find a programming language that was high level, effective, but boring in the sense that it isn't being changed every other year. Something that I can build on for five years or more.
It's a strange thought but I've heard of people using PHP, of all things, to write general purpose CLI programs and whatnot. It had never occurred to me to try that even though I knew it was possible. It just felt... dirty.
Licensee is expressly forbidden from:
(a) Incorporating, modifying, or using the Software as part of any other product or service; ```
We actually started with just releasing the Worker for self-hosting. Then based on feedback from one of our friends and early users, we decided to also distribute the client for self-hosting due to security concerns. Maybe in the future if we also allow self-hosting our backend API it could make sense to distribute Dropbase differently!
Oh yeah, maps are also super important, and being able to overlay different statistics and or graphics over them.
I would give better feedback but still no easy way to see the code? Unless you're trying to do it like this to have something like a closed-source version of your libraries... which would again be kind of a bizarre model to use with Python.
> a backend API for app/component definitions hosted by us to simplify pushing feature updates
Any plans to open-source that part as well?
as we grow and learn, if we get interest from the community to contribute, we'll definitely consider opening more of the codebase.
Thank you!
Also, why using this vs creating a desktop app? (There are ways to create GUI desktop apps in Python)
the goal of internal apps is to optimize tasks that are tedious and time consuming, but not too common for an off-the-shelf product to be available.
since the internal apps aren't the main product developers work on in a company, they prefer to build them quickly with minimal resources.
internal tools usually run on a server, as does Dropbase
I've built multiple internal tools like those in the example section, and even with a solid framework like react-admin, one of the first requests you're going to get from internal stakeholders is tweaks to the UI.
It's a myth that internal users aren't as demanding as external stakeholders. If anything, they can be more pushy.
I would not want to launch an internal tool, except as an engineering-only POC, unless customizing the frontend were at least as easy as customizing the backend.
what would be the minimum set of customization required to satisfy the majority of the tweaks requested by internal users?
would it be sufficient to offer themes (dark/light modes), a custom logo, and control over font sizes? or, is it more fundamental, like adding your own css and changing the size/positioning of components?
I know you're a Chief Technology Officer not a Chief Product Officer or Chief Sales Officer, but if you're not already getting an earful from prospects or clients about wishlist items on the frontend, gird your loins, because it's coming.
Do you consider your customer path someone coming from e.g. Airtable and converting? Or are you looking to find someone who would be choosing Django for their next project?
(This looks like something I would use Django for, although the additional building blocks are nice sugar on top too)
I would have tried out your approach if it was out back then, I am much more well-versed in Python than JS. Having some way to write code in files, and then link it to the table structure makes a lot of sense (having lots of spaghetti code all over the place was one of the core issues of Retool, also it became slooooow at some point). Simplifying to a table + sidebar view is a very good idea (that's all we ever did).
There are unique challenges in making a decent looking chat app. State management is one such. Streamlit’s approach is to rerun the script on every action, which means your code needs to be aware of this, and this usually results in headaches and spaghetti code. Chainlit has a clean approach — I don’t know what they do under the hood but at least from a dev POV it’s far simpler.
I’d be interested to see how a basic chat app is built with Dropbase so I can compare.
Lol.
I understand that SaaS is the only way to monetize software projects in 2023, but this whole setup is not defensible.
The self-hosted client talks to the self-hosted worker, the latter which is the server responsible for querying and processing your data, and storing your creds. So basically your sensitive corporate data flows from your self-hosted worker directly to your self-hosted client. There's no funny business in between. Only the worker can initiate calls to our backend API (not the other way around), and you can easily inspect our network requests and payloads. We do store app metadata, UI properties, and the names of the columns you configure in your tables. The worker sends periodic health checks to our backend. Hope that clears things up!
