Do you find yourself for your team building internal apps frequently for your company?
Are you familiar with the term forms over data?
They can be super empowering for your organization, but they can also be pretty repetitive.
And you might find yourself spending more time than you like working on them rather than core products and services.
I've invited Jimmy Chan from Dropbase to tell us about their services, whose tagline is build internal web apps with just Python.
It's a cool service and a fun conversation.
This is Talk Python to Me, episode 460, recorded March 12, 2024.
Are you ready for your host?
Please.
You're listening to Michael Kennedy on Talk Python to Me.
Live from Portland, Oregon, and this segment was made with Python.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy, and follow the podcast using @talkpython, both on fosstodon.org.
Keep up with the show and listen to over seven years of past episodes at talkpython.fm.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube to get notified about upcoming shows and be part of that episode.
This episode is sponsored by Mailtrap, an email delivery platform that developers love.
Try for free at mailtrap.io.
And it's brought to you by us over at Talk Python Training.
Did you know that we have over 250 hours of Python courses?
Yeah, that's right.
Check them out at talkpython.fm/courses.
Hey, Jimmy.
Hey, Michael.
How are you doing?
I'm doing well.
Welcome to Talk Python to Me.
It's fantastic to have you here.
Thank you.
I'm really excited.
Yeah, I am too.
I saw DropBase.
I saw what you all were building.
I'm like, that is pretty darn interesting.
I think people will want to check it out.
So we'll dive into this app and this platform that you made for app building, basically.
We'll have a lot of fun.
Now, before we get into that, though, just give us a quick bit of background on yourself.
How'd you get into programming?
How'd you find yourself writing a Python building platform?
Awesome.
Yeah, I went to school for engineering.
This was actually back in Canada.
I studied in Montreal at a little school called McGill University.
Nice.
We started then.
I used to intern, by the way, at this company called Research in Motion that used to make
BlackBerrys way back in the time.
Oh, yeah.
Awesome.
In the heyday?
In the heyday.
I remember when they said we had 50% of the US smartphone market share.
But the platform was actually built on Java.
No, Python.
Python was something afterwards.
Actually, my co-founder is the Python programmer.
And I picked up Python after we started working together.
Cool.
You got any fun stories from your time at BlackBerry?
Did you enjoy it?
How long were you there?
I was there as an intern only.
Spent about 16 to 20 months of internships.
Yeah.
At the time, I was, I think, in my third year of school.
And we were just working on these little Java apps for the smartphones and just making sure
everything was working.
The cool thing is when you work at a company that's making devices, devices have a very long
development cycle.
So imagine, for example, you worked at Apple today.
Like the iPhone, what, 15, whichever one's coming next.
Like they've been working on it for at least a year, probably longer.
Do you get access to all these prototypes that you get to use?
Because like you're building for it, you're testing it.
That was a really nice, nice, nice thing.
But you actually couldn't tell anybody about it.
But it was really cool to know that you're on the last thing.
And you couldn't lose it in a bar or anything like that, right?
You remember those stories, right?
Yes, exactly.
A few times.
Somebody got a hold of a lost phone and it was sold and there was all sorts of drama.
It was a big deal.
That was around an iPhone 4, 3, 4, 5 sort of time frame.
Yeah, I remember that very clearly.
Yeah.
So you didn't want to be that.
You wanted to make sure you hung on to it.
Oh, yeah.
No.
Yeah, I think working for a company like that would have been awesome, at least in the heyday.
It's cool to work for a tech company that's got a lot of wind that it's back and a lot of people using it.
It's kind of neat.
I was very happy.
We had a lot of other interns that they hired at the time.
So you just had a blast to work in there over the summer.
Yeah, a lot of excited people to do stuff.
Excellent.
Cool.
And so then you picked up Python, I guess, when you started this project.
Is that right?
Just a little bit before.
So when we started our startup, this was back in 2020.
My co-founder had been using Python.
He did a master's degree, computer science, focused on machine learning, actually.
In that field, Python is really the main language you use.
Yeah, it is.
And so he was very familiar with it.
And so he set our stack, basically, to be a Python backend.
And then just through that process, just looking at things and designing features, we just all got involved with Python.
So it kind of just became the same.
And this is actually the reason why we're working on a Python builder is we're kind of building a product for ourselves.
It's something where it fits our own needs, that works with our mental models.
So that's pretty much it.
So today, I spent a lot of time building apps with DropBase, so internal tools.
And that's most of the app building I do now.
So building demos, testing the product, making sure everything is working.
And then just finding other ways to make the developer experience more convenient.
It seems like something you could really take care of a bunch of internal automation type of apps.
You don't have to create full-on web apps to secretize this data or get that dashboard or whatever, right?
You just fire up your own platform and win at your data sources.
That's right, yeah.
So the big difference with other frameworks is that you're going to use these frameworks to build your customer-facing applications.
And customers, they have expectations about what they need.
Interactions sometimes make a big difference for them.
UI components, the way models come up.
It's all part of the experience.
And so for that, you really need a lot of extra components complexity.
For internal tools, it's not to say that internal users don't have high expectations.
But the kinds of things that you do with those tools tend to be very, very similar.
You search for data.
You get context about that.
So for example, you search for a transaction or for a user.
You get some more context to make sure that that's the user or the transaction that you want to act on.
And then you just act on it, right?
Like you trigger an action on that item or that resource or that person.
It helps you simplify the kind of things you need.
And so for that, having a framework, a builder to make this happen is super convenient.
This is a little bit of a tool.
And when I think of internal web apps or even traditionally, if you look back a ways, there was VB6 and Windows Forms and those types of things that were kind of playing the same role.
So same basic idea.
There was a lot of people who referred to that as forms over data.
It kind of the not quite a negative term, but kind of like we're sort of doing the same basic architecture over and over.
But it's a different problem every time.
And so we kind of got to write code, create these projects from scratch every time.
But they're the kind of same kind of thing.
And so, you know, I think that's probably why VB6 with its kind of visual drag and droppy experience became real popular because you could drag a table on there and drag a data source, bind it to that and make a button click when somebody touches this thing.
And that didn't create something that would rival, say, Airbnb.com or, you know, these really dynamic design sites.
But that's not what they need.
The company says, look, we need this week.
I need our salespeople to be able to answer this question and make this change.
That's what we need you to build this week.
And if it's from scratch every time, that's a ton of rework.
It's a lot of work.
It's funny you mentioned the forms over data.
It is true that a lot of the, well, if you take it at a very high level, all apps are forms over data.
In some sense, yeah.
All SaaS apps are forms over a database in some sense.
And then you start to hear also about the similar things with, you've heard about the GPT wrappers, right?
It's the same concept where it's like an oversimplification of what's happening.
But at the same time, it is kind of core to what's happening.
And for internal tooling, at least, is exactly what you need.
Forms over data, but very quickly.
So that developers don't have to spend a lot of time basically doing the same things over and over again.
You want to make their lives easier to support their internal users.
So people in customer support, operations.
And I think sometimes even supporting other engineers as well.
Yeah.
And it's not that people in companies don't have expectations of nice apps and nice interactions.
It's just that it's more utilitarian.
Like so many of these big enterprises, when you kind of think of them, maybe the right way to think of them is there's a massive Postgres or Microsoft SQL server at the center.
And like it almost connects the business divisions, like the sales team and the marketing team and the product team and all that.
And if you can get into the database and answer questions, expose data, expose relationships, put a UI to some aspect of that, you're really right at the heart of the company in some sense, you know?
Yeah, it's definitely about effectiveness.
One way we think about what these kinds of tools should do, you have to enable developers to very quickly build apps that have maximal value, that lets you get the job done as effectively as possible.
But also that's easy to use for the end users.
So, you know, if it's like a business operator or someone in the operations team, they also need to be able to learn quickly how to use it and trigger actions.
And so we call that sort of effectiveness of the apps, some sort of like effectiveness score.
Yeah.
It just combines these components.
And that's really the, like, if you can get to the essence of it and create a framework or a tool builder that maximizes for that, I think you're in a really good place.
And this is something we're trying to do with DropBase.
The components are simple.
The kinds of apps that you can build look roughly the same, but they look really nice.
And they're also quite simple to understand.
They're modeled after, but it's in a way where you have data, a greater table in the middle, and then there's a sidebar from where you can trigger actions.
And this ties back to this concept of when you ask people in operations what they do, like sales, marketing, business operations, essentially it ties back to the previous comments, which was you search for something, you get context about it, and you trigger action.
And so the way we translated that insight about what people just end up doing over and over again, we said, well, then you really just need some sort of search bar.
You need a grid and you need a sidebar with some buttons or some other drop downs and other components.
And then you realize, okay, this is kind of what spreadsheets I've been trying to do for a long time.
Yeah, that's true.
Except we like to trigger actions.
Yeah.
People do oddly connect Excel to, like, external data sources and all sorts of weird things as well.
Yeah.
Or write VBA that makes some change.
They probably should just not be doing that.
Yeah.
There's a lot of, it's actually a big use case.
One of our previous product, we actually did exactly that.
Okay.
We let you connect any database source to your Google Sheets and just kind of run that on a schedule.
So you'd imagine in a business setting, you have sort of these, like, weekly, daily reports that analysts end up working on, right?
And what you want is for the data to be fresh, up to date.
And so people just wanted a way to, on, at 7 a.m., 8 a.m. on Monday morning, basically automatically pull data from a database, load it up to your spreadsheet.
And then all your tables and calculations, which is sort of updated because they're referencing a tab, a sheet, basically, that has fresh data.
It's very interesting, the evolution of all these tools.
It is really interesting.
Maybe one of the big differences is the interactivity here versus what you might do in that story, right?
That's read-only, really.
And then here, what we're doing is letting you trigger actions, perform actions, basically outside the app.
So you might call an API or you might trigger an internal endpoint or just trigger some action in the UI.
This portion of Talk Python to Me is brought to you by Mailtrap, an email delivery platform that developers love.
An email sending solution with industry-best analytics, SMTP, and email API SDKs for major programming languages and 24-7 human support.
Try for free at mailtrap.io.
I think we'll get to this more later, but I want to maybe touch on it since there's a good question.
Also, it might be a question a lot of people have.
So what's the pricing model for this?
And basically, more broadly, what is the business model around here?
Luis says, already amazed by it, would like to compare it.
First thought, there's nothing like this available in open source.
So very neat.
The business model is we're going to sell the product on a per-user, per-month basis.
So it's a B2B SaaS app product.
Now, developers need to be able to play around with products before they can decide whether that's something they want.
And so we have a free version of the products that you can set up locally, like in your own machine, or you can just put it up on EC2.
And you can just build apps for yourself.
If you want to automate personal tasks, you can totally use this for it.
And then the way that we, in a way, layer the pricing is like, if you need very complex permission systems, so like you build an app and you want it accessible by this person, by person A, but not person B, then you'll need very granular permission systems.
And so that's an indicator that you're probably like a corporate user, you're a business user.
And so we do the pricing based on that.
The source is open, at least.
People can go and check it out, right?
Is that true?
Let me clarify that.
So you can self-host it.
Yes.
You know, you can look at the repo.
Behind the scenes, it's a Docker image that you set.
So the code for draw base is not immediately, you know, you can't just browse it through the file system, but the code is basically sitting in your machine when you set this up locally.
Now, the difference here is if you look at the directory where you have the workspace.
So the workspace directory is where all your apps files would be generated as you build the apps.
That's really nice because you can essentially version control this from day one.
You can build apps.
You can check it in GitHub.
You can just keep your code.
You can version it.
And so it's really, it's not open source.
It's clarified that, but you can self-host it.
It's on GitHub, but the licensing is really not like just straight up GPL open source type of thing, right?
That's correct.
Yes.
Okay.
And it's on GitHub because you need to, you do need to clone the repo and then you need to send it out and install it.
The free tier doesn't allow self-hosting, but if you pay for one of the versions, then it does have a self-hosting option.
So when you, just to wrap this up on the price, when you say it's $10 per user per month, is that per person that makes the project, that builds the apps?
Or is that per person that interacts with the web app?
This is currently per member of your workspace.
So we're not yet differentiating between someone who is building the app or using the app.
Although that might be something that we'll have to add later on.
Sure.
So if you had say four salespeople and one developer in quotes, maybe developer, that would be five users under this story.
Correct.
Under the current pricing, yes.
Okay.
You know, even if it's not just pure open source, take it and run with it.
I do like the self-hosting aspect of it because if you've got private data or maybe even more important than any of that is I want to connect it to data sources that are, I don't want to give your cloud access to my company database, for example.
I can expand on that, actually.
So we built this specifically with that comment in mind.
So when you're using internal tools, it's very, well, let's say it's almost all the cases you are interacting with production, at least one production database, right?
Like if you're supporting customers and you're issuing them a refund, you don't do that in tests and then take it to staging and then deploy it, right?
You basically, you act on it on your production data.
And so we thought, okay, people are probably going to be very hesitant to basically say, let me load up all my creds, all my API keys into some new player, new cloud, and then like hope for the best, right?
So when we designed DropBase, we call it the worker or the worker's server.
The way you connect to data sources is you basically go to your .env file and you just add your database creds.
And that .env file sits in the same directory that that workspace directory sits, the one that we saw on GitHub.
And that's completely on your side.
And that's in your VPC or in your local machine.
And the same server is the one that triggers the task to query your database.
So, and that's also sitting on your side in your machine.
And so the entire part of the product that processes, queries, touches your data, your data sources, your credentials, that's completely on the user side.
And the only part that we manage is really just the permission system.
So that controlling the workspace and controlling the like the app permissions.
That's the layer that we control.
And that's really like the part where we can do the pricing on to begin with.
Like that's the, that's the feature set thing that helps us say, okay, this is going to be paid customers.
And these are going to be developers who are just going to learn how to code in Python.
They just want to build little apps for their own personal use.
All right.
That makes sense.
You know, let's maybe talk through an example.
If you go to dropbase.io, there's a, right at the top, there's a sort of tutorial or a demo video of you using it.
Obviously, I don't want to just play the video, but maybe just talk us through the steps of what this app is and what are the steps to build it.
And just for people who are listening, haven't watched that video, maybe I think it's 12 minutes long and you're like, let's create a new project.
And here it is published at the end, right?
Which is really nice.
So yeah, talk us through.
I'm going to try to recreate the exact same one that's, that you have on the, on the screen, right?
So it looks like an app that has two tables and you can somehow perform an action with up on the sidebar.
Basically, it just notifies, either notifies a user or it performs some sort of permissions.
I think what this one does is it has a workspaces and then users are in a workspace and you can make them admins or not admins of that workspace.
Gotcha.
Perfect.
Okay.
So I'll describe how you build this app.
So you go to our app studio and it's going to be a blank canvas.
In that canvas, you can add tables.
So the first thing you do is you add table one, you add the first table, and then you add table two, which is the second table.
And then you add a widget on the sidebar.
You just click on add button and then it just places a button on the screen for you.
That will be sort of a shell of the application.
It'll be just the UI part.
At this point, it's just a few mouse clicks.
There's no JavaScript code or Python code that you're writing.
The next step is to add the sort of the logic behind the scenes.
The first thing we need to do is to populate the first table with data about your workspaces.
And essentially what we do is you click on create new, you create a new function.
And in that function, it could be a SQL function or a Python function.
Because that's just a table, you can just create a new SQL function.
So you do create a new function, select everything from workspaces, let's say that's the table.
And then you can see a little preview of what that select statement will result in.
So you can verify that that's the data that you want to show.
Once you've done that, you just save that file, that query, and you do something we call binding.
So in the UI, you can select table one, and it'll present you with the table's properties.
And one of the properties is which SQL file, which SQL script it's bound to.
So you just click bind to the SQL file that you just wrote, and then it just automatically
populates it with data for your workspace.
Now, the second table is a little bit more interesting because the second table will update
depending on what row you've selected in the first table.
When you click on a workspace in the first table, it should load all of the users that
are part of a particular workspace.
And so we do this, we have a feature called dependent tables, and that's exactly what it
does.
So for the second table, you would still write a SQL query, and the query would just say,
select everything from users where the workspace ID is the selected row workspace ID from the
first table.
And we used to sort of a Jinja, I'm not sure, maybe the audience will be familiar with Jinja,
it's sort of like Jinja templating style where you say, select everything from users where
workspace ID is double curly brace.
And then we have something called state.
State basically gives you the state of the UI at any point in time when you've clicked something.
And it's really, we made it into a class.
So you can say state.tables.table1.workspaceID.
We resolve that into the value that's the workspace ID from the first table.
And so that's, and then you do the same thing.
You save that SQL query, you bind it to the second table.
And then we automatically infer that whenever you need, whenever you select a different row
in the first table, the second table will update the workspace ID value, rerun the query,
and then show you the data for it.
That's cool.
I was wondering how that happened.
I thought you must have to wire some on change event, clicks over here, then it triggers that.
But you just have that all automatic, right?
The UI actually knows that which tables are related.
The UI sends a payload to the backend saying, this table was clicked and this other table is related
to it.
And so we kind of know that we need to process those again.
And so that's how we do this dependent table for the getting the value of the workspace ID in the
first table.
We basically, we resolve the sort of the variables in the backend and then pass the value so that
we can update the query.
So let's say that you stop at that point, right?
And then you say preview the app.
The app would look like two tables where it's really just lets you see all the users for each
workspace that you have in your database.
And then a few more things to make that very useful is you might want to search for a workspace
before you know who to support.
So let's say each workspace is associated with one of your customers.
So let's say company A is your customer and company A gives you a call, a support call and
says, hey, can you make John in our company an admin?
So the first thing you want to do is you want to find, you search for company A and
then find John.
So we have this nice feature that basically automatically creates searches for you.
So let's say in the first table, you can click on a button to convert it to a smart table.
And when you do that, we basically generate filters for you.
So you can then just say, I'd like to search by company name and you can select the filter
and you can pin the filter into the table.
And that automatically performs the search for you.
So it's just pretty neat that way.
It reminds me a little bit of Notion, Notion tables.
I don't know if you play with Notion any.
Yes.
You know, you have got those pinned swords and those pinned filters and different things
you can kind of put at the top of the, I guess their databases are called in Notion.
A little like that.
It's very similar to that in the sense that you're not writing any code to be able to search
through tables, but you can still modify what you let people search by pinning certain filters.
The really interesting thing that we've done here is that we let you do joins and still provide
you that feature.
So in Notion, for example, you would just have one database and you can filter and sort
that database.
With DropBase, what we have is, let's say you have a table called users and a table called
roles.
And then they're related by an ID where, let's say, ID 1 is users, ID 2 is developers, ID 3 is
admins.
Yeah.
You might have to join those two tables first.
And so that same smart table feature, you can just write that SQL statement, that join
statements, and we can still generate sort of the right filters for you.
And we'll actually let you edit those tables as well.
What we do is we take your SQL statement and then we infer all the SQL required to search
or edit any column within the SQL statement.
That sounds awesome.
That's a really neat feature, especially for the people who are used to using something
like Django admin in the sense that it helps you very quickly build an admin panel with very
little developer work.
Yeah.
You can just write a SQL statement and then we give you an admin panel.
Yeah.
So that's really neat.
The final thing with the app here in the demo is the little button on the right side.
Yeah.
That is a Python function.
So you create a new Python function and you essentially write a database update to update
the role from whatever it was, let's say from developer to an admin.
So it's just really a select statement, update, table, set, column, something on this particular
ID.
And so that's just a Python function.
And the final thing is just to connect that button to run this Python function.
You click on the button, we run the function, and then we perform a database update to update
the role to whichever role you want.
And that really is just the gist of the demo.
So a couple of things about that Python function that's pretty interesting.
When you create it, you can say, I want to create a function and it says, do you want SQL
or do you want Python, which is pretty interesting.
The Python function has access to the UI widgets.
Like in the actual video, not the screenshot of the video, I think you've got a dropdown select
box.
And so the Python function go, well, what did the user select?
And then we'll make the change to the person in the workspace along those lines.
So that's pretty cool, right?
That you interact with this UI in kind of an object-oriented way, I suppose.
That's exactly how it works.
So behind the scenes, we have two classes.
One is called state and one is called context.
So the state class just lets us access all of the UI state at any point in time.
Anything you enter in an input component or any row you select in the tables, you can see
the currently selected values of it.
And so whenever you click on a button or you perform an action, that state is passed to the
backend just as a payload, just like a dictionary.
And the backend, we generate all the classes, all the objects related to state and context.
So we just have to pass the values in and then execute the function with those values as the
input.
And so that's how we're able to do the state thing with Python.
If you've seen how you would do it in Python, it is very much a dot notation, right?
So you would say to get the value of column one in table one, you basically just say state dot
tables, which gives you all the tables, dot table one, dot column one.
And that basically resolves into the value of the table, of the row in that table for that column.
Yeah, that's cool.
I can imagine the implementation of that thing.
It's like dot, dot, dot, dot, get adder.
And if you ask for the thing, you look in the dictionary and you traverse the thing.
But with that in mind, what I thought was really nice about this is you had pretty decent autocomplete in your little embedded Python editor.
How did you pull that off?
I did that you noticed.
Yeah.
We spent a lot of time on it.
I bet you did.
Yeah.
How's that work?
When we were designing this, we were thinking, damn, VS Code is really nice.
You have all the plugins, all the autocomplete and everything.
But we had two choices, right?
Either we build this whole UI builder into VS Code, or we kind of take some of the things that make VS Code great and then bring it into the DropAce Studio.
We don't know sort of the final eventually where this will be.
But the current version of this is we thought, you know what, I think we need to give users an editor, like a built-in editor, so they can just quickly, they can have the best experience building the app and the access to UI and context and state really quickly.
We just did it that way where we added in LSP, so like a language server.
So anytime you type code in your Python function, it's basically over a WebSocket connection, basically streaming the code changes and saving them in your file system.
That's the only way we can do this, this like object-oriented Python dot notation access.
And so we need to have access to all the files.
And so we set this up so that not only you can do autocomplete, but also that we can actually do the state and context approach to the web framework.
It was a bit complicated because we hadn't been really exposed to LSPs before.
And so we had to learn how to use LSPs, and we had to sort of hijack sort of the WebSocket connection in a way.
So like we intercept the code, and then we save it in your file system.
So we had to customize it a little bit to do this.
And it's really nice because now you can do autocomplete for your files.
It's just a need.
It's so hard to develop now.
We're so used to these tools.
And now with things like Copilot, like we're used to even more than just autocomplete, right?
It's like autocomplete the function, not just the variable, right?
I feel like autocomplete is just table stakes, you know, especially in this kind of thing.
There's somebody who's just done Python forever, and they'd rather get it out of the way, and it's fine.
It's not my way of working, but it's fine for people who want to do that.
But if you're working with somebody who might not be a full-time developer, but they want to use your framework, your service to build some app, it seems like this could really empower them.
But if you give them something with zero autocomplete, zero highlighting, you're going to be having a rough time, you know?
Yeah, even for a more experienced developer, I think it's still a hard time.
Even if you can do it, it's just less productive to go like, oh, yeah.
Way less productive.
Yeah, way less productive.
I think AI gets added to apps a lot just to kind of check a box, but the result of it is not that great.
To get on my email client that has AI integrated, but it almost always seems like, well, that's not something I'd, yeah, something I want to read.
Like, I don't really want to read that, and I don't need to summarize it.
It's not emails, you know?
It just seems like a lot of energy goes into it when it's not that big of a value.
But maybe something like Copilot could be here.
This is something we've talked about, me and my co-founder.
So one of the things that we didn't get to cover, because we're not going to go through all the demos, but the way that we render data in these tables is we basically format it as a pandas data frame.
Okay.
So what that means is that, let's say that you query data from Stripe, right?
Like you get all your customers from Stripe.
Stripe is not going to return a data frame for you.
It's going to return like an object, right?
A dictionary.
And then you basically have to take that dictionary and then basically convert it into a data frame.
And then we automatically know how to render everything else from there.
So we've thought about this.
And like, wouldn't it be cool if as soon as you get the response from an endpoint, let's say as a JSON dictionary, that we suggest that we can just take it at next step for you, which is just to like convert it into a data frame.
And then you wouldn't have to hustle with it.
Yeah.
We've done that with it.
But in theory, that sounds very, very helpful.
If you're proficient in pandas and using data frames,
it's actually not that hard.
It's a very quick thing for you.
But if you just know Python but not exposed
to the whole data frame ecosystem,
then maybe it would be really nice if you just said, OK,
we just started to data frame for you,
and then that's all you have to care about.
So we've thought about this.
We haven't added this yet.
MARK MANDEL: I think it's fine without.
But it's kind of one of those things,
like you're in there, and you've got these data sources,
and maybe you're not super familiar with them.
Maybe you can pull them together somehow.
One of the things that I find myself struggling with
is, let's say I want to build a demo.
Let's say I haven't been exposed to the SendGrid API
or the HubSpot API.
Then I have to go to their documentation
to figure out what's the package name so I can install it.
How do I authenticate in?
How do I call a few endpoints to do what I need to do?
And I think in that case where it's
not about your knowledge of Python,
it really is about your knowledge of this other thing
that you're using.
In those cases, it seems that it could be extremely helpful for someone to build apps very quickly
if they somehow had access to either quick documentation or you just suggested what you might want to do.
MARK MANDEL: Yeah, that's kind of what I was thinking as well.
If you're a regular listener of the podcast, you surely heard about Talk Python's online courses.
But have you had a chance to try them out?
No matter the level you're looking for, we have a course for you.
Our Python for Absolute Beginners is like an introduction to Python plus that first year computer science course that you never took.
Our data-driven web app courses build a full PyPI.org clone along with you right on the screen.
And we even have a few courses to dip your toe in with.
See what we have to offer at training.talkpython.fm or just click the link in your podcast player.
MARK MANDEL: So speaking of that sort of external resources, you've got this Python function.
And what can I put in there?
Can I use external packages?
Can I call out on the network to talk to some API endpoints?
Can I spin up threads?
Like what can I do?
How much Python can I do there?
MARK MANDEL: Pretty much all of the above.
MARK MANDEL: So I'll elaborate what I mean by that.
So the standard way that you would connect to some of these services, these third party services, is you'll make like an HTTP request.
Like get requests, post requests.
So you can just like import requests, basically.
PIP install requests and then just do it over the standard Python, basically Python package.
Now, it is way more convenient when you use an SDK provided by one of these third parties.
So if you want to use Stripe, if you're able to just import Stripe, it'll make your life
a lot easier, very nicely, Pythonic, everything set up.
So in DropBase, you can install anything that you can install via PyPI.
We have a file called custom requirements.
And if you just list them out, when you set up DropBase, we'll basically install all those for you.
And then when you write a function, you can just basically import Stripe directly in the function
without pip installing it again, and then you just use it.
So that's really nice.
But basically anything.
I think you were doing a previous UV.
You were talking.
Yeah, yeah.
I was talking to Charlie Marsh about UV earlier today.
Yeah.
We haven't looked into it yet.
But anything you can pip install from PyPI, you can install in DropBase, which makes it really,
really powerful.
Yeah, nice.
There's a database connections.
I mean, you could use SQLAlchemy or you can import whatever else you want.
But we make those a bit more native because we know that you're going to connect to databases.
So we want to make it a bit more convenient.
So.
And your tables need sort of direct access to it as well, right?
Not just the output of some access to the database, but you've got to figure out the columns and all that kind of stuff, right?
That's correct.
So we created a little library, like a utility slash helper that lets you perform database operations very quickly.
So if you've added your database credentials to the .env file, then you can quickly perform, you know, like a select statement or, you know, make an update to that database via functions.
But without, you know, the standard thing where you do, if you use SQLAlchemy, for example, where you like start a session, start a connection, you know, like all those steps, we kind of abstract that for you.
But you can totally use SQLAlchemy in its full glory if you, you know, if that's what you're used to.
Nice. Can I write Python files, like separate Python scripts and stuff, and then just import and call them from there?
Or does it have to be done through the UI?
Totally.
Yeah.
There's actually one of the biggest advantages of DropBase is that if you have like a Python script lying around and you want to sort of use it in DropBase, you can add it to that file system somewhere in the workspace directory.
And you can just import it in via your function.
So you just like from your file, you can import a specific function in that file, for example.
And so the implication of this is that you can set up DropBase in a way that it just lives in your existing Python code base.
So imagine you're already, you know, you've set up your company, you've got product market fit, you know, things are running, right?
And you have a Python backend.
And now you're starting to scale and you need to build tools.
So your first option would be to do all custom, obviously.
The second option is to use some sort of tools builder.
But every single action you take is done over an HTTP request with authentication, with everything.
So just like a standard internet communication.
But if you wanted to just interact with an existing functions or internal endpoints, then you'd have to either set up an RPC server or you might want to use some other way to get in there.
DropBase, you basically just set up DropBase in the same directory as your app.
And you can then import selectively what functions you need.
It's sort of like a window into your code base that it's like a plug into that code base where you can now expand and build a lot of internal tools that leverages everything that you've already built.
Yeah.
That's it, by the way.
Yeah.
When you've got, yeah, there's the requirements at custom, right?
So you've got your Docker compose file.
I mean, could you set it up just so as you build, maybe even better, just set up a volume so that it can directly find.
I mean, I guess that's what you're kind of showing right here, right?
Is that you can sort of map, mount a volume just directly into, say, your Git repo for your big project code.
And then you can just start importing that and doing stuff with it, right?
We still need to do some tweaks because of the relative paths.
But the idea is that you can do that with a little bit of customization.
But yeah, our workspace server, basically, you mount files or directories, and then we can look into those to execute.
Yeah, manage those files with Git or something like that.
A good example of this is, are you familiar with Django and Django Admin?
Not super, as I do every day, but I'm aware, sure.
Django, it's a great web framework.
It's used by a lot of companies.
It's like, if you want to build web apps, you have Django.
It comes with a lot of stuff, right?
And there's this thing called Django Admin that basically automatically generates admin panels for you based on your Django models.
And so if you have a model for a book, right?
And the book has authors.
It basically exposes that to the Django admin.
And then now you can edit a book without really doing anything.
It all kind of comes for free.
It's pretty neat.
I think that's half the appeal of Django right there.
It is.
Yeah, I think a lot of people use it for that.
Yeah, they're like, I don't want to write that stuff.
I'm using Django.
Yeah, for real.
And it's great.
Now, at some point, when your company hits a certain milestone or a certain number of customers, you will need to customize those admin panels.
You might need to create admin panels for things that maybe you don't have models for yet.
Or for things that combine data from your database with data from like Stripe or some other source.
And so what we see when we talk to these people is that they kind of struggle to like either do I like keep using this or do I like completely rebuild everything?
For those users, when we talk to them about DropBase, they get very excited because with DropBase, you can install Django and it can sit in your file system.
And so essentially all the models that you've already built in Django, you can basically call them via DropBase, with DropBase function because it's all Python, right?
And so it gives you this like, okay, Django admins are great up to a certain point.
And then after that, what happens, right?
Like you might not want to rebuild everything just so you can have internal tooling.
And so I think that's quite of a nice spot for us to say, look, DropBase can live in your code base, uses everything you already have, but it gives you some extra things if you want to build internal tools very quickly.
So that's something we're obviously very, very excited about.
That's really cool.
I like that aspect of it.
So when we talk about this code, I guess there's two scenarios, the cloud version or the self-hosted version.
But where and how does this Python run?
Is it, it must be full CPython?
Is it running in isolated Docker containers?
Or in your cloud, what happens?
Is it functions like AWS functions, Lambda?
It just runs either on your local machine, if you've set it up as a developer.
It's all running there.
Obviously, if you turn off your machine, you can use your apps.
And then if you set it up in a production instance, let's say you deploy this on an EC2, your Python functions are running on that EC2.
But it's running via Docker container inside.
So it gets a little isolation, a little bit of protection, that kind of stuff.
And we're assuming that, I mean, you're building these apps to run on your own infrastructure.
It's that you would, that you know what you're doing.
So this is as opposed to us having a full cloud version where all customers run untrusted code in the same sort of backend system, which would be obviously very dangerous because I'm sure there's ways a customer can somehow, you know, go through the backend and access other customers' untrusted code.
And that would be a nightmare.
And so if, you know, we have isolation, first layer is, well, it's in your infrastructure you're going to do.
It's just your company's code.
But then further, you know, we run Python in containers in that instance.
That sounds more like a durability thing than anything.
I mean, it is also for isolation protection.
But first and foremost, just don't let bad Python code take down the whole thing, you know?
The way we recommend people using DropBase or setting up their dev sort of process with DropBase is that they would clone, basically fork the for DropBase.
And then they will develop locally.
They will test changes.
And once they're happy with the new code, you know, they'll push it back.
And then they will have CICD into the production instance.
And then they can version control everything.
So that also gives you that extra layer of, okay, let's make sure that whatever we're pushing is tested.
You can always add test databases that you develop locally with before you push the production, where it's going to have to act on your production data.
Yeah, that's pretty interesting.
I like the version control aspect of it.
That gives it a much nicer touch to connection to real software rather than just it's a text input area in an app that who knows what happens.
As developers, it sometimes feels a bit scary, right?
Like you're building something and it's in this other framework and this other cloud.
And it just feels like you can't kind of get, like if the thing goes away, like you can't even see your previous code.
That was another key concept that we wanted to have is in this tool that it feels friendly for developers, that it matches your mental models and your sort of like your development process, let's call it.
Like how you're used to making apps or developing code, that we keep that feeling when you're building apps for a trial phase.
I want to maybe have a PR to understand if we accept this change to it, right?
That's right.
Yeah.
You don't normally hear that kind of stuff around these kind of tools, you know?
And if you do, I think it tends to be like, yeah, okay, it's like a huge enterprise contract, you know, pay us $50,000 a year and then you get version control, which to me, it sounds scary.
I mean, it just, it will make me a little bit less comfortable.
Now, obviously, if I'm a big company and I just really need the tool, sure, maybe I'll just pay for it and I get version control.
But, you know, getting version control, it just feels so like, like table stakes for developers, especially today.
But yeah, it just wouldn't make sense otherwise for us.
I mean, it's the way we're approaching this product.
Yeah.
Well, the other aspect is, you know, what are you version controlling?
You know, do you end up with, you know, something like effectively a Jupyter Notebook, like big blob of something.
And then there's an older blob of something and then you diff it.
You're like, what is this?
But since you end up with just these, you know, your workspace files that just live there, right?
It's a real optimized, like, show me the changes.
Show me what's happened here.
Yeah.
It all lives there, including the component properties.
Like we don't store this in like a separate database or anything like that.
So like, you know, like for some of their tools, they will store all the components in their database.
And so what they do is, you know, when you load up their tools, like their tools builder, it'll fetch all the components from the provider's database, combine it with maybe your custom code, and then it'll do it.
And so even that feels like, okay, but where's like config for my components?
Yeah.
Where'd this button come from?
Why is it gone?
That's tough.
Yeah.
That's tough.
And then like, imagine if you wanted to like share their apps or, you know, it's just like version control makes a bit less sense.
I mean, you're just version controlling, just like the individual functions, maybe like the custom part of the code that you write, which is still useful, but it still feels like you don't have the full picture of what's happening.
Yeah.
You don't have a full record.
It could easily get out of sync.
Yeah.
Quite interesting.
I guess one thing we touched on a little bit before I press go here in the show, you said that at one point you were considering using Jupyter in this whole mechanism.
Yeah.
What's the story around that?
We love Jupyter.
We love notebooks.
And we love the experience of them.
The sense that you can write some code and you can quickly test and execute the code without, basically without, without needing to write anything else.
So for prototyping, for getting quick feedback, it's great.
And we wanted to give our developers something like that, because when you build these apps, you're kind of iterating, right?
You're like, you're testing it.
A lot of times you don't even know the documentation for Drive or HubSpot or, and so like there's a lot of experimentation.
And so we wanted a quick way to do that.
So we considered maybe having something like a Jupyter kernel within DropBase that allowed people to do it.
There were some issues with it in the sense that the kernel actually stores results from like previous blocks.
And sometimes that gets in the way of you triggering an action in a later block.
And so we were like, okay, maybe that's a little bit more than we need.
Now, we still kind of eventually want something like that.
We hacked it in a way.
Like, so the way that we do it is you can write a Python function.
You basically get one block.
You can write a Python function and you can click on a play button to basically run that function.
But it's not like a kernel.
So what we do is behind the scenes, we have like a main function.
And when you trigger that function, we take the state from the client.
So whatever you've selected or input it, we take the underlying file for your Python function.
And then we call it from me.
And so we kind of simulate that experience of like instantly testing code that you just wrote.
But there is no Jupyter kernel behind the scenes.
And then you can only do one block at a time.
And so we said, okay, for now, as we're getting started with it, it's good enough.
You can write your functions.
You can run and test them immediately, which is really nice.
You can do this with VS Code, by the way.
Like you would have to open up the terminal and then basically run your function.
And so we still wanted this feature where you can click and just see your outputs and basically debug and troubleshoot.
But it would be really nice if you could get out multiple blocks and you can just build functions that way.
So maybe for the future.
Interesting.
Did you say that you were a core developer for Jupyter?
No, no.
I just spoke to them.
It sounds fun.
I interviewed a whole bunch of them recently.
And what I thought was interesting is Jupyter is such an empowering thing for Python developers.
But many of the core developers are so focused on writing JavaScript and TypeScript to sort of make these interactions possible so that the rest of us don't have to write JavaScript and that kind of stuff.
So I think we're getting about to the end of our time here.
I'm sure that actually this is somewhat similar.
It's really a dynamic interactive web app.
And in that case, it probably has to have some interesting front end JavaScript stuff going on.
What's the JavaScript story?
Yeah.
What framework are you using and stuff like that?
We just react to build our components.
Obviously, we abstract that away so that you as a Python developer, you're just writing Python.
Well, you're writing SQL as well.
But let's call that Python.
And then we deal with the components for you.
And so it's not the kind of framework where you're writing Python and we're generating HTMLX or something like that.
So obviously, we understand React.
And we know we can build some beautiful components, customize them with it.
We weren't about to create a completely new framework where we somehow just generate HTML from Python.
I think there's a few people working on that, actually.
We already know React, so let's just build those components or customize those components and then just let people declare them and then sort of access and modify them via the context objects in your Python functions.
So our stack, we use FastAPI for our backend, which is great.
It's excellent, yeah.
I'm not sure if you've had the creator here.
Yeah, I've had Sebastian on, I think, at least three times, Sebastian Ramirez.
Yeah, he's great.
Yeah, he is really great, yeah.
FastAPI is a fantastic app.
And so, yeah, we use them.
We use React or our client side.
And we are a lot of our infras on AWS.
Yeah, sounds really interesting.
Sounds like a fun app to work on.
Yeah, you should play around with it.
I can help you build some apps to manage your podcast library.
All right, well, Jimmy, I think we are pretty much out of time.
Final thought for people listening.
Maybe they're excited to try this out.
What are you telling them?
Yeah, just go to droppace.io and sign up for a free account.
It's free for developers.
You can set it up locally.
If you have any issues setting it up, just reach out.
I'll personally help you get it up and running.
Yeah, you can look at the documentation for everything else.
Yeah.
Let's find it.
Try it.
Give us some feedback.
We'd love to hear from you.
Awesome.
Congrats on building a cool project for people.
And yeah, good luck with it.
Thanks, Michael.
This has been another episode of Talk Python to Me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
Mailtrap, an email delivery platform that developers love.
Try for free at mailtrap.io.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
We'll see you next time.