The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to Podcast Dot in It, the podcast about Python and the people who make it great.   When you're ready to launch your next app or 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 the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform, including simple pricing, node balancers, 40 gigabit networking,   dedicated CPU and GPU instances, and worldwide data centers.  

Go to python podcast.com/linode,   that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show.   And do you want to get better at Python?   Now is an excellent time to take an online course.   Whether you're just learning Python or you're looking for deep dives on topics like APIs, memory management, async and await, and more, our friends at the Talk Python Training have a top notch course for you.   If you're just getting started, be sure to check out the Python for absolute beginners   course. It's like the 1st year of computer science that you never took compressed into 10 fun hours of Python coding and problem solving.  

Go to python podcast.com/talkpython   today and get 10% off the course that will help you find your next level. That's python podcast.com/talkpython.   And don't forget to thank them for supporting the show. Your host as usual is Tobias Macy. And today, I'm interviewing Meredith Bluff about the process and motivations for releasing the Anvil platform as open source. So, Meredydd, can you start by introducing yourself?  

[00:01:47] Unknown:

Hi. My name is Meredydd Bluff. I'm the founder of Anvil, most relevantly for this.  

[00:01:53] Unknown:

And do you remember how you first got introduced to Python?  

[00:01:56] Unknown:

I first encountered Python seriously   when I was doing my PhD   because while I was helping to lead a summer school   aimed at disadvantaged kids, giving them a sort of a taste of computer science and what computer science at university was like. And we used Python for that. And so I hadn't really   used it in anger before we started Anvil. It was a kind of arbitrary choice. I sort of knew it was out there, vaguely knew sort of, you know, what the language's values were,   but hadn't really, you know, picked it up and swung it around my head until now.  

[00:02:28] Unknown:

The topic of the conversation today is the Anvil platform and the work that you've done on it. And for folks who haven't listened to the previous episode that you were on where we dug deep into the platform, can you just give a quick overview about what it is and some of the story behind it?  

[00:02:42] Unknown:

Sure. So Anvil's a tool for building full stack web apps with nothing but Python. So you don't need to use HTML and JavaScript and CSS and all that stuff. You can in fact build your designer user interface with a drag and drop designer or built in code, write Python that runs in the web browser, Python runs on the server,   and then just deploy it if you're using our hosted service with 1 click or on your own machine, as we're gonna be talking about today. So the idea is to make web development more accessible, because   the web is   honestly a bit of a mess.  

The bar for you must be this tall to ride this ride is set at knowing   HTML and CSS and JavaScript,   something like Python on the back end and SQL for the database, and then like React and Redux and Bootstrap   and Flask and SQLAlchemy   and Webpack, and that's before you even get onto the DevOps.   And there is   no good reason to require people to be an expert in that many things,   to put something on the web that does something when you push a button. So my background, my PhD is in usable programming systems, my friend, Ian, who's my co founder, is in human computer interaction.   And we were acutely aware that if you rewind back as recently as the 90s, well, recently for some of us, you had these platforms like visual basic, where anybody who could program a little bit could put together an application that looked like everything else in your system, which in those days was Windows apps. And because that door was open,   you have   like secretaries   in their weekends building   mission critical apps for their companies that are still often in use today. Microsoft have committed to supporting Visual Basic Apps in like the 2030s, I think. Because once you have that door open,   people will build amazing things. And now   the path to building something that's like everything else you use, which these days means a web app, is so much expertise   that we're shutting off a lot of what people could create.  

You know, that goes for beginners.   It goes for people for whom programming isn't their   main professional skill set. You know, if you are an electrical engineer, but you need to build a tool, you're probably not   going to have the time and inclination to sit down and learn all this stuff, but you probably   can swing a little bit of Python somewhere.   Data science is huge here because   there's a   whole rapidly growing profession of people who are primarily, you know, statisticians and data people.   And they're not full stack web developers, but they run into situations all the time where they want to put, you know, user interface together   to for their colleagues to use or someone else can query a dataset. There are all these people who want to create things, and it feels like, you know, as time went on, the programming tools ought to have got more advanced, instead of which they've got harder to use. And so we said we took a look at that and went, this is ridiculous. It ought to be as   if the logic of your app is basically   5 Python statements in a for loop, you should be able to write those 5 Python statements in a for loop and deploy that as a web app. And that shouldn't be a radical idea. And in practice, what's had to happen, of course, is that   the existing web is really not that simple. So we've had to   build   a new abstraction for the web, a whole app platform,   cross compiling Python to JavaScript, building our own UI toolkit   to provide the level of simplicity that we wanted people to experience. But that's the platform. So it's available for free hosted at anvil. Works.  

You can check it   out, use the online builder.   And   as of quite recently,   earlier this year, in fact, once you've built something using our online builder, you can also   run the whole you can take an app and run it, host it on any computer you like because we have open sourced the actual app platform itself.  

[00:06:34] Unknown:

The last time we talked was a little over a year ago now where the episode went live in June. And I'm wondering if you can just give a bit of a summary besides just open sourcing the app platform.  

[00:06:52] Unknown:

Platform. That open sourcing the platform. That's a major change and something we're very excited about. But I mean,   thinking back to 2019   is definitely a different era   from here in late 2020. But I mean, all sorts.   We've kept adding features. Now, for example, you can use AML to generate PDFs, which is another of those pain points that people have all the time in Python. And   there's no reason that the standard way to generate a PDF in Python should be like generate an HTML page and then stick it through some headless browser renderer that you configure yourself and thereby expose yourself to like a ton of repeated security vulnerabilities? No.   So we've just like plugged a PDF render into our drag and drop designer. And now you can use Anvil to generate PDFs. The little things like integration with Microsoft authentication and other single sign on stuff   and a whole bunch of sort of fiddling around. Actually, since 2019, that was also the Python 3 transition.  

So   we had to upgrade the Sculpt Python to JavaScript compiler to support Python 3 syntax. And that transition feels a world away now. But yeah, lots happened in terms of the platform. And in terms of the company, I mean, we've more than doubled in size, which is quite nice. The men are now minority on the tech team, which is also quite fun. Yeah. It's been a bit of a  

[00:08:06] Unknown:

ride. Going back to the use cases, in particular, the use for data scientists where you mentioned them needing to be able to put things up on the web to be able to share their work with other colleagues or provide some means of getting user input for   populating a dataset. Another tool that has come up recently for fulfilling that use case is Streamlit. And I'm wondering if you've seen use cases for   integrating Streamlit into Anvil or what the sort of Venn diagram is between those tools and maybe some of the things that Streamlit doesn't solve for that Anvil is able to cover?  

[00:08:43] Unknown:

Yeah. Streamlit its itself is kind of an odd case. I put Streamlit into a category alongside   like Plotly Dash,   these ways of building fairly simple UIs on top of something that's   basically still a little scriptlet to deal with data. Something   we've really enjoyed seeing is people using Anvil to turn   something that they've done as a data scientist.   The classic thing that happens is that if you ask a data scientist a question,   they will come back with a Jupyter notebook that's the answer to that question.   And that's great if you just wanna copy and paste the graphs out of that into a PowerPoint deck.  

And it's great if the person receiving the notebook is also somebody who is happy singing Python around, but it's not so great if what you actually want is the ability to go back and run those queries again, or maybe they've prepared a model or a predictor, and now you want someone else to be able to query it.   And this is a pain that's acutely felt, which is why there are several people sort of reaching towards this use case.   Something that Anvil has that's kind of unique there is what we call the uplink. So   the uplink is an open source library. You can PIP install anywhere.  

You can give it an uplink key, and it will connect up to Anvil. It'll just make a WebSocket from the Python interpreter, wherever it is, up to Anvil.   And then your local Python interpreter inside your Jupyter notebook or wherever is like it's part of your Anvil app. So things like accessing our built in database, you can write functions in your Jupyter notebook and then call it as part of your app. And so something   we really enjoyed seeing is people using that for   deploying   something like a machine learning model or some   dataset   as a web application.  

And so unlike something   like the Jupyter widgets or Streamlit, which concentrate on taking something that's fundamentally   kind of notebook y, data science y shaped,   and putting sort of some basic UI on that, what we do is we say, okay, you've solved your problem in your notebook. You now need to deploy this, you need to enable other people to interact with it. You can keep it in your notebook, you can keep it exactly where it is, you just tag which functions you wanna be able to call. And then to actually build the UI and the app, go over here to this actual UI and app platform,   and then make the specific requests back into your notebook to query the model, say. And so I think it's a pretty different model to those systems. It allows you to plug   a notebook or interpreter running on your local machine or whatever, into a real app platform, rather than having kind of half an app platform on top of   your existing data science tools, which is   a kind of thing that often causes friction in model deployment.  



[00:11:30] Unknown:

And what are some of the other common or impressive ways that you've seen Anvil being used?  

[00:11:36] Unknown:

Right now, topically, the thing I am most impressed with is   probably   the Australian   public health COVID response, where their microbiological   diagnostic unit in Melbourne, which is the sort of the 1 of the big labs for the state of Victoria in Australia, which was obviously   recently had a very severe lockdown and managed to contain their outbreak, for which massive props to them. They have been rethinking   their   protocols for dealing with   disease samples and   sequencing   pathogens that come in and tracing their spread and, you know, tagging who caught it from whom, which cruise liner did this strain come from.   And they were working on this project anyway before the start of this year,   and they have turned around   and built   a bunch of incredibly impressive infrastructure   for   sharing this public health information across all of Australia and hopefully beyond in a very short space of time. So that's the thing I'm most impressed with in terms of its effect.  

We also see it used for internal tools. I don't think we published the podcast last time I spoke to you, but examples like, there's a TV network in Norway that needed help for the customer service people. So that thing that happens when you call up some customer service person and say, hey, I'm not receiving my cable   TV, and they say, tuck, tuck, tuck. Oh, yes, sir. I can see that your box is having trouble connecting to the Internet. Try moving it somewhere with better WiFi. And that is a perfect example of like it's a tool that the customer service people need to be looking at   to actually go in and ask a fairly complicated   sort of media delivery system   that question. Without that tool, they have to pester the engineers who are building their system and this was getting completely untenable for them. But of course,   a customer service person is not gonna be able to deal with like a command line Python tool or not reliably.  

And so what Anvil did was it enabled the broadcast engineers, again, not full stack web developers, but the broadcast engineers could build an interface on top of all of their broadcasting systems   that was able   to go quickly from   a customer number of a subscriber who was on the phone to diagnostic information   pulled straight out of the set top box in their living room, and that was really  

[00:13:52] Unknown:

cool. And so 1 of the key elements of the Anvil platform is this fact that you're able to   work end to end in 1 language without having to worry about these points of friction where you jump between Python and JavaScript   or from Python to SQL.   And the JavaScript community has worked to address that through the use of Node. Js, which has arguably had some level of success despite there being different APIs between Node and the browser, etcetera.   But how much of the overall adoption of Anvil do you attribute to the fact that you're using Sculpt and being able to   write pure Python in the browser? And how much of an additional learning curve is there for Python engineers to be able to   interact with the DOM API?  



[00:14:38] Unknown:

Here's the thing. In the Python community, we often love to rag on JavaScript, but JavaScript isn't really the problem.   The symptoms people ascribe to JavaScript, they are symptoms of the underlying problem. The underlying problem is think about a web application. If you've written web applications,   think about it from the perspective of a piece of your data. Your data probably starts out as rows in a database accessed by SQL.   You then pull them out and turn them into   Python objects accessed by methods and attributes on your server.   In a classic web application,   you'll immediately   turn around and convert those into JSON delivered for REST endpoints. So accessed over like lots and lots of nouns and tiny set of verbs,   which is quite a big transformation. And then on the other end of that is, of course,   a bunch of JavaScript code, which is pulling that data end endpoints and reconstituting it into JavaScript objects with a different set of attributes and a different set of methods.  

And then   you turn around and turn that into HTML DOM with a completely different API, you then style those into pixels. And like you have to do like 5 or 6 levels of transforming your data from   1 format to the other. And if you do web development, that is your day to day work,   is transforming data between different representations.   And that is   where the friction comes in. It's also where the complexity comes in because when you're doing tasks like that, you know, so repetitive,   you're tempted to use or invent frameworks.   So you end up with this proliferation of frameworks   that   are all kind of magic.  

It's like, you know, what we call the ORM problem. The way that objects in something like Python and rows in an SQL database,   they're kind of similar enough. You can kinda squish them together, but they're also different enough that if you're using a library like SQLAlchemy,   which is really cool. But if you're using it, you have these expressions,   prices less than 20 that aren't actually Python operators, they're like weird   SQL generators generating syntax in another programming language.   And in practice, to use them effectively, you need to know about Python   and SQL   and how SQLchemy works.  

And this is true at every level of stack. We have ORMs turning database rows into Python objects. We have REST frameworks helping us exposing those to expose those objects on REST endpoints. We have JavaScript frameworks helping us to, like, reassemble those   HP endpoints into objects.   And then template agents helping us turn those objects into DOM. And CSS frameworks taking up helping us turn those DOM into pixels. And   now you've just got this explosion of complexity of needing to know not only about every layer of that stack, but how the frameworks at every layer work. And that is why when you see 1 of these diagrams of like, you know, here are the things you need to know to be a basic full stack web developer, it makes your eyes hurt. And so it's not really about the language, it's not really about JavaScript, it's the fact that JavaScript is 1 of this chain of 5 different transformations   that your data has to go through. So   Anvil sort of isn't about   being able to run Python in the web browser, because there's loads of open source projects that let you do that. So like Sculpt, which is the compiler we use is 1 of them, you've got Python, you've got transcript, you've got Literally, a colleague of mine wrote a blog post comparing them all, actually, maybe we should link that in the show notes. That's not the problem. The problem that we set out to solve is your data goes through tons of different representations. And so what we did is create   an environment where   your data is Python objects right the way through. So you have this UI toolkit   that is   addressed in Python. You have a button that is a object of class button, and you want to change its text, you set its text attribute.  

Your server code is obviously in Python, but with your client in Python and your server side in Python, you don't need to mash everything through JSON on the way. You can just make a function call from your client to your server or indeed from a client to a Jupyter Notebook.   And similarly, we have a way of representing database rows as as Python objects. Although I have to say like the ORM is the framework in that stack that has the most excuse for existing. So lots of people use existing ORMs and that's okay. But the crucial thing is that it's 1 representation from top to bottom, all Python objects   throughout your app. And what that means is to answer the last bit of your question,   if you already know Python, the amount you need to know in order to be able to use Anvil is just Python because it's all just Python objects. And sure, you'll need to know you'll learn how our UI toolkit works, and hopefully, the drag and drop designer will be pretty good at teaching you.  

And you'll need to know how to make a function call from the client to server, but that's about it. Everything else is just writing Python code. And   so what the JavaScript   folks have   in terms of running the same language on client and server isn't enough if they still have to take all their data through the rest of the mashing of the stack. It's still not going to solve that complexity problem. Whereas if we can keep it all as Python objects and Python function calls,   now we can make a real dent in the problem.  

[00:19:39] Unknown:

And so for communicating   from the server side to the browser side, are you just using something like pickle for being able to serialize it in a binary format and send that over the wire versus   converting it to JSON back and forth?  

[00:19:53] Unknown:

So we can't use Pickle. Pickle is in fact even interpreter version specific, and we are not running a full CPython in the browser. We're compiling to JavaScript, so that's not really an option. We actually do our own RPC protocol over WebSockets.   And the basic types that can be transmitted   are actually   JSON based. But then what we have is this system called portable types,   where you can   define any   Python class you like, you can tag it as, hey, Anvil serializer,   this thing knows how to send itself over a WebSocket.   And so   you can   build up these rich type systems that you can just happily pass to or from a function call to the server.  

So in some ways, it's more powerful than Pickle   because   Pickle isn't really designed for this particular use case.   Our portable types mechanisms   give you a lot more control over how your data serialize. So if you really are   squeezing the last few bytes of performance out there, if you're transferring large datasets, but you want to keep a nice object model,   we give you a lot more control over how your data is serialized   while still allowing you to, you know, do the obvious thing. If it's a simple class, then you just tag it, mlserverportableclass,   and you're done. There's a blog post all about that. We should put that in the show notes as well. And I am hoping   to record a YouTube talk about how it works under the hood as well. I don't know whether I'm gonna get it out in time for this episode's go live date.  



[00:21:21] Unknown:

Python has become the default language for working with data, whether as a data scientist, data engineer, data analyst, or machine learning engineer.   Springboard has launched their school of data to help you get a career in the field through a comprehensive set of programs that are 100 100% online and tailored to fit your busy schedule.   With a network of expert mentors who are available to coach you during weekly 1 on 1 video calls, a tuition back guarantee that means you don't pay until you get a job,   resume preparation, and interview assistance, there's no reason to wait.  

Springboard is offering up to 20 scholarships of $500   towards the tuition cost exclusively to listeners of this show.   Go to python podcast.com/springboard   today to learn more and give your career a boost to the next level.   For users who want to expand the client side of the application and integrate other aspects of the broader JavaScript ecosystem, what are some of the edge cases or impedance mismatches that they might run into when calling out from their Python syntax code in the browser into those other JavaScript libraries?  

[00:22:28] Unknown:

So that is exactly the right question   because the first skeptical question you should have of a platform, especially a platform that's abstracting so much as Anvil,   is   what happens when I hit the edge? Because   computer science is built from top to bottom   on abstractions.   And like the 2 big questions about every abstraction is like, how easy is it to use? And then what happens when I hit the edges? Do the underlying implementation details leak up? And what happens when I hit the edge and can't do anything more? Like abstraction of a Windows app, when you hit the edge, you want to put your app on the web. Well, it's a desktop Windows app tough, the abstraction has just killed you. Then there's things like what we call the ejector seek patterns. So if   people have ever used like create React app, which is a tool for building and managing your   JavaScript front end build chain.  

It's crazy. The JavaScript and the web ecosystem is so   nuts   that   you need   simple abstractions to help you configure your build tools for 1 level of this stack. I mean, I'm gonna pause for a moment and let it soak in how nuts that is.   But anyway, create react app is a tool for helping you drive your JS build chain without tearing your hair out and with a simpler configuration. But you hit the edge of what it can do, there's a command you can run, which is eject, which then dumps out a full sort of webpack   configuration in all its gory details.  

And that's better than just the abstraction just killing you. But it's not great because what happened is you needed 1 advanced feature, suddenly you're outside the whole platform.   And now you have to do everything the hard way. It's a little bit like an ejector seat in that   you'll live, but it's going to be unpleasant,   not going to be a fun ride.   So the gold standard,   really for when you hit the edge of an abstraction and be clear, oh, Anvil is really ambitious. There are tons of edges like the surface area of the browser as a platform is so huge, we could not possibly   cover all of it.  

But what we go for is when you hit the edges, there is a convenient,   safe escape hatch you can lean out of, do what it is you wanted to do, and then go get back into the warm and dry of this Python environment. And so   we have escape hatches all over Anvil.   I've already talked about 1 of them, the uplink. Like that's the escape hatch for well, what if I don't want to run all my code in a serverless environment?   Bit, is   another answer to that. I don't want to be on your hosted server. That's absolutely fine. Just go pip install it, you'll be fine. So for us, I want to deal with a piece of the JavaScript ecosystem.   It's just another instance of that. Okay, you need to be outside the framework. That's okay. Let's make your life easy.  

So we Sculpt has pretty good foreign function interface support. We've wrapped that up. So   when you're building something in Anvil, you can always drop down to JavaScript. You can build like a custom HTML form. You can define the HTML and CSS that is used by it.   You can write JavaScript and you can call from Python to JavaScript and JavaScript to Python.   And then the crucial thing, the thing that makes it a functional escape hatch is that you don't drag the rest of your app out with it. You don't need to convert your whole app to JavaScript to do this. What you'll then do is say, okay, I wanted to wrap   some plotting library or some data visualization in D3. So I've created a custom HTML form, I've dropped down, I've written the JavaScript integration, I call back from JavaScript to Python,   Python to JavaScript, I built this thing. Now,   I'm going to to Python, Python to JavaScript, I built this thing. Now I am going to package this thing up as a custom component and it will appear in the toolbox for everybody who's using this library. They can drag and drop it onto the screen and configure it from the drag and drop designer without having to write a line of JavaScript. And so that's really the key. Our goal   is when you need to drive some piece of JavaScript library or a browser API,   you can always do it   and you can wrap that back up in Python so that your collaborators   who don't necessarily speak JavaScript can still use it.  



[00:26:35] Unknown:

And so digging more now into the open source release of the Anvil app server, I'm wondering if you can start by just going over how that affects your overall business model and maybe some of the shift that was necessary to make that a reality and the motivation behind releasing it as open source in the first place.  

[00:26:53] Unknown:

1st, I should probably explain what the app server is. The app server is everything you need to run an Anvil app.   And it's open source. It's a thing you can just pip install,   and then you can say, okay. This folder over here contains an Anvil app. Serve that, please.   It will just do it. No must, no fuss.   So the goal here is to ensure that   apps people have written are theirs, like they can take them, run away, and do anything with them. We have people shipping user interfaces on IoT devices using the   app server running on a Raspberry Pi. That's the kind of thing you could never do from a hosted platform, but that's okay, we have an escape hatch. Let's see what we talked about earlier.   So the number 1 goal is to say, well,   actually,   you wrote this program, you should be in control of it, And you should have everything you need to do anything you like with it. It's a place we've wanted to be   for a while because   we are developers too.  

Developers are quite rightly control freaks. We want to know, and when we are going into using any piece of technology,   that it's not going to cramp our style. And in this case, you don't want to say, oh, in order to use this piece, this cool   platform for building web apps in Python,   I'm therefore locked into this hosted service forever. No, no, no, no. I would quite like to be able to just pull it out. Yeah, pull it out, run it, whatever, entirely under my control, edit it with a text editor.   If I decide I don't like these people's faces, I never have to deal with them ever again.   And I'm pleased to say that from a business point of view,   this is actually less of an impact than you'd have thought.  

Because   the problem we're trying to solve is actually the development problem. And so   we're really happy to be   basically selling development tools. I mean, you know, it's it's freemium. You are very welcome to use the free   ID Amble dot Works and to check out and deploy everything with the open source app server. You don't have to pay us, but we reckon that we have the professional features are good enough, that enough people will want to. Kind of aligns   business with the problem we wanted to solve better   Because at this point, we are much more like JetBrains,   the people who make PyCharm.  

We sell   a tool   for developing applications that use open source frameworks.   And it's the right shape for a dev tools company to be.  

[00:29:13] Unknown:

And in terms of actually   making the app server open source, how much work was involved in   either cleaning up the code base or extracting it from the rest of your platform and getting it into a shape that was suitable for public release and public consumption?  

[00:29:30] Unknown:

I still shutter slightly, some of the things. But, no, it was a significant amount of work because, obviously,   1 of the things that we tried to do when we first built Anvil   was to make everything work nicely together.   And so   you're building your platform to be integrated with your development environment, then there's a lot of assumptions that you're gonna have to unpick.   So if you actually open the   source code on GitHub, what you'll see is   all of the assumptions, we basically had to sort of shim out a hook and say, okay, well, for this assumption, you're gonna have to call this   hookable   function and say,   how do I know about the environment I'm running in? Say, and if you're running in our hosted platform,   well, our hosted platform will hook into   the runtime core and say, the way you know about which platform you're running in is   you pull this out of the fabric in our hosted service.  

And if you're running on the standalone app server, the answer is, well, this is the command line argument that I was passed, so this is what your app is. And so that unpicking process was a lot of work, but it was   you know, there's 3 factors that are   a lot of work to get through, but leave you afterwards feeling like you've just had a really satisfying cold shower. It was 1 of those. It was 1 of those that definitely   left the project better than where we found it.  

[00:30:52] Unknown:

For people who decide that they do want to   export their application and run it in their own environment, how does the overall workflow change for the   deployment of the app? And for people who decide that they actually want to do everything on their own, they don't want to use your hosted developer environment,   what are the other   changes that they might need to bring in, or what are some of the considerations   that they should have before deciding to go down that route?   So I'll answer those in sequence.   If you want  

[00:31:25] Unknown:

to take an app that you've built that's currently in our post development environment and run it yourself,   We wanted to make that experience   as close as possible to the   1 button simplicity of deploying something on a hosted platform.   So the actual thing you do is first, you get your app out of Anvil, and all Anvil apps   are Git repositories because of course it's development tool, of course it uses Git. So   you copy the git clone command out of our development environment, you clone it onto your local machine,   and then you go pip install Anvil app server,   and then you go Anvil app server dot. And it says, you know, check this app out of our development environment, launch this directory as an Anvil app, and you don't need to do anything else. Notable contrast with other web frameworks, for example, you don't have to set up a database first, because setting up a database is another example of these things that are massive pains in the rear that, you know, get in a lot of people's way when they're getting started. So actually, the thing that you pip install   actually included embedded copy of Postgres. We will launch, you know, it will set up its own private database and run that, so you don't have to worry about it.  

Serving stuff on the public Internet requires setting up HTTPS.   It's just baseline expectation, everything should be served encrypted and rightly so. And again, setting that kind of thing up involves   setting up reverse proxies   and getting certificates and configuring let's encrypt.   And   that's   way more work than deploying an application ought to be. So again, we've actually embedded a copy of the traffic reverse proxy.   And   if you configure it with Avalanche Server   origin, and then you tell you httpsmyapp.com,   you tell it what domain name it's being served from, it will go and fetch a certificate from Let's Encrypt and just start serving your app encrypted automatically.  

So we have made it as simple as we possibly could   to get this stuff set up. To answer the second part of your question about, yeah, if you decide you don't like our faces, you don't like that guy's British accent, you would much prefer to do it all on your own, well, that's fine. You can go I think it's Anvil create app. Once you've PIP installed the app server, you can go Anvil create app, and it will just set up a scaffolding of   a standard application with some client code and some service code. There are a few examples like a to do list built in there to show you how to do it. And if you look in our GitHub repository,   there is documentation   for everything that you need to push in that directory to tell the app server what to do, if you're building it by hand with a text editor.  

So   this is a notable contrast with the way that a lot of   companies that sell products that are nominally open source go about things.   Because   a lot of companies,   if their main product is open source, the thing they sell is setup and support,   or possibly hosting. And so they're kind of incentivized to make the process of   running your own instance of their open source tool,   like just subtly painful in a 100 different ways.   And   we did not want any of that. We are able to do this, by the way, because, of course,   we make development tools, we sell development tools.  

And so we can kind of lean into making   the process of hosting it on your own machine   as slick as we possibly can,   because   our business does not depend on persuading you not to do that,   which is, I think, a bit of a contrast with a lot of the support based open source companies that you see out there.  

[00:34:55] Unknown:

Digging more into the actual model of running a business based on open source, there are a lot of different ways that people have approached it where you mentioned 1 track will give you a tool to be able to get 80% of the way there. But if you actually wanna use this in production, you need to pay us for hosting to make your life easy or spend 6 months rebuilding our whole platform.   And then there are other avenues   of, we'll   give you this tool, but, you know, there might be some edge cases or there are difficulties that we can't have anticipated. So if you pay us for support, we'll provide some consulting services to help you get over that problem.   What were some of the other tools or companies that you looked to for both positive and negative examples of how to be able to run a business that is based on open source?  



[00:35:41] Unknown:

Oh, I mean, that is a big question.   I think that we had   2 big   negative examples,   places we didn't want to end up.   1 was,   and I will, for diplomatic reasons,   refrain from naming too many names here. But we did not want to be   the   kind of product where   you can do it on your own, but   out of the box, it comes up, for example, horrendously insecure. And so we sort of try to quote unquote punish people for quote unquote cheaping out, like making them suffer horrendous security vulnerabilities all the time. That is not   cool. And, you know, it's not gonna make you friends. If you're selling a developer product and you   try making your developer experience worse in order to get customers, you're just gonna make people dislike you.  

If you're a company, bits of whose product are open source,   someone once told me, you have to think about it as now having 2 products, 1 that you sell and 1 that you give away.   And we do that. And we have   the Anvil development environment   as the thing that we sell or give away on a freemium basis.   And   the   runtime   is the thing that we give away, which means that we can lean right into properly giving away the runtime, gift wrapping it, making it as easy as possible to pick up and swing around your head.   And   we can lean into making the development experience awesome   because that's where our next meal comes from.  

And so I do want to say that   when we talk about other companies   whose products are open source   and some of the awkward binds they've got into, I don't want to say, oh, yes, we are smarter than these people.   Partially, we are lucky to have a product that fits this model really well.   Because the classic pathologies that we wanted that we can therefore avoid are things like, yeah, sure, it's technically open source, but in practice, setting it up is going to be a massive pain in the rear. Just pay us to make your pain go away, which is just not gonna leave a nice taste in people's mouths.   The alternative is you release a product that's open source, and then you hope to sell support and hosting on top of it. And then you make it so good that   knowledge of the tool becomes a, like, widely distributed   among your users.  

And   at that point, there is no reason you are going to host it better than Amazon hosts it. And so the other   real   negative example   in terms of outcome we wanted to avoid   was   giving it away for free and then ending up competing on an equal footing with AWS for operational excellence. Because that is not a battle that any small startup is gonna win. Another example of this failure mode, I suppose, is Docker.   Docker is a company that   absolutely transformed   their target market. I mean,   the way that people develop and deploy software is just different before Docker and after Docker. And yet, despite all of that success,   because the tool is open source, they basically didn't capture any of it. They have, relative to their valuation and their investment, basically no revenue,   and all the actual   value they've created,   all of it that is captured in commercial transactions   is captured by   platforms that use Docker to provide a service that people pay for. And you better believe those platforms don't pay for Docker.  

Does Google pay Docker   for the fact that Google Compute platform, serves apps over Kubernetes, which is a piece of open source infrastructure built on top of another piece of open source infrastructure   and is used to construct a paying service. No, they don't.   So but, yes, those are the 2 things that we wanted to avoid,   were to   be sort of pretend open source, you know, open source, but we'll try as hard as we can to make it unpleasant to use   and to   produce something that basically gets subsumed   and, you know, all of the value captured by some bigger player.  

[00:39:38] Unknown:

Yeah. And, again, not naming any names. 1 of the strategies to avoid that second scenario is to compete based on licensing more than on product. So that's definitely another area that you can potentially go wrong.  

[00:39:51] Unknown:

Yeah. I have a lot of sympathy for   companies who essentially have only 1 product   because that product is a developer tool   or is infrastructure.   The market expectation is that it should be open source.   But   if it is liberally licensed to open source,   then   AWS will, once you reach a certain scale, just launch a product to host it for you and outcompete you at it. And   if you don't follow Corey Quinn on Twitter, you really should, extremely funny guy. He has this line about every year at AWS re:Invent. They lock the doors of the conference hall and reveal which of their partners they're putting out of business this year.   And so I actually have a lot of sympathy for the companies that are trying to walk this line of   creating licenses that aren't quite open source,   that basically   developers who want to use their product   to learn or even to deploy stuff with on their own on their own infrastructure to use it while somehow forbidding   Amazon from AWS ing them. It's a hard problem and I have sympathy for people who have that problem. And I'm not saying we have a solution, we just have a product that's   shaped to be slightly less vulnerable to that problem.  



[00:41:03] Unknown:

Maybe going a bit more into this, what are some of the other main threats that you see to open source business models and some potential guarding actions that   organizations   can take to try and build up a bastion against those potential threats?  

[00:41:20] Unknown:

Oh, man. I mean, that is the multibillion dollar question, that is.   I don't think anyone has a real answer to that.   I think   the models that have   worked,   unambiguously   worked,   repeatably,   have been   the models   that   release   something as open source that is basically complementary to their product. So to take a big example, Google releasing Kubernetes.   It's not what they sell, but it is maintained   because it is useful for the things that they do do for money. That model works. I think   the rise of that model is behind. I think a lot of the transition to, you know, liberal licensing,   liberal licensed products being spun out of these   huge tech companies,   because that's really the most reliable model.  

Well, I mean, actually, no, that's just the 1 model, is to produce something that's complementary to the thing you actually sell. Whether that   is infrastructure that is complementary to what you build on top, so that's what you'll see for the open source projects out of places like Google and Microsoft, and even companies like Lyft and Uber. They sell car rides, they sell   ultimately, that's what we do as well, because   the Anvil application platform   is complementary   to   the development environment we sell. I wish I had better news because I desperately want there to be   a good, reliable way of   building awesome   open source   infrastructure products   while retaining   the ability to, you know, to have a company that's   just dedicated to building that thing.  

But the path to doing it is pretty narrow.  

[00:43:01] Unknown:

And in your experience   of building out the Anvil business and going through this exercise of open sourcing   the app server   and trying to   grow the overall capabilities   for engineers to be able to build applications without having to jump through all these hurdles or overcome these impedance mismatches.   What are some of the most interesting or unexpected or challenging lessons that you've learned in that process?  

[00:43:26] Unknown:

1 of the most interesting   genres of thing   is the little peek into some other industry   that you get   when we interact with a customer, when we see,   you're using this for TV broadcast. I had no idea how TV broadcast works. And in the process of helping with you with this problem, I am going to learn   more than I ever thought I would ever know about how TV broadcast works. That's cool. I'd say that's probably been responsible for the most   interesting moments we've had.   Surprises,   I mean, I'm afraid that the negative surprises almost all to do with driving the web platform.   Every time, you know, we find some corner of the platform and go, oh, goodness, this is really how it works. So as we bash our heads into the desk, we repeat to ourselves, we are doing this so other people don't have to. So, yes, unfortunately, I'd say the web platform is a constant source of negative surprises. And most recent 1,   Chrome's autofill   is remarkably aggressive and by design   can't be switched off.  

You basically have to craft your HTML in an attempt to entice it and persuade   it not to jam users authentication credentials   into any text box you leave lying around. We had a massive spate of maretta.amble.works   is not a valid Python identifier.   Now you see that error message, you go, oh, no,   where has the autofill jam by email address now?   So yeah, it's fun and games.   And I mean, every system is going to have its idiosyncrasies.   And the web is like it is for a reason. It wasn't designed by some mustache twirling villain to say, I know, I am going to   turn the world into a place where you need to be like   a programming polyglot   in order to get as far as hello world on the world's biggest application platform.  

It grew organically   for reasons that were always a good idea   at the time.   And the fact that it is possible   for   anyone with that set of skills to build an application that can be used by anyone on earth is a towering achievement of humanity. I don't want to lose sight of that,   even as we look at the set of skills required and go,   really,   really? Did you need to do that?  

[00:45:40] Unknown:

Do you have any hopes for WebAssembly   as being maybe a mitigating factor in the list of technologies and skills that you need to have?  

[00:45:49] Unknown:

WebAssembly is   incredibly cool. Oh my goodness. It's amazing. It is really awesome. If you have not seen Mozilla's   Pyrodite project,   like that's like a whole data science notebook in your browser because they just compiled CPython, a whole bunch of data science extensions, like into WebAssembly. It's mind blowing. WebAssembly is super cool.   But just like I said before,   replacing   the JavaScript with stuff written in WebAssembly isn't going to solve the problem because JavaScript wasn't the problem.   And just swapping out 1 layer of that stack for incrementally   more congenial technologies to you personally   isn't going to solve the   stack wide impedance mismatches   that are really what's making things difficult.  



[00:46:34] Unknown:

As you look to the future of the Anvil platform and the business around it, what are some of the things that you have planned going forward?  

[00:46:41] Unknown:

I'm always cautious here because every word that you say here is a hostage to fortune.   And I have great sympathy for   companies who have a policy of just not preannouncing anything,   because   anything that you preannounce that's delayed just feels like a broken promise.   And by the time it actually arrives, it's old news.   So   there's a ton of stuff right now sitting in git branches of the Anvil repository   that I am bodily restraining myself from shouting about. But I will say that   we are looking to make the experience   of   actually building an application   a lot more fluid. We've recently hired and built out our dev team, and there's a there's a whole bunch of   stuff that's been irritating us for a while. We can get around to fixing and engineering,   doing proper UX engineering on making the process of sitting down and starting it through the blank sheet of paper of an Anvil app much more pleasant. So but we are currently   going hammer and tongs   on the development tool itself, on the platform itself in terms of increasing its speed, increasing its flexibility.  

We released the portable classes system only last month, went to general availability.   Expect a lot more like that. Expect the platform to get faster and more capable   and expect the development environment to get a lot easier to use and for us to be just, like,   sanding off those bits that you'd still stub your toe on.  

[00:48:09] Unknown:

For anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us on into the picks. And this week, I'm going to choose the game Magic, the Gathering.   It's something that's been around for decades now and is continually evolving. And I played it a long time ago,   walked away from it for a while, and have recently been getting back into it and playing with my kids. So definitely a lot of variety and   strategy and thought that can go into it, and it's just a lot of good fun when you have a deck that you can play and battle against your friends or family.  

Definitely worth checking out if you're looking for something to keep yourself occupied in these pandemic times. And so with that, I'll pass it to you. Meredydd, do you have any picks this week? I have 2, actually. 1  

[00:48:54] Unknown:

is the Anvil advent calendar.   So I'm told that this episode is going out in December,   which means   that if you go to amble. Work/advent,   you should see a series of doors opening with a whole web app behind every door. We're gonna see if we can build some holiday themed web applications that are   more suited to our   current, somewhat distant celebrations.   So check that out, anvil. Work/advent, and you can sign up to be emailed a new 1 every day as we release it. The other 1   is our podcast. So I said earlier that 1 of the most interesting things about running Anvil has been meeting the people who are using it for really cool stuff way outside our experience.   And so we actually started a podcast where we talk to those people. So I've mentioned a couple of people   already that we've talked to, like the lead bioinformatician   at the Melbourne MDU.  

I had a great conversation with him about like,   how does genetic tracing for the coronavirus work? How do you tell who caught it from whom? So that was really fun.   Anders Kaland from Rix TV, the Norwegian TV network I also talked to. We've had like startup founders, people who trace fraud in international phone networks. It's great fun. Avl.org/podcast,   check it out. I promise you it's not just another marketing podcast. It's mostly about the really interesting things people are doing.  

[00:50:12] Unknown:

Well, thank you very much for taking the time today to join me and share your work and experiences it   goes   into   trying   to   bring   an   idea   into   reality   and   that it goes into trying to bring an idea into reality and share it with the world. So thank you for all the time and effort you've put into that, and I hope you enjoy the rest of your day.  

[00:50:36] Unknown:

Thank you for having me. It's been great chatting to you.  

[00:50:41] Unknown:

Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.   And visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on iTunes and tell your friends and coworkers.