jimmyechan

I'll check this one out - it looks very interesting!

I think I understand the irk, but I feel that your presumption of our intention in posting a GitHub URL is unfair. In fact, I'm not sure how else we'd share the news that you can self-host this without posting a Github link. We've made it very clear throughout the comments that we are not an open source project and nowhere in our website or GitHub do we try to mislead people to think so.

These are all great tools! The use cases we are going after different than those these tools make easy. One way we think about the difference is analytics vs operations. Another way is dashboarding (streamlit) vs triggering actions (dropbase). By triggering actions we mean, triggering tasks that get/act on internal/external data, as opposed to a rearrangement/display of existing data.

Yeah, the code is in a docker image, published on docker hub. It's prepackaged so it's easy to set up with docker-compose. The repo mostly has the docker files needed to self-host the dropbase worker and client. As you said, it's a bizarre, but not uncommon way to distribute. We're not technically open source at the moment, but considering evolving into source-available, and maybe eventually move up to an open source model. But we still have plenty to figure out. It's a bummer we can't get your feedback though, that's definitely a nice thing about open.

We've heard of Tkinter before, but haven't really looked into it. We don't have a lot of experience with desktop apps and we're mostly unfamiliar with this space. But a few people have asked us about desktop, so we do a bit of research here.

Not yet, but will check it out! Thanks for sharing it

Thanks! We've heard something similar - many Python tools in financial services. I think they build tools on R too. We should probably try to reach out to people in this industry to learn about the kinds of apps they build and whether their home grown tools are missing something we can ship

> as AI turns more subject matter experts into programmers who can code a bit of python

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.

This is actually quite encouraging for us as product developers (although maybe it's not a good thing if end users don't get good tools). It just means there's a lot more room to grow. I wouldn't say we've given up on external, but there's definitely a part of us that's hesitant to communicate the product as a "build anything" app so early. The fact that you think that could actually be an obvious differentiator is quite intriguing and thought provoking. I should do more research and understand the extent to which customers of big companies are exposed to google forms (and similar tools). Maybe we'll discover something interesting in the process. Thanks!

I can confirm all our engineers have seen this product before launching it lol.

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!

Absolutely, thanks!

What kind of apps were you building and what did you like most about building with the cgi module?

Also fun fact: originally we only intended to enable self-hosting for the Worker, but we ended up enabling self-hosting for the Client too. If we also end up enabling self-hosting for our backend API then we'd probably rethink our distribution approach

We should have a Chrome extension that just summarizes the license for any Github repo you hang out at!

I hadn't heard of it, but I'm excited to check it out!

We should probably clarify that although we are pointing our post to our Github repo, it isn’t technically open source. It’s something we’d like to explore in the future with Dropbase though. At the moment, you can self-host our Client and Worker.

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!

It's just how we try to narrow down the uses cases that the product would be better suited for. I'd love to come up with a better name for it. At the end of the day, I think we're all just different approaches to a similar problem/use case

I think it requires a lot more UI components, more flexible layouts, and customization options to be able to build something externally facing. Building for end-users, especially on the consumer side, tends to require a lot of flexibility on all 3 aspects. Our product could handle it, but the resulting apps will feel quite limited.

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.

I'd say it's closer to the latter, unless you are already quite familiar with Django. Dropbase is a lighter framework with a more narrow use case, whereas Django is a much more powerful, complete, and you could practically build anything with it. For internal web apps/tools specifically though, it'd be much faster and with a smaller learning curve to build with Dropbase.

Excited to make Dropbase available for local setup! It’s free for personal use. It’s still early so we're really excited get your feedback, especially on our approach to tools building.

Dropbase lets Python developers build fullstack internal apps without writing frontend code. Just Python. Import any Python scripts/libraries, declare UI components, and layer granular app permissions atop so you can share them with others. To make this work, we created a State class that lets you access UI state and a Context class that lets you access/modify UI component properties directly via Python functions. It does the job but results in occasional state syncing issues. Maybe you have some ideas on how to improve this architecture.

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 by focussing on what you need for most tools: to see some data for context and to trigger actions based off it.

We have a hybrid hosting model that combines a self-hosted client and worker server, with a backend API for app and component definition 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 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 UI components to Python functions. 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.

A neat feature we are experimenting with to build admin panels fast is “Smart Tables”. We can convert any SQL SELECT statement (even across multiple joins and filters!) into an inline editable table, like spreadsheets, without any additional code.

We envision a product that lets you quickly add UIs and permissions to any Python scripts, libraries, files, etc., and turn them into simple web apps that you can share with others. We’ve designed it in a way that would let us add support for Rust, Go, and others later.

We have some demo videos here: https://docs.dropbase.io/category/demos

Create account and setup here: https://docs.dropbase.io/category/setup

Note: Developers can only signup/setup via our docs page at https://docs.dropbase.io. It's currently closed for the general public. Looking forward to your feedback!

This is a fun idea! I've been trying it, but getting errors. Is it down?

The page looks nicely designed. You could try seeding this first. There are many ways to do that, but one of the easiest would be for you to launch your own campaign using your own product, offering a service you can offer, to fund marketing budget for your site so you can help grow it and benefit more people. For example, you could help local businesses improve their landing pages or something that matches your skills. Your campaign could be to raise money to increase awareness of Taskwer. You can be the first successfully funded project in your own product. Then talk about that. I'd try to bring in one campaign at a time that are 100% funded. Good luck!

Founders are already great at making up personas that aren't quite accurate or don't really exist, but that sound real. This is mostly because of an incomplete understanding of the persona or not talking to users enough. This product could be a good way to get started or even lay out a framework for a potential persona, but the highest value work is in fleshing out these personas by actually talking to users.

Curious to know your use case. Were you hoping to use Retool Database with your existing Postgres as a schema builder or as a data editor via their spreadsheet UI?

Yes, while the GPT API latency will be minimal, whether it's noticeable by users would still depend on the application, use case, and even the location of the client(s). In some cases, the small latencies may still be noticeable for example in gaming, chat apps, or maybe some large enterprise deployment that's tied to specific regions. I agree that for hacking it won't make a significant difference and there's no reason to get on Azure just for GPT - too much overhead and Azure isn't the easiest to figure out to begin with.

Your app could be slightly but meaningfully faster (depending on your use case) if the other servers/services your app relies on are close by (also on Azure, in the same region region or datacenter). Otherwise probably not much more speed difference aside. There are other benefits such as managing everything in the same cloud, single billing, and maybe even some security benefits of having everything in the same VPC. This is assuming Azure will allow you to chose a region for the GPT4 service.

Not yet, but my bet is that we will be able to in the near future. The gpt-4-32k (with a 32K context window) allows for about 52 pages of text

Livestream developer preview link in case you missed it - https://www.youtube.com/live/outcGtbnMuQ

Yes! Swapping out NumPy with Arrow underneath! Excited to have the performance of Arrow the API of Pandas. Huge win for the data community!

Side note, unrelated to the main post, but I read "open source", "seeds", and "A's and immediately thought farmers are raising big VC funding rounds. I think I need to start reading other kinds of news.