[HN Gopher] Show HN: Dropbase - Build internal web apps with jus...
___________________________________________________________________
Show HN: Dropbase - Build internal web apps with just Python
Hey HN, I'm Jimmy, co-founder of Dropbase
(https://www.dropbase.io). We are an internal tools builder for
Python developers. All you have to do is import any Python
scripts/libraries, declare UI components, and layer app permissions
so you can share them with others. 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.
Author : jimmyechan
Score : 79 points
Date : 2023-12-05 18:25 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| edmundsauto wrote:
| Very cool, thank you for sharing!
|
| 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)
| jimmyechan wrote:
| 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.
| cjohnson318 wrote:
| Hell yeah. I build internal web apps with Django. I'll definitely
| try this out in my upcoming project. Some major pain points are
| going past tables of data to (1) graphs (2) create/update modals
| (3) cron jobs. I've used and contributed to some plotting library
| I don't remember. For modals I usually use Vue+Primevue and for
| cron jobs I use celery+redis. Login is a pain, but it's mostly a
| solved problem on my end.
| ayazhan wrote:
| thanks for the feedback! i'm curious, how critical are graphs
| for your internal tools and what are some examples of their
| use?
| cjohnson318 wrote:
| Pretty darn critical! I built a service a few years ago to
| scrape natural gas volumes from different refineries and my
| client wanted that data plotted over time. Another project
| collected and displayed wellhead pressure data.
|
| Oh yeah, maps are also super important, and being able to
| overlay different statistics and or graphics over them.
| twism wrote:
| why the internal moniker ...what stops this from being "external"
| facing?
| jstummbillig wrote:
| I am so confused about this too. retool, tooljet, budibase -
| why is everyone doing this? Best I can figure out is that no
| one has found a pricing structure that works otherwise, which
| would be rather sad if true.
| djangelic wrote:
| I assumed this was because it's internal devs that are
| actively looking for platforms to build on, while external
| devs might already have stacks they prefer to work on due to
| how it interacts with their security postures. Pure
| speculation, but it's been my anecdotal experience.
| ayazhan wrote:
| i second that. for external-facing tools, you probably want
| something custom, branded, and more flexible. when it comes
| to internal tools, you typically want something quick to
| get the job done.
|
| 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
| jstummbillig wrote:
| Are you aware how most companies external apps look like?
| Here's how: They don't.
|
| 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.
| jimmyechan wrote:
| 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
| karl11 wrote:
| It's because every small business has this problem and need,
| and there are a lot of small businesses. But selling
| technology to small businesses is extremely hard.
| jimmyechan wrote:
| 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.
| slig wrote:
| Congrats on launching!
|
| > a backend API for app/component definitions hosted by us to
| simplify pushing feature updates
|
| Any plans to open-source that part as well?
| ayazhan wrote:
| frankly we're new to open source. and technically we're not
| really open source. we wanted to take advantage of the self
| hosted nature of data processing worker, which are safety,
| extensibility, and developer trust. that's why the worker is
| under the source-available model.
|
| as we grow and learn, if we get interest from the community to
| contribute, we'll definitely consider opening more of the
| codebase.
| jimmyechan wrote:
| 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
| dfthinkpad wrote:
| I am confused on why I need to sign up for an account to try it
| on my machine?
| ayazhan wrote:
| yes, it's a bit inconvenient, but user management and ui
| component definitions are managed by the dropbase server.
| because of this, we need an account, with a token to identify
| and authenticate a workspace
| azazel75 wrote:
| The license kinda sucks though: ``` 3. USE RESTRICTIONS
|
| Licensee is expressly forbidden from:
|
| (a) Incorporating, modifying, or using the Software as part of
| any other product or service; ```
| paulddraper wrote:
| Wait people read those?
| jimmyechan wrote:
| We should have a Chrome extension that just summarizes the
| license for any Github repo you hang out at!
| jimmyechan wrote:
| 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!
| foxbee wrote:
| How would you compare this to tools like Budibase?
| goerchw wrote:
| Or NocoDB?
| throwaway81523 wrote:
| I've done plenty of internal web apps with Python's old cgi
| module and it's really about the simplest approach. Too bad the
| cgi module has recently been removed from Python due to some
| weird neurosis about underused modules. It's still possible to
| side-load it from someplace though.
| jimmyechan wrote:
| What kind of apps were you building and what did you like most
| about building with the cgi module?
| zlg_codes wrote:
| This is something that irritates me about some languages. I get
| the intention of keeping a clean language, but for something as
| foundational and basic as CGI... what's the real problem in
| keeping it there? It's not like CGI itself has changed much in
| the past 20 years...
|
| 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.
| urban_alien wrote:
| Not strange at all! Leave those assumptions behind, take a
| look at symfony/console and minicli. PHP is not shiny or
| snarky as Python, but resilient and "boring". The "dirtness"
| that you are feeling is just a way to keep those insufferable
| people that you mentioned out.
| goerchw wrote:
| Interesting. How does this compare to https://flask-
| appbuilder.readthedocs.io/en/latest/?
| jimmyechan wrote:
| I hadn't heard of it, but I'm excited to check it out!
| kelvinzhang wrote:
| We definitely need more ways to build quick web UIs for Python
| code. Looks sick!
| ayazhan wrote:
| thanks Kelvin! :)
| jimmyechan wrote:
| Absolutely, thanks!
| soperj wrote:
| You have 6 comments from your account and one of them is this:
|
| > I'm one of the engineers behind Dropbase.
|
| So I hope this isn't the first time you've seen this.
| jimmyechan wrote:
| 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!
| waydegg wrote:
| FastUI (https://github.com/samuelcolvin/FastUI), a fully OSS
| Python-to-React library was just launched recently too
| ayazhan wrote:
| this looks great, thanks for sharing! i'll check it out. we are
| also big fans of Pydantic and FastAPI
___________________________________________________________________
(page generated 2023-12-05 23:00 UTC)