The Python Podcast.__init__

Share on social media:

[00:00:12] Unknown:

Hello, and welcome to podcast.init,   the podcast about Python and the people who make it great.   When you're ready to launch your next app or you want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode. With 200 gigabit private networking,   scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you've got everything you need to scale up.   And for your tasks that need fast computation, such as training machine learning models or running your CI pipelines, they just launched dedicated CPU instances.   In addition to that, they just launched a new data center in Toronto, and they've got 1 opening in Mumbai at the end of 2019.  

Go to python podcast.com/linode,   that's   l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of the show.   And to keep track of how your team is progressing on building new features and squashing bugs, you need a project management system that can keep up with you that's designed by software engineers for software engineers.   Clubhouse lets you craft a workflow that fits your style, including per team tasks, cross project epics, a large suite of pre built integrations, and a simple API for crafting your own.   With such an intuitive tool, it's easy to make sure that everyone in the business is on the same page.  

Podcast.init   listeners get 2 months free on any plan by going to python podcast.com/clubhouse   today and signing up for a free trial. You listen to this show to learn and stay up to date with the ways that Python is being used, including the latest in machine learning and data analysis.   For even more opportunities to meet, listen, and learn from your peers, you don't want to miss out on this year's conference season.   We have partnered with organizations such as O'Reilly Media, Dataversity,   and the Open Data Science Conference.   Coming up this fall is the combined events of Graph Forum and the Data Architecture Summit.  

The agendas have already been announced, and super early bird registration is available until July 26th where you can get up to $300   off,   or the early bird pricing for $200 off is available through August 30th.   Use the code b mllc   to get an additional 10% off any pass when you register.   Go to python podcast.com/conferences   to learn more about this and the other conferences and take advantage of our partner discounts when you register.   And, also, the Python Software Foundation is the lifeblood of the community, supporting all of us who want to run workshops and conferences, run development spritz or meetups, and they also ensure that PyCon is a success every year.   They've extended the deadline for their 2019 fundraiser until June 30th, and they need help to make sure they reach their goal.  

Go to python podcast.com/ps   f 2019 today to make a donation.   And if you're listening to this show after June 30, 2019, then consider making a donation anyway.   And you can visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, read the show notes, and get in touch. And if you have any questions, comments, or suggestions, I'd love to hear them.   And to help other people find the show, please leave a review on iTunes and tell your friends and coworkers.  

[00:03:22] Unknown:

Your host as usual is Tobias Macy. And today, I'm interviewing Meredydd Luff about Anvil, a platform for building full stack web applications entirely in Python. So, Meredydd, could you start by introducing yourself?  

[00:03:34] Unknown:

Oh, yeah. Hi, Tobias. Thanks for having me.   So my name is Meredydd.   I'm from Cambridge in the UK.   And for the last few years, I suppose,   my primary identity has been I run Anvil, a search tool for building full stack web apps with nothing but Python. And do you remember how you first got introduced to Python? So this is a odd confession this early in a Python focused podcast, but   Python wasn't like a central language for me initially.   So Anvil originally started when   a friend and I, Ian Davis, my cofounder with whom I who I've known for years years,   we we did our PhDs, together at Cambridge, and   we spent a lot of time grousing about web development.  

And there's a lot to grouse about at web development,   and I'm sure I'll get around to that later. But eventually, we decided to, stop browsing and actually spend some of our project time   building something we thought would be better.   And   so we were looking at this tangle of applications, you know, other languages and frameworks.   And, I mean, if you think about the web, it's ridiculous. Right? The sort of   the   entry requirement   for building a web application is HTML, CSS, JavaScript,   something on the server side, maybe Python, maybe Ruby, maybe something else, SQL for your database. That's 5 different programming languages just to get started. And then you've got a framework for pretty much all of those. Right? You've got something like,   React for JavaScript and Bootstrap for CSS and maybe Redux for JavaScript as well. And then maybe something like Django or Flask for the Python, maybe some SQLAlchemy   for the for the database.  

And we were looking at that going, well, hang on a sec.   Back in the 19 nineties, right, when when we started programming,   you could pick up a tool like Visual Basic or Delphi, and 1 language   would be enough   to not just 1 language, in fact, but just being able to program a bit would be enough to build a whole application that works the same as every other application on your desktop. In in those days, that was Windows desktop apps.   And these days, the bar for doing that is so much higher, and, you know, none of that's like okay. Some of it is, but most of it is not inherent complexity.   It's incidental complexity. It's accidental. It's not nothing   none of the complexity you're dealing with is really necessary to express the application you want. And we thought   that's something we should bring to the web.  

And so   the moment we thought of that,   that's   really where we thought, well, okay, we're going to want to unify this in 1 language, because 1 of the problems is all these languages coming out of your ears. What will be the obvious language? And we very quickly decided on Python, even though it wasn't   either our primary language at that point,   because it was   so obviously best suited to the task. It is   so approachable to people who are   used to different languages. It's the world's favorite,   first language,   and it's if you're trying   to reduce complexity, then, like, picking a language that prioritizes   simplicity and readability   was an obvious choice.  

So that's the point where we actually really got into Python. Ian likes to joke that I learned Python by hacking on a compiler for it, which isn't quite accurate, but it's not a 1000000 miles off the truth.  

[00:06:55] Unknown:

It's always interesting to Start trying to learn a new concept   or technology   by going from the bottom up instead of the top down. So  

[00:07:05] Unknown:

that's it's it's Yeah. I tangled with Python before a little bit. So I I vaguely knew what, I was doing, but yes, that was enormously fun. And so  

[00:07:14] Unknown:

can you talk a bit more about what Anvil itself is at this point? And, you've already shared a bit of the story about how it got started, but maybe some more of the actual web  

[00:07:30] Unknown:

based development web based development environment, so an IDE where you can build applications in your browser with,   buff Python. And then it's a run hosting runtime environment where you can,   deploy them. So the idea is instead of instead of the normal web stack where you have, you know, your data starts as rows in the database, then you have to turn that into   model, you know, model objects on the server, and then you turn that into, like, JSON over HTTP, and you turn that into JavaScript objects, and you turn that into HTML DOM, and you turn that into pixels.   We wanted a unified representation. So it's Python objects everywhere. It's Python code everywhere.  

Everywhere. So if you use Anvil, you pull up Anvil dot works, you open up the IDE, you use a drag and drop designer to design your user interface.   And then if you double click a button or something similar,   you're then editing Python code that runs in the browser when the user opens your app. And then with 1 function call, you can get to Python code running on the server, so posted in a serverless environment by us.   And that is how you build your application.   So   instead of all these different   forms for your data to be in, your data is in Python objects being manipulated by Python code right the way through. And then, of course, 1 click, deployment, and your app is live on the Internet.   So   the impetus behind creation, as I mentioned earlier, was   Visual Basic and Delphi   and similar environments, there were tons of them, allowed you to get from 0 to a working application with, you know, sometimes with only a bit of programming knowledge. Sometimes you'd know knew a lot of programming, but you were just in a hurry.  

And we really wanted to replicate that experience.   So the idea really started,   shortly after Ian and I finished our PhDs. He his PhD is in human computer interaction. Mine is in usable programming systems. So we had spent a significant amount of time griping about, web usability.   And,   at a certain point,   we just said thing that needs to exist, visual basic for the web. And we started it as a kind of hobby project in, like, evenings and weekends   on the basis that, you know, even if nothing else came of it, this is a thing that it will be totally worth us building and putting out there because we would use it even if nobody else would. And then,   after, you know, several months of development, I think over a year, we finally put up a a link to it on Reddit and discovered that we were not the only ones out there who were very enthusiastic about this. And then from that point, we went, okay. Hey. This is a real thing now. We should make a proper go of this. And so we went full time on the project, and,  

[00:10:05] Unknown:

we have been ever since, really. And so for the initial development period,   were you just doing it sort of nights and weekends in addition to whatever you're doing as full time work, or did you have sort of a  

[00:10:18] Unknown:

seed amount of money that you could use to support yourselves while you were getting this off the ground? We are incredibly lucky to be entirely bootstrapped, actually. So, we didn't have to go getting, you know, getting seed money or permission from anybody to do it. It was just, as you say, nights and weekends.   I   was consulting at the time, and so I just took myself down to 4, then 3, then 3, then 1 days a week. Ian was working as a postdoc at the university,   which is a very flexible thing, and he just went down to 4 days a week on that. The company is actually called the Tuesday project because it was always Tuesdays that we met up to work on it. And even when it wasn't a Tuesday, we just we relabeled   whichever day it was to be Tuesday for the purposes of scheduling.  



[00:11:05] Unknown:

That's an interesting little tidbit of background information.  

[00:11:08] Unknown:

Yeah. And so we we worked up, and it was   it was great, honestly, having a cushion like that. I mean, it's sort of both hackney to say and somehow underappreciated   that   there's there are very few fields in which you can do that. I mean, spinning something like this out of thin air in   in nights and weekends   is possible. We are extremely lucky as a profession as a whole that this is an option. And I am personally extremely grateful that we didn't have to go do a song and dance to investors. We could sort of slowly and methodically build something that we thought was technically right before we started doing the,   sprint to customers pivot pivot sort of thing.  



[00:11:47] Unknown:

And so in terms of the early launch of Anvil, you mentioned that you posted it on Reddit, but I'm curious what the sort of early days of users coming onto the system looked like both  

[00:12:07] Unknown:

we reconsidered as you continued to build and grow the product? Absolutely. So when we first put it out there, we had,   you know, we had some ideas.   We thought, well, this would be a platform for simplicity.   And we,   you know, we we the thing we put out there was the smallest thing we thought was even slightly usable. And we very, very rapidly learned what the biggest missing things were. And, I mean, honestly, when we put it up on Reddit, just to be clear, like, this is a point that I don't think there was even a payment page. Right? There was a sort of free for noncommercial use. Contact us if you want the if you want to use this commercially. Sort of that level of maturity. We are not talking a polished product. But   so in the original in car incarnation, when we were first, let's say, playing with this in nights and weekends, we were thinking that   the biggest problem was   in the front end. And, you know, that actually,   if we sort of built something that people,   design their UIs without writing HTML   and write front end behavioral code without having to write JavaScript and communicate with server side code,   without having to deal with HTTP and REST and mashing everything is adjacent on the way. We thought that would be the big problem. We actually discovered that there was still a whole bunch of unsold stuff on the server side. We originally   shipped Anvil with, like,   a built in ability to, like, like, to to back your applications off like Google Sheets because we were thinking, okay, databases are too complicated, but, you know, you should be able to at least read and write spreadsheets.  

And if you, you know,   if you're beyond that, then you'll know how to use databases. And, 1 of the things we very rapidly discovered is, in fact, that's not true. And there was a quite a craving for, you know, okay. So how do I how do I set up a real database? Oh, you mean I have to go to RDS and,   yeah, to start up a virtual machine and put Postgres on it and, you know,   the we realized that that was much causing people in the wild   much more pain than we thought it was. And so I think that was the biggest thing. It was realizing that there were back end headaches to solve as well as front end ones. And that was basically so we we put it we put it up on Reddit in, I   think it was May of 2016,   and   we did get   some customers. And this is something that I I've been involved in a couple of startups. And this is a,   this is 1 of those merciful things the universe sometimes does to you. We picked up very quickly a couple of really great customers who are exactly who we thought,   you know, would benefit from Anvil Just to slight just to give us a little bit of encouragement to show that, sure enough, this was possible. And, yeah, they were paying us some tiny number of bucks per month. And then   after that, it was, you know, a long fallow period because we, you know, we were   engineers and researchers, and we had no idea how to, you know, get out there, get in front of people's faces, make some buzz.  

We just built something, and that little burst of interest we got we got once,   got us, you know, some, like, slow low trickle of,   Google traffic   and, like, 1 or 2 perfect customers to reassure us that we were onto something.   And then the next few months was a long slog of building a bunch of stuff that we knew we were desperately lacking. And I'd say, like, the the platform started to become I mean, I am I'm really astonished by the tenacity of some of those early users. Looking back now, how, you know, how much do we still have to do that they actually   that they stuck with it and were able to do such amazing things with it in sort of summer late 2016.  

But within a few months, we'd filled in the biggest gaps. And then we felt like we were okay. We were ready to sort   of go back to the well, if you if you like, and say, okay, this is actually,   we we've learned it was a good idea. Now it's usable.  

[00:15:55] Unknown:

So web applications in general come in a pretty wide range   of varieties and categories   from just a simple web form up to fully interactive immersive experiences   powered heavily with JavaScript.   And so I'm wondering what the primary format of web applications are that Anvil supports building   and the limitations   in terms of what is sort of easy to build because anything is possible,   but what is sort of easy and,  

[00:16:25] Unknown:

well trodden in terms of the formats of applications that Anvil is designed to help people build. So I should start by saying that, of course, you should be able to do everything with Anvil, and anything you can't do is a bug report. Frankly, the things it's not straightforward to do are bug reports too. Having said which, the the sort of the most common use case we see of Anvil is for single page applications. So you go to the application, it loads this,   there's Python code that runs in your browser,   and you sort of, you interact with that. So it's not like a page based paradigm. It's, you know, it's an application you open. So   it's not   specifically geared towards,   like, you know, a content driven   website. Right? You know, you wouldn't run BBC News website on it, but you would write a mail client in it, that kind of thing. As you've alluded to, a lot of applications do end up having having quite deep deeds of the the web API frameworks.  

So the web is an extremely deep and complex   development environment. Right? There is a lot to it. This is I mean, part of the problem of the complexity is there is so much to it. And Anvil is necessarily an abstraction   over the web. You know, we   take the web in all its complexity of all these different programming languages and all these different network protocols,   and we present you with a way of using this that is much less complicated. And the trade off to that is, of course, that abstraction is never going to be complete. You're you know, there's always going to be something that you can do with native JavaScript,   for example, that you can't do with Anvil. Or indeed, you know, something you can   do with certain pieces of server side code that you can't do in our serverless environment.  

We try very hard   to make sure there is always an escape hatch. So there's this happy path of, you know, all my components are Python. Everything was designed with a drag and drop signer. Everything runs in my serverless environment. But at each of those points, if you realize that you need something the abstraction doesn't give you, you can reach out and escape hatch and use the native underlying functionality. So for example, recently, right, somebody wanted to use Bokeh, I think it's pronounced,   the visualization library. And, you know, we don't have native support for that. We do have native support for plotly. You can just drag and drop it in, use the Python API. We don't have we don't have built in support for bucket. And if it were a closed system, that would be that would be the end of it. That would be you know, the answer is you you would would be you couldn't do that. But what you can do instead is drop down to JavaScript   and write some write a little piece of little bit of raw HTML and raw JavaScript,   and then plug that into your Python code, and then call into JavaScript from Python to create this walker visualization, and then wrap this up in custom component that appears in our toolbox just like the, you know, the labels and buttons and so on of the standard Anvil components. Just now there's bokeh plot next to it, and you can drag that onto your page. And then you can make that a, you know, reusable library so other people can use it. And that's the sort of example of of what happens. There's a a happy path you can do with nothing but Python. And then when you want something outside the abstraction,   the idea is that you can   reach down to the lower levels   of the stack, you know, manipulate the HTML and JavaScript directly, and then bundle that back up back up into a Python component that you or a colleague or somebody on the Internet you've never met can reuse,   and now they're staying on the happy path. And is there a particular  

[00:19:50] Unknown:

category or set of categories of users that tend to gravitate toward Anvil either in terms of their background or their needs or use cases?  

[00:19:59] Unknown:

So this is always a fun 1 because   actually, talking about the history, we spent a long time trying to guess, you know, what kind of category. And the answer is all sorts of people,   end up using Anvil for all sorts of things.   You know, we've got everybody from,   1 man bands,   starting start ups   to   I mean, startups that were started with Anvil and are now substantially larger than 1 person,   to big companies to building internal, like, business workflow apps,   you know, data scientists   doing visualizations.   It's honestly kind of difficult to pin down. But, yes, from from   literally the smallest to literally the biggest, companies on Earth have ended up using it, which is quite fun. The thing they tend to have in common, the people who've who are most enthusiastic about   it is they are Pythonists first. So, obviously, we get a bunch of data scientists   for whom this is an enabling tool that gives them superpowers. Right? And 1 of my favorite stories is actually 1 of our earlier you earliest users, 1 by the name of Colette Nataf, who started,   well, she was a data scientist by background, maths masters and all that, had been involved in marketing   and had an idea for an ad tech company, an algorithm for doing automate automated AB tests on your Google and Facebook ads.  

And   she actually had this working and up and outperforming,   the built in tools   and   was kind of stuck in consulting land because, you know, she'd have a client who would ask her to do a thing, and she would, you know, bring up the script on her laptop and point it at,   at that client's account and   do the ad optimization.   And   she needed   to have a user interface where clients could do this for themselves in order to become a scalable business.   And she looked at, you know, was going to find contractors. It was going to cost her, you know, the best part of a $100   to hire somebody   to build, like, the first MVP   of a web interface for her.  

And, of course, you know, everybody knows the first version of something is not the version you're eventually going to want to ship ship with. You know, you that was like she was going to have to take a whole random investment just to make that happen. And the crazy thing is, of course, that wasn't even the difficult part. Right? The data science was the difficult part. Machine learning was the difficult part. The web UI was, you know, just having a button that when you click did this thing. And   where there are we find there are a lot of people in that situation that actually,   they   need a web UI   on the front of something, but the something is much more important. And so, yes, she ended up finding Anvil. And instead of spending a $100 and grand and getting taking months to launch, she launched something within 3 weeks and was profitable within 4. And that's the kind of thing we really   we obviously really love to see,   but we do see a lot of people like that. So people with a Python background   or either a such as a scientific background or a hardware background.  



[00:22:52] Unknown:

And so given the wide variety of backgrounds   of the users that you're supporting, I'm curious how you approach overall user experience and usability   design in the platform to make sure that they don't run into any roadblocks in the process of trying to get something off the ground? That's a really interesting question because implicit in that question  

[00:23:15] Unknown:

is this idea   that   the web is so complicated,   you sort of have to have you know, if you're going to make it simpler, you're going to be putting, like, almost a kid friendly interface on it.   That, you know, this idea that the web is so complicated that any attempt to simplify it must lose so much that it's basically a toy. And   I   very, very loudly and emphatically disagree   with that premise.   The complexity   in building a web application   is, like, 95 to 99%   accidental complexity.   It's not necessary, and you don't lose any power or expressivity by taking it away. Again, you know, it's always there behind an escape hatch, but you don't lose any power by taking it away. And so it's not the case   that there is, you know, that there is a right interface for beginners and a right interface for for professionals.  

And I think 1 of the corrosive effects of the web being our primary programming platform, you know, for delivering applications today is that people have got into their heads that anything   real, quote, unquote, anything that can in fact be distributed to millions of people across the world must be built using a staggeringly complex technology stack.   And, you know, for most of   computing history, that was not   true.   Okay. Not for okay. Since, like, it back in the, you know, the 19 seventies, you needed to know a lockdown to the hardware to get anything done. But   certainly since, like,   the nineties, it did it   did not have to be that complicated to get something going. And,   I mean, really, we in the Python community should know this, right? We use a programming language that is the first thing that you teach,   you know, a 7 year old their first raspberry jam. If you don't know about those, those are great events run by the Raspberry Pi Foundation for kids. If you have a kid, find your low your nearest, they are great.  

But Python is also the programming language   used by DeepMind to beat the human brain at Go for the first time ever. And, like, we are sitting on top of living proof   that   a well designed system is accessible enough for novices and powerful enough for seasoned professionals. And it genuinely is just   how awful the web is from the usability perspective that has, like, brainwashed us into thinking that there must be beginner friendly and pro friendly interfaces to everything.   So the conclusion of that little rant is that   the variety of users   does not   especially   feed into   the API design   for how Amber is constructed.  

Our   goal is to make a good API,   and we firmly believe that   a good API for a, you know, component based user interface   is   accessible by beginners. And, you know, we have existence proof of this from 19 nineties.   And   if you design that well, that is not going to get in the way of the seasoned professionals either. So we don't really concentrate   so much on creating   APIs for novices and APIs for professionals.   We try to create a good programming environment   where the simple things are obvious.  

[00:26:36] Unknown:

And so for somebody who's interested in getting started with Anvil, can you talk through what a typical workflow looks like and is in the process of doing that, talk through the sort of implementation stack of Anvil itself and where it ties into those different touch points?  

[00:26:53] Unknown:

Sure. I think I'll probably go through those separately. So in terms of your workflow, if you're creating an Anvil app, you will start, you'll, you know, log in to the Anvil website.   You will open up the application builder. You will create a new application.   You'll then be faced   with a   visual designer   to design,   the user interface of your app and a toolbox on the side. And most likely, you will   design the first screen of your app by dragging and dropping, these components,   onto your page and then, you know, changing some of their properties. So, you know, each each component, like a text box or a button you drag onto the screen, you can then go down to the properties window and, you know, change things like its font size and its alignment and that kind of thing. You will then,   you you know, respond to an event. So when someone clicks on a button, at the bottom of the properties window is, you know, this button, what happens when it gets clicked.  

And you click on that, and   you're now you've now switched from the design   you're looking at to a code view, which is the code that runs behind that design. And every 1 of these pages, these forms we call them, again, VB heritage,   is a Python class.   And when you double clicked on that button, you created a new method in that Python class that was, you   know, my button click. And that's the code that gets executed   when the button gets clicked. And   in that code, you will you know, you'll do whatever user interface. You might do some validation. You might pop up a message. You might navigate from 1 page to another. But But if you want to do something on the server, you will make   a function call. So anvil.server.call.  

You'll specify the name of a server function. And then that's just a it's just like a Python function call. So you can pass arguments, you can pass keyword arguments,   and you can get return values from that call. So   to implement that server call, you'll create a server module, which is they're actually they're highlighted differently in the editor. Yeah. Yellow background for server code. And that's just a Python module that runs   on our servers in our serverless environment. And there, you you write ordinary Python code,   but you can define a function and just def something, and then you can decorate it with at an anvil.server.callable.  

And that says, this is 1 of those functions you can call with anvil.server.call   from the web browser. And so you you define a function, you drop this decorator on it,   and this function can do whatever, talk to databases, so on, return some values.   And then you can go, you can go back to a client code. You just call it like it as if it were a function call, any other function call in Python. That's really the core of it. You know, there is a there is a visual designer. There is code that runs in the browser. There's code that runs on the server. In practice, the first question everybody always asks is, okay,   as we discovered when we first put this thing on Reddit,   the first thing everybody asks is,   so how do I set how do I use a database? And, of course, you can, you know, spin something up, in spin a Postgres instance up in Amazon and then connect to it with Psycho PG 2 because, of course, it's just Python. Right? You've got all those libraries at your fingertips. But in practice, we'd we discovered   setting up databases   is,   a lot a bit of a pain. And so we actually have a built in built in database service you can just add to your app.  

This has, like,   again, a point and click interface for creating date creating tables,   and creating columns in those tables and so on. And there's actually a pure Python API for interacting with them. So you can go into your server code, and you just go sort of apptables.food.searchoraptables.food.addarow,   which has actually has a lot of advantages.   It means that we have a straight Python object based API, which is really cool because we've actually made it so you can return those Python objects. So you can a   server function, anvil.server.callable   function running on our servers can go look something up in the database and then return that database object. You know, whether it's like a search iterator   or a database row,   you can just return it to the client. You get it as the return value from envelope server.call   in in the web browser. And so you can do things like accessing and updating your database   directly from, like, the button click handlers in your code, because it's just a Python object that you return from a server function, and you can live update it. And this means that you don't have to plumb, like, every operation in your app   through   from you know, all the way from the front end through to the database.  

You can in fact return the database   row or a view of the database as a Python object from the server and interact with it on the cloud.   So that's what a typical,   very simple Anvil app will entail. Right? It's got some drag and drop designer on the on the front,   Python code running in the browser,   server code running in our infrastructure database, again, hosted by us built in,   and passing   database objects between client and server with these function calls   to implement whatever kind of,   storage or display you want to. And   the really cool thing about all of that is that because they're all just Python objects,   they're all in the same programming environment. Right?  

If you're a web developer, like, when was the last time   you were working with something that knew your database schema and was able to use that to provide auto completion in your front end code.   Right? It's basically impossible with a modern web stack because your database schema is designed in 1 programming language. You're reading it in something like Python. You're transmitting it over JSON,   you know, interpreting it in JavaScript and then chucking it into some framework that an autocomplete will have a very hard time understanding.   Whereas with Anvil, they are just Python objects, and our autocomplete can track them all the way from the database to the front end. So,   you get   all, again, all the luxuries we had in the 19 nineties. All the luxuries you're familiar with if you use PyCharm on a daily basis, you can actually use in a full stack web application. So, yes,   designer, front end code, back end code,   databases, objects you can pass back and forward, and it's all auto completed. How we implement that, which was your second question, is a lot of fun. So, obviously, the actual running in the browser and running on the server are very different environments in terms of implementation.  

So the the code you write in the browser is compiled to JavaScript   and executes that way.   The code in the server runs, you know,   in,   either a   sandbox,   for free users or a,   more capable,   full Python interpreter inside of Octaventainer, inside in a virtual machine, inside, you know, Ledline box   on our servers, and we just have an environment for far farming those out. The function calls from the client to the server,   they happen over a custom RPC mechanism over WebSockets. And the custom RPC mechanism is what lets us pass back and forth those rich Python objects like database rows. The   database itself is   backed by Postgres.  

It's, again, it's actually implemented   as a series of calls just like anvil.server.call   calls that are handled by, you know, the the central sort of   Anvil built in services.   So   but, of course, those are wrapped in   Python objects. So you can do things like accessing a database row with square brackets because, of course, that is just a a call to the dunder getitem function. So that's that's the sort of the the the skimmed   the skimmed view. Oh, I could talk a little bit more about the client side stuff.   So   all those components you've been dragging and dropping onto your page, so the buttons and the text boxes and so on, are actually they're Python objects. So if I want to, you know, change the text on a label, which is text component, or if I want to get the text that's in a text box, you just go self.textboxone.text.  

You know, it it's just a Python object with an attribute. And when you go and select that text box and scroll down the properties window in the visual designer, you're just editing the attributes of that Python object. And that's that's an example of what I mean about, you know,   that's an API design that is pretty accessible to someone who's just started. You, you know, if you know about Python objects, you understand they have attributes,   then self dot textboxone.text   will make perfect sense. But that is also a really good interface for driving things from an expert level because, of course, you can, you know, dynamically   create these objects and add them to your,   you know, and add them to containers on your form.  

The drag and drop designer is, of course, just   a short hand for all the ways that you could construct   your,   interface with code, which means that, again, by making them Python objects, they are direct manipulable.   You can drive them in all sorts of interesting ways, but   there's a drag and drop interface and easy way of using them. And those Python objects are, of course, they are implemented   because they have to be they are accessible   from this   Python that has been compiled into JavaScript.   They are implemented in JavaScript as part of our Android runtime   and made accessible via sort of foreign function interface into,   Sculpt, which is the Python to JavaScript compiler we use on the client. Yeah. I was going to ask about whether  

[00:36:06] Unknown:

you use a sort of ready readily available JavaScript transpiler   that's just PIP installable or if you were building something custom for your own purposes.   So I'm curious what your selection criteria was for determining,   sort of which path to go down and which library to use. So yeah. So we use,  

[00:36:26] Unknown:

Sculpt, which is an existing open source Python to JavaScript compiler.   There are, as you allude to, a few of these about actually,   a comparison of Python in the browser mechanisms,   for Python tips that you might want to put in the show notes.   Some of these Python environments,   they're meant as kind of drop in replacements for JavaScript. Right? If you look at something like Bryton, right, Bryton's big cell is that you can do script type equals text slash Python, and then you in your HTML, in angle brackets, and then you can write some Python in your web web page. And that's cool if you want to use Python instead of JavaScript, but it doesn't fundamentally   change   the paradigm of how you're using the web. Right? You are accessing the HTML DOM   the same as you do in JavaScript. Right? You know, you have a document object.  

And so it hasn't actually raised the level of abstraction. It's just swapped out a language from JavaScript to Python.   And we, you know, we were more wanted to be more ambitious than that   because that you know, those layers of abstraction   and the need to transform your data into 50 different forms between server and client is a large part of the problem. And so something like Brythen, although it is   absolutely awesome and you should totally check it out, doesn't actually solve that problem. And so we chose Sculpt because Sculpt was   a originally created for educational purposes.  

It deliberately it's not meant for as a JavaScript replacement. It's meant as a Python implementation you can use   in the browser   in JavaScript because, obviously, you know, you don't want again, because you don't want people who are learning Python for the first time to have to interact with HTML because that is   asking for a migraine. So   instead, it's   a Python interpreter   that you can then, you know, provide modules and objects for interacting with the outside world in whatever way you see fit.   And so   that's what we did. We, you know, we used a Python runtime environment,   and then we provided objects for, you know, components on the screen and so on that you could interact with,   so that we could provide a Pythonic interface   rather than writing Python but still having to wrangle   basically everything else as if you were JavaScript.  



[00:38:43] Unknown:

And on the server side, I'm curious what you've chosen for your technology stack there. And also, I know that particularly for the shared environments, you preinstall a number of additional Python dependencies that people can take advantage of. And so I'd also like to hear what your strategy is as far as managing version upgrades without breaking your customers' applications.  

[00:39:06] Unknown:

So on the server side,   we actually we use a a couple of technologies.   For free users, we use the PyPI sandbox because that is a very low cost sandboxing method, which means that we can support thousands of, free users.   For,   paid users,   we use   a, yeah, a full Python 3 or Python 2 interpreter   running,   say, inside yeah, isolated in a virtual machine. And for those, we we ship them with, as you say, like, a a default set of, set of libraries.   And those libraries do,   do we do update from time to time. We currently do run on, like, a standard a   a a standard requirements.txt   effectively.  

We don't   personalize those yet, although that is something that I'm looking forward to on the,   something I am looking forward to on the road map. But at the moment, there are just upgrades. And, you can, if you're a paid user,   sort of   ask me ask us to tell you, when something,   you know, when   certain of your dependencies that you need change.   We don't currently have a good, change management process for that yet, but that is something that is,   is on its way. So watch this space.  

[00:40:20] Unknown:

And so for the server side, I'm curious what the environment is that customers are using for   running their code there. So whether it's like a Flask app or a Django app under the covers, or if you have built some homegrown web framework for,   Anvil in order to be able to support the WebSocket communications   or,   what sort of combination of   technologies you're using to build that.  

[00:40:46] Unknown:

Right. So,   the code that's be you're writing on the server is absolutely not a Django or Flask or a standard web application.   The as I say, it's an it's a serverless environment where   the way to talk to the client is to expose atamble.server.callable,   functions.   So   what actually happens is that   when you open an an Anvil application in your browser,   that makes its WebSocket connection to a, like, a a piece of central routing infrastructure that we maintain.   And that says, oh, well, you know, that that request is for this app.   And, you know, it's not to 1 of our internal built in handlers. Therefore, it's going to be executing in the server side   Python environment.  

Therefore, route over there to that node, which is, you know, which is hosting a live server side environment for   that app. And so this is that part is all,   is custom. So what act what's actually running inside that VM   is a   is a custom Python environment that connects up to this, you know, this routing infrastructure   and,   distributes requests accordingly.   Having said which, you can, of course, build,   functions that responds directly to HTTP endpoints as well. So   you can interact with your Anvil app. Actually, as a more general point, you can interact with your Anvil app by many means other than just opening a web browser. Right? Obviously, that's the primary way that people   use many Anvil apps. But, you know, you can   put throw together an HTTP API. So you can make you can tag a function at anwell.server.http   endpoint instead of callable, and that says that's like a like a Flask root,   that will respond to certain HTTP requests to your app. You can also actually,   use something called the uplink, which I'm surprised I haven't mentioned sooner,   which is   is a way of hooking   a piece of code running on your computer or computer you control into,   the same, like, the same request for routing infrastructure. So what you do is you launch any Python environment on your computer. You know, maybe it's a standalone Python script running as a daemon, maybe it's inside a a Jupyter notebook, maybe it's just a REPL running on your machine,   and you   PIP install the Anvil uplink,   and then you go Anvil dot server dot connect with a key that is unique to your application.  

And when you do that,   your code,   wherever it's running, on your laptop or on your server, connects up to this central, you know, routing infrastructure.   And then you can, locally on your machine, create an anvil.server.callable   function   and call that from, you know, from the front end, from other server modules, and you're, you you   are there. You are executing. It's like part of your app. You know, you can from your own laptop, you can access the built in database with the same APIs you can from server server code. You can write HTTP endpoints. You can amble dot server dot call into the server infrastructure and so on. So, yeah, I'd   that's  

[00:43:46] Unknown:

significantly more powerful than the server side code just being a wrapped up Django app. And as far as building and growing the Anvil platform and company, I'm wondering what have been some of the biggest challenges that you faced in the process?  

[00:44:02] Unknown:

Oh, so, I mean, 1 of the biggest challenges is when you're building a develop it's just that it's so big. Right? When you're building a developer tool,   nobody wants something that that is half working. It needs to cover pretty much all the bases   before   it's usable for anything. So,   certainly, 1 of the biggest challenges was   building a platform this large from scratch,   and that was   why it was so great for us to build it slowly and not have this pressure of,   you know, seed funding that's going to run out. So that would be 1 of the biggest ones.   I'd say   the second biggest challenge   is sort of   getting the word out there and explaining it.  

Because   we go you we we met at PyCon just a couple of weeks ago. And   when we actually   show Anvil to people and see a demo, you know, our our booth gets piled 3 deep, and it's all very satisfying.   But   it is   it's a little bit like the matrix. You know? It is difficult to explain, easy to show. And so   our our biggest challenge is really   as always, I suppose, with programming, it is all about communication   and education   and communicating   what it's about and how to use it. Technical challenges, there have been,   lots, and they've been,   fun.  

I have 1 of my first,   significant externally visible acts as part of creating Anvil was modifying   the Python to JavaScript compiler sculpt we use. So I mentioned earlier that those aml.server.call   calls,   those are blocking calls. Right? You you can get   a return value from an aml.server.call,   which is really neat for writing idiomatic Python,   on the front end. It was really important. It turns out that that was not, natively supported   by, Sculpt when we started this,   because, of course, JavaScript is a non blocking language.   And so,   I had an enormous amount of fun   modifying the,   Sculpt compiler   to support producing blocking code and how that interacted with JavaScript. I actually gave a lightning talk at PyCon   2017   about that that I would love to send you a link to. But, ultimately,   there are lots more like that. But, ultimately,   the technical challenges   were,   as always,   nowhere near,   as much of a challenge as the human challenges.  

1 of the things that starting a startup as an engineer does is it takes you way outside your comfort zone because, of course, if you just stayed in your comfort zone cranking out software, you could create a marvel that nobody else sees. And there's,   fundamentally,   the good you do for the universe,  

[00:46:45] Unknown:

is sort of limited that way. And as far as just the overall features and capabilities of Anvil, I'm wondering what are some of the ones that are often either overlooked  

[00:46:56] Unknown:

or underused or misunderstood that you think users would benefit from knowing more about? So I've previously talked about the up uplink. I think that's a thing that is often difficult to communicate   without a demo. And then you sort of see a light bulb go on behind people's eyes. And they go, oh my god. That's exactly the thing I needed. We   say, we try to make   specific things not difficult to understand, but there is a lot of depth to Anvil. And if you sort of talk about all the depth upfront, then you will sort of necessarily overwhelm somebody. So   there's, you know, lots of little things in the background. Like, there there are whole features like, you know, the uplink or like the fact that you can create HTTP APIs   that we kind of don't hit you over the head with, as you first turn up because,   you're already taking in this idea that, wait. Hold on. I don't actually have to write HTML and CSS and JavaScript for everything. I can just drag and drop some Python components in. That's cool. So I think a lot of the   the the supporting infrastructure,   things that   you don't need until you need them and then you really need them. So, like, ability to respond to HTTP endpoints is a classic version of that. The uplink is a classic version of that. Some people never have to use it. Some people have, like, a sensitive database that absolutely must stay inside their corporate network, and they just need to be able to expose   function calls in their app that run queries against this database. And so I could, you know, I could I could list them all,   but part of the problem is that there are, that there are so many of them that you can't sort of list them all at people without their eyes going slightly glazed.  



[00:48:31] Unknown:

And   so as you mentioned, you have worked very hard to make sure that Anvil can be used from the smallest to the largest customer and that there are escape hatches to be able to reach outside of Anvil to be able to do things custom. But I'm wondering what the overall limitations are of the platform that you've built and when it would be the wrong choice for somebody. So right now I mean, this is this is obviously you're asking me for  

[00:48:58] Unknown:

this is a quite a painful question because, as I say,   anything that it's the wrong choice for is on some level a bug report. Nevertheless, right now, Anvil is not particularly useful for heavily real time applications.   We don't have a lot of, like, streaming   streaming to the browser support. Again, we have sort of designs for how to support that, but it's not implemented yet. As I say, like, content heavy websites. So   because Anvil is geared towards single page applications,   then   serving,   you know, serving like a a news website or a blog off Anvil is not currently very well aligned with what Anvil does. Those are the 2 examples that spring to mind. But as I say, everything that doesn't work in Anvil yet is a bug report that we will get around to fixing. And you mentioned a couple of times some of the ideas that you have for the road map. And I'm curious if you can talk through what you see as being the future of Anvil both from the technical and the business side. So   from the technical side, we try not to talk too much about the road map for the simple reason that you can sort of never win that way. If you say something is coming and then it's,   then it is late, then you've broken a promise. And   if you come up with, you know, something that's actually new and better and much more important and you do that instead, well, you ended up still breaking a promise, and that might overshadow you having done something cool. So we try to avoid giving too many hostages to fortune on the road map, certainly to people who don't have support contracts with us. On the business side though, there are, you know, if you if you look at it in the market, there are roughly 2 ways to sell software. You   can go out and convince all the people that might use your software that this will be really good and,   fun and stress relieving to use and will help them in their day to day lives and so on. Or you can go to their boss's boss's boss in a company and take them golfing. And the incentives that those 2 systems of selling software provide to the quality of the software that results,   they're legendary within the community. A lot of software, not all of it, but a lot of software that gets sold to bosses, bosses, bosses ends up not being   that fun to use because that's not what it's being optimized for. And so the biggest thing we are focused on, in the business is we do actually and it's a bit grandiose to say it, but it is actually ultimately what we're aiming for is we are trying to fix web development. And   if you just fix web development for the Fortune 100,   then   you have not in fact fixed web development.  

So we want to continue to remain   something that is   widely usable   by a developer who wants to throw something together and can pick up Anvil and just, you know, do it in an afternoon,  

[00:51:43] Unknown:

without talking to procurement first. And 1 thing that I didn't ask yet but that I'm curious about is how you ended up selecting the name for the business and the platform.  

[00:51:53] Unknown:

So an Anvil is a tool you find in a workshop.  

[00:51:57] Unknown:

It's something big. It's something solid, and you use it to build other things on top of it. Plus the domain name was free. And so are there any other aspects of Anvil or the work that you're trying to do to address some of the pain points and shortcomings of web development or anything else about the business or the technology that we didn't discuss that you'd like to cover before we close out the show? I think I've said a lot of what I want to say. I think web development is currently  

[00:52:25] Unknown:

conceived   is   it is massively liberating in some ways because   it has,   you know, compared with 20 years ago, it's   leveled the playing field. It's allowed   pretty much anybody to make an app that pretty much anybody else in the world can use.   And   that was a genuine good thing it did for us compared with what we had in 19 nineties. But   because it did that 1 thing, 1 really good thing for us, we have let it get away with a lot.   We've let it get away with being   hostile to beginners, frankly, hostile to experts.   And   I think we have become so used to the idea that anything full scale   requires   that level of complexity,   that we   flinch from anything trying to make it simpler because, you know, we're so used to this level of complexity   that we think that anything making it simpler must be turning it into some Fisher Price toy.  

And this is a legitimate fear. And you look at some of the systems out there that try to make this easier   and, you know, you can find a lot of enterprise drag and dropware that promises you can build applications without writing any code. And, sure, yes, that is   turning the web into a Fisher Price toy, but you don't have to do that.   You can   build something with an industrial strength programming language that keeps all the power that you enjoyed having   as a programmer and   takes away   the wrestling your data into 5 different formats and mashing it into JSON   and writing the same piece writing the same operation 5 times   just to build a basic application. And I've said it before and I'll say it again. We're Pythonists.  

We know that this is possible. We know that simplicity   does not mean lack of power.  

[00:54:16] Unknown:

And, yeah, we want to convince people that that is true for the web as well or rather to show them. And for anybody who does want to get in touch with you or follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the picks. And this week, I'm going to choose a project called PIPX that I started using recently, and it's a simple command line tool for being able to install   any sort of Python application or command line tool or binary   into a its own virtual environment and then it exposes it to your shell environment so that it makes it very easy to use some of these command line scripts,   you know, from your terminal without having to go through a lot of setup or   maintain different virtual environments or have it pollute your overall system packages.  

So   it's been very useful for me. So it's definitely worth a look if that's something that you have found yourself battling with. And so with that, I'll pass to you, Meredith. Do you have any picks this week? I'm going to have to choose Sculpt, the Python JavaScript compiler we use.  

[00:55:18] Unknown:

I'm sort of using it here as a synodosh for any of this, any of these, environments that allow you to write Python in the browser because I do think that it's a big step forward. And some of them are small steps in that they are adding   choice of choice of language from you know, adding choice of language in the browser instead of everyone being forced into JavaScript,   and some of them are really exciting   changes   to how   web development can be done. There's actually   I'll point you at the comparative   Python in the browser article, written by my colleague Sean because I think that's a really interesting overview   of where this space is going, and I think it is very exciting. And it just got more complicated too with WebAssembly   making it possible to have other languages running in your JavaScript runtime. Oh, yeah. Well, this is I mean, that that's the the real goal. Have you, seen Pyiodide,   which is this awesome   project   that just puts an entire,   full size Python data analysis environment into a web browser using WebAssembly.  

It is it it is beautiful.   And that's, yeah, that's the kind of power that,  

[00:56:26] Unknown:

I yeah. Really excited about what WebAssembly can do. Yeah. I've seen that come up, and, I've took taken a brief look, but haven't dug too deep into it. But I'll definitely add a link to the show notes for anybody who wants to take a look at that on their own. And   so I'd like to thank you for taking the time today to join me and talk about the work that you're doing at Anvil. It's definitely a very ambitious project, and it looks like you've been able to,   enjoy a good deal of success and add a lot of polish and usability to web development. So thank you for all of that, and I hope you enjoy the rest of your day. Thank you. Thank you very much for having me. It's been great talking to you.