jimmyechan

Congrats Tom!

Congrats! Cool project! I’d been curious about whether GPT would be good for this task. Looks like this answers it!

Why did you choose markdown? Did you try other output formats and see if you get better results?

Also, I wonder how HMTL performs. It would be a way to handle tables with groupings/merged cells

No. At the moment all apps work on top of our internal framework. However, you can reuse your existing Python code/libraries. For instance, you could call existing Django models from Dropbase apps. You can also import any PyPI package.

I like your take on that! I hadn't thought about it that way before but "Writing two files to build a webapp" indeed sounds quite intriguing. And we could extend that idea to "...and deploy it with 1 click" or some version of that.

I'm curious about what audience you have in mind and what kind of apps would you be interested in building this way? Would love to hear more of your thoughts!

Edit: I should add that our main motivation for integrating GPT is that we had to introduce some new concepts to make this experience work, which increased the app-building learning curve. We thought having GPT generate code and highlighting diffs would be a neat way to teach users how to develop apps without reading a lot of documentation.

Thank you! I read your blog post and checked out your project! If I understood it correctly, you’re trying to build a software engineering team in a box. Basically from first issue, to code, to live apps. Very interesting approach adding the collaboration angle! ASTs are neat but I’d imagine it could get hard to manage with more complex code.

In our case, we regenerate the `main.py` file each time. One of the hacks we did was to start with boilerplate code, which is why you see it modifying the code as opposed to generating from scratch the first time. We also feed the model with some context/rules on app building using our web framework, so the output is more bounded.

We haven’t tested it on really big files yet, though I'd imagine it could be a problem later. At the moment, we don’t generate HTML, JS/TS, or React code from scratch so our files tend to be relatively smaller than if we did. Our UI is defined via the `properties.json` file, which abstracts much of the underlying code, therefore keeping the files small. It’s much easier for LLMs to generate json and map it to UI behavior, than generate of the client code needed to do all of it.

We don’t have issues with the LLMs changing function/method code, but it occasionally implements one of boilerplate methods we didn’t explicitly ask for. In those cases, a developer has to remove that code manually, which is why showing code diff is critical.

Many other hacks come down to lots of prompt engineering! Something along the lines of "Only implement or modify a method/function corresponding to a user's prompt. Leave all others intact"

Happy to chat more!

Also you might find this blog post we wrote interesting: https://www.dropbase.io/post/an-internal-tools-builder-that-...

Interesting approach to just do json instead of protobuf!

Can you provide examples of 2 services that interact with one another? Do the services call each other, or do clients call a service that then calls another service?

Co-founder of Dropbase here. We're a better fit for you given your comments about Django and being in the same repo.

We are an internal tools builder that works with your existing Python codebase, in the same repo as your core app. You can call/use your exiting Django models from Dropbase UI components, and build fullstack internal tools with just Python.

This is awesome!!! I'm really impressed with the demo. In particular, with how fast it seems to work given the number of models you use, the client-server back and forth, and the required processing and text gen. How did you do that? And at which point do you start to get bigger latencies e.g. writing an email, an essay, or a novel where you change the spelling of a character's name 2 chapters earlier.

Cofounder @ Dropbase (dropbase.io) here. If you just need to build internal tools with Python or want to build internal tools on top of your existing Python codebase, give us a try. We have granular permission built-in so you can share internal tools with others easily, down to who can use or edit each internal tool you build.

For context, we're a more niche cousin to Reflex that's specifically designed to build internal tools. Reflex seems to be a more general framework to build anything you want; quite powerful, and possibly an easier to use Django replacement.

It's awesome to see frameworks like Reflex. I think the Python ecosystem needs this.

It depends on your use case or development preference. Check us out at Dropbase (https://dropbase.io)

Is your cron running locally or do you have it set up on a server?

Woa! That's quite a bit. What do you use for your static site generator? Or is a custom tool you built for yourself?

Curious, how do you organize or keep track of all your scripts? I assume you have them easily accessible so you can trigger them quickly?

How do you usually trigger scripts? Do you do it via Ansible or manually via terminal?

Airplane customers: Our engineering team is in the position to help you migrate your Airplane UIs/Tasks to an alternative platform, even if it’s not to Dropbase.

Cofounder of Dropbase here. We build similar tools to Airplane.

I’m surprised to hear the news. I’ve always been impressed with the product/team and we share the same vision for a more developer-centric product.

We imagine it must be a bummer to have to migrate so suddenly. We want to help in a way that’s actually meaningful.

Reach out to airplane@dropbase.io

Additional info:

- Our latest Show HN for context on the product: https://news.ycombinator.com/item?id=38534920

- Our tech stack: Python, Typescript/Javascript, React, AWS, FastAPI, Postgres, Pandas

- Other tools: Stripe, HubSpot, Slack, Snowflake, OpenAPI. We have experience with other app builders and we pick things up fast

Streamlit is a great. Despite the fact that we are both Python-focused, the use cases for the two products are mostly different at the moment. When it comes to triggering tasks/actions, updating databases, processing data, and talking to APIs, you’ll find Dropbase the more convenient of the two.

It has actual source for the worker. We aren't worried about it being leaked because we are not particularly trying to hide it in the first place. We will probably make source available to paying customers on request if they want to verify that their sensitive data only moves between self-hosted worker and self-hosted client.

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.

That's an interesting use case. Thanks for sharing. I think I understand your point better after reading this. I agree that having to pay xx$ indefinitely for presumably many end users who will only fill up the form once (or very rarely) doesn't make sense. We don't have a solution to this just yet, but I have a couple of ideas on how to tackle this.

PS. CRUDy sounds like a fun and quite literal name for an app builder!

Lol not sure if your comment was meant as a joke, but wanted to clarify in any case to clear up any misunderstanding: We don't exfiltrate your sensitive corporate data.

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!

Looks like Airtable. Also no-code, like Budibase above.

I wouldn't. Budibase looks like a no-code tool and we are code-centric. I saw in your profile that you are the cofounder of Budibase - perhaps you can confirm my understanding.

I'll check it out

Looks interesting! I'll check it out. We don't currently focus on chat apps and don't have a chat component yet so it'd be significantly harder to do this.

Ha! What a pivot that would have been! And the story behind it!

Give it a try! You can copy those scripts as-is into the workspace directory and with a few lines of code turn them into web apps.

Thanks! Yes, absolutely! All HN readers can try without booking a demo. Get an account here: https://docs.dropbase.io/setup/ and then follow instructions for local development setup here: https://docs.dropbase.io/setup/developer

Flask and Django are web frameworks that are more geared towards general app development - you could build anything with them. Dropbase is an app builder that makes it easy to build certain kinds of app: internal apps used to support customers, business operations, build admin panels, or trigger tasks or processing jobs. You can’t build absolutely anything you’d want with us, but for a narrow set of uses cases, you can build it very quickly.

Thanks! You’re spot on about our approach! Python, binding code files to UI, table+sidebar.

Thanks HN! Really appreciate your input! Gotta sign off now though, it's getting late for me. I might answer some more questions in the morning if this is still on!

Some context here is that our launch is mainly to developers. Other users can't even sign up from the website or use the product without self-hosting. In any case, we'd still need to post a link to Github, somewhere.

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.