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.
Oh yeah, maps are also super important, and being able to overlay different statistics and or graphics over them.
could you elaborate on cron jobs being a pain point? would you use it as a scheduled task to fetch/prepare data before user logs in or let users schedule jobs on their own to run async? any use cases you could share?
Sure, I've used cron jobs to collect data, send reports, and check if any users should receive push notifications or alert emails.
The pain point is that celery can be a little tricky to configure when you're working with docker-compose. It works, but if I had to re-figure everything out again, it would take me a while.
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.
are there any limitations you encounter with NiceGUI? do you need a user permission feature or does each user get admin access? can you see it scaling up easily?
For scaling, I am viewing it mostly as an internal tool builder. I wouldn't recommend it for external applications. So as far as scaling an internal app I think it works fine. Their website [2] is built with NiceGUI, and it works fine, but you can feel the lag occasionally on some of their larger demo pages.
1. https://github.com/zauberzeug/nicegui/blob/main/examples/aut...
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.
The other reason is that internally we've always thought that we'd eventually gravitate to an open model when the time is right i.e. at least until after we've figured out the product.
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)
> 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.
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.
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.
at dropbase, our focus was on enabling developers to get stuff done efficiently. we noticed that for 90% of internal tool use cases, you only need a table and modal to get user input. so we focused on developing those. while it may not be sufficient for external apps, for internal tools, it should cover most of that you need
What you compete with, what you have to beat, is not "something custom branded and more flexible". It's nothing at all. Cutting yourself out of that market with a tool that would easily be powerful and user friendly enough to fill this gap does not make any sense to me, if that is in fact your true reason. (And also I don't understand how that could make any sense intuitively if you just look at how often you see google forms being used by a big company as an external data collection tool).
It could be such an obvious differentiator for any of the competitors – but, like I said, I suspect the actual reason to why people are so ready to give up on this is rooted somewhere else.
For the patients, you might need submission process, you might need a place for people to see or cancel their next appointments, fill out a form or upload some pictures from other, while also making this information available internally, with doctors being able to document therapies and such.
Nothing fancy; I would hardly call it "build anything", it's all fairly CRUDy and on the face could be very effectively handled by all retool-alikes. (In fact budibase for example could have easily filled the need from a technical standpoint – but having to pay xx$ indefinitely per "customer" just does not work out, when you see most of them only once a year and maybe only once total, while having to keep records for many years.)
PS. CRUDy sounds like a fun and quite literal name for an app builder!
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
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
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.
But maybe I’m the dinosaur. I still associate GitHub with open source, but closed source developer tool startups seem to increasingly use it as a ProductHunt.
If you're saying it's ok to post a Github link to a non-open source project, but just not as the main URL, I'd understand, but I still feel that in our specific case, the Github link is the least friction path to set up for self-hosting. I think a developer who goes to a marketing site and doesn't easily find way to setup/self-host would be more frustrated.
In that case the marketing site should probably be fixed.
"If it can be self-hosted, it has to be on GitHub" is a really weird claim, considering that tons of "self-hosted" open source projects aren't on GitHub. debian.org, for instance.
Also, I personally wouldn't call something that requires an external backend API (if I'm understanding this correctly?) "self-hosted". Partially self-hosted? Not sure. It's not exactly on prem either.
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!
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!
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.
i feel like the challenge would be to find a subset of customizations that would work for most users.
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.
I would hope argv and argc at least are passed by default in PHP programs on the command line. New experiment unlocked I guess.
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!