Building web UIs in Python has always been an interesting proposition.
On one end, we have the full web design story with artisanal HTML and CSS.
On the other end, there are several Python platforms that aim to bring RAD,
rapid application development style of building Python apps to the web.
Those can be great, and I've covered a couple of them,
but they usually reach a limit on what you can do
or how they integrate with the larger web ecosystem.
On this episode, we have Samuel Colvin back to share his latest exciting project, FastUI.
With FastUI, you can build responsive web applications using React
without writing a single line of JavaScript or touching NPM.
Yet designers and other tools can focus on React frontends
for a professional spa-like app experience.
This is Talk Python to Me, episode 449, recorded December 14th, 2023.
Welcome to Talk Python to Me, a weekly podcast on Python.
This is your host, Michael Kennedy.
Follow me on Mastodon, where I'm @mkennedy,
and follow the podcast using @talkpython, both on fosstodon.org.
Keep up with the show and listen to over seven years of past episodes at talkpython.fm.
We've started streaming most of our episodes live on YouTube.
Subscribe to our YouTube channel over at talkpython.fm/youtube
to get notified about upcoming shows and be part of that episode.
This episode is sponsored by Bright Data.
Bright Data is professional web scraping in a dataset marketplace.
If you need data and it doesn't have an API,
check out talkpython.fm/Bright Data today.
And it's brought to you by Sentry.
Don't let those errors go unnoticed.
Use Sentry like we do here at Talk Python.
Sign up at talkpython.fm/sentry.
Hey, Samuel.
Welcome back to Talk Python to me.
Thank you.
Thank you very much for having me again.
So soon after last time.
It's always amazing to have you on.
In fact, you were on just last week in a really cool show that tons of people enjoyed
and is not yet out at the time of recording, but will be released to the world
by the time your show goes out live.
So it's a bit of a time travel thing.
Very, very appropriate here.
But it was under the full-time open source developers panel of like a bunch of folks,
for example, Charlie Marsh, Will McGugan, Gina Houska, and so on, right?
And you snuck in for a minute there on your travels.
But now you're back and we're here to talk properly about something really excellent
that you put together called Fast UI, which is going to be a lot of fun.
Yeah.
Thanks so much for having me.
And yeah, I'm in a slightly better environment for a podcast than the stairwell of a restaurant
somewhere in Istanbul.
So yeah, it's nice to be there.
High marks for effort there.
Come on.
That was great.
It was good fun, but this is a better place to talk about these things.
Yeah.
Well, I hope you had a good trip and you're back in at it.
Kim out in the audience points out, hey, could you just write another impressive tool for
the next week's show?
Because things are going pretty prolifically over there.
Tell people a bit about Pydantic, the company they probably heard of the library, but just
what are you up to these days?
So Pydantic's obviously been around since 2017 originally, but then it's like something weird
happened at the beginning of 2021.
I don't know quite what that was, but Pydantic, the downloads just went crazy.
So we were at 5 million downloads then and we're now at 130 million.
So yeah, it's gone crazy.
And then just a bit more than a year ago, I was very lucky.
Sequoia got in touch with me and basically said that I want to start a company.
I had been meaning to do that after I released Pydantic V2 that I was then working on.
Yeah.
I started the company beginning of this year and now have an amazing team of 10 people
working with me.
So we released Pydantic V2 finally.
Having originally told people it would take me alone three months, it took me and I guess
then six people a year in total.
But that was released back in the summer.
And now we're working on a platform that I'm not going to talk about now, but I would love
it if you'd have me back, I guess, beginning of Q2.
Is that next week or whatever?
It's not quite next week.
Q2 in 2024?
Something like that?
Yeah.
I think we're going to try and get to Open Beta in Q1.
So yeah.
Okay.
Fantastic.
Yeah.
Well.
But off the back of, so that without getting as much details on it has platform component
to it.
And so we have people, people will be logging in, et cetera, et cetera.
And I was just thinking about all of the path and the churn of building the relatively mechanical
bits of an application.
Again, it doesn't matter actually if you're building it with React or with one of the other
front-end frameworks, you end up having a whole bunch of stuff that's duplicated between
what the front-end guys are doing and what the full-stack developers or the back-end developers
are building for us.
And I guess for lots of people, there's a Pydantic model that's kind of at the core of lots of
those bits.
And I was just dreading all of that churn.
And I had been wanting to build something like Fast UI for a long time, but the fact that we're
going to be using it internally really spurred me on to go and get it built and release it
in like a very incomplete phase to see what people thought.
And yeah, there's been a great reaction.
And here I am.
Yeah, there has been quite the reaction to it.
Let's see.
Do the GitHub star test.
It's 2.6 thousand stars and it's what?
Two weeks old?
Yeah.
A month old?
Yeah.
A month old?
Last month anyway.
Well, it was only released publicly like, yeah, two weeks.
Less than two weeks ago.
Or maybe two weeks ago today.
Oh, that's right.
Yeah.
You probably, so you worked on it a little bit private and then you flipped the bit on the
public status.
Yeah.
That makes a lot of sense because you don't want people just to go, whoa, what are they building?
I mean, maybe you do.
What is this GitHub repo?
They misspelled FastAPI.
I don't know what they're working on.
Yeah, exactly.
And also, I mean, we have a team with lots of people who've done lots of open source, very
strongly opinionated engineers.
engineers.
I can't even get my team to use it without kind of proving the value in it.
So I worked on it a bit without really talking to them and then was like, right, I built this
thing.
Let's at least give it a try.
Yeah.
Because I don't know.
Maybe I'm wrong in this.
But I think it's quite a fundamentally different way of thinking about how you build user interfaces
from lots of the tools that exist today in the Python ecosystem.
And so there's a bit of a like education piece and trying to understand the principle as well
as the like mechanics of going and using it.
Yeah, absolutely.
Well, we're going to dive into the philosophy, but I'll give people that too long didn't read
version.
Basically, you can create UIs in pure Python in sort of dynamic web framework friendly ways.
Right.
Yeah, probably the mistake is in my description of it because yes, it does that.
But where I personally think fast UI is powerful and where we're using it in within the
pedantic team is actually we have got front end developers.
We've got some really expert guys like who are very comfortable building stuff in react.
But we want to those two roles to have to constantly communicate to build every every
individual bit.
So the idea is I think if you go down the page a little bit, I kind of explain it.
But like for a front for a Python developer, it's this way of building UIs without having
to touch TypeScript or JavaScript or NPM or any of those Byzantine like massive build tools.
But then for a front end developer, it's this opportunity to go and build the best components
you can and allow basically provide a powerful interface for your back end guys to go and build
a build a UI with it.
So kind of split those two things up and I guess allow react to do what react does brilliantly,
which is allow which is provide these like reusable components.
Yeah, absolutely.
Kind of a framework as well to bring the navigation and the cohesion of the whole app together,
not just a particular view or a page to what you would say, right?
Yeah.
So the weird bit is principle of RESTful interfaces.
We've all heard of RESTful and we all think we know what it means, which is basically something
to do with a URL structure and return me some JSON that like gives me the data I need to render
my view.
Well, if you look at the rifle that Roy Fielding's original PhD, as is brilliantly described in
this HTMX article that I talk about further on down here.
He's not really talking about that stuff.
Sure.
He has some stuff on what the URL structure should be.
But really, his principle is that the data returned from the back end should be self-describing
as if it should have everything you need to go and render the user interface.
So let's say, I think they're using the HTMX example, example of like a bank account.
And if you go down to like principle, the long version, here we are, right?
I've linked to the PhD, but more importantly, the HTMX article, which explains it really well.
I think if we follow that, yeah, I think they'll even on that page, there's a very jokey tone
lots of the time HTMX, but they also talk about a really cool thing.
Yeah, absolutely.
Somewhere I think they have, yeah, here we are, right?
So if you look at the traditional JSON response, which I think is the second one, and you were
trying to show, yeah, right.
So this, you and I as humans can read this and be like, yeah, that kind of explains my
bank account and what's going on.
But there was not enough.
It's got like an account number and a balance, which is a more complicated object, nested object
and those types of things.
Right.
It's got all the things that we can read account number.
Cool.
That's a number balance.
Yeah, that makes sense.
But if you're a computer, there's not enough there to go and render someone the nice user interface
they would want where they would have it displayed on a page.
So if you were the engineering team in the bank trying to turn this into a web interface,
you then need to go and have lots of very application specific or page specific logic to show where
the account number goes and where the balance goes and where the status goes and stuff like
that.
And that causes an enormous amount of churn.
And it means that it's particularly difficult when you have those engineers working in different
time zones because you end up having this spec between the two.
And then you always have this problem with software where fine, we can get it to work.
But what happens when we come to add it?
So what's the process of, let's say, we want to show as well on this page, your like joint
account balance, let's say, just to make something up.
What we probably need to do is we need to get back in guys to go and add that to endpoint.
And then the front end, and that can be deployed.
And then the front end can be updated to show that and the data is available.
That is a lots of churn, lots of delay.
Right.
Lots of coordination between the two domain experts.
And then it kind of, you've got that microservice cascading, like it's got to do, then this one's
got to be upgraded.
And then eventually there's enough flow of data through the system that the UI people can put
it up there.
Right.
And so, and it's bad in this case of like showing your bank balance, but it gets even
worse when you have a form where every field in the form needs to be completed, for example.
And so we basically have to deploy the front end that has all of the form components and
the backend that receives that new form at the same time.
And we've got this Pynantic model that, you know, depending on how we've done it, probably
is used to define our form.
And it might even be used to define our database.
But like, we're not using a Pynantic model in the front end.
TypeScript, in my opinion, is a big Achilles heel in typing is that you don't have any, you
can't use type ins at runtime.
And so we don't have an equivalent of Pynantic.
And so we're basically trusting that data is how it is.
So yeah, FastAPI is an attempt, sorry, Fast UI is an attempt to basically remove that
need to like have complete synchronization between backend and front end by having beautifully
designed components in the front end.
Not saying what we have now is that beautiful, but that's the ideal log term.
But then the backend can basically just do the orchestration, can say, show me a table,
show me a form, show me a modal and put the following content in it, et cetera.
Excellent.
Nice comment from Tony on the audience.
As I originally started in Python and went to using TypeScript, Pynantic made the transition
back to Python so nice.
And so in your description, you also have up here that this Pynantic is interesting,
is involved here.
Like what is the role that Pynantic plays in defining all this?
So the idea is that we're getting to, of this RESTful UI is really that we end up having a
bunch of components in a shared definition of some components.
And we basically promise that the backend is going to send data that matches the types
defined in the front end.
Well, that's all very well, but if you're not careful, you end up not sending quite the
right data.
So what's nice is that all of the components that you can return from fast UI are themselves
Pynantic models.
So Pynantic goes off and does not only the validation, but also the coercion.
And it does stuff like uses camel case.
So the front end developers are happy because we've got no underscores anywhere.
And so, yeah, all of the backend code for fast UI basically is just Pynantic models, which
implement these components.
Right?
So it might be useful for those who can see this to go in and I can talk through an example.
If we go into the code here and I can talk you through like a very basic component.
Oh, maybe it'd be useful.
I showed it here.
So I've got the code base open here, just working on something.
But if I open up here, source and then the Python package, and then we look into components and
we can look at like a really simple component, probably a button, which would be kind of understandable
to everyone.
Where's button?
Here we are.
So this is just a plain Pynantic model, which contains text, which is the text you put within
the button.
Then it contains the event that you want to fire when someone clicks on it.
And HTML type, which, you know, this matches what you can get in HTML button, reset, submit,
and then class name, which becomes the classes that get applied.
And then critically, this type, which is a literal, which has to be button.
And that is used by the discriminated union in Pydantic to do the validation of different
types.
And it's also used by a big switch statement in the TypeScript to basically decide what component
I'll go and render when I get an object.
Right.
So there's some TypeScript.
Maybe it makes sense to talk a bit about the building blocks.
You say FastUI is made up of four things, just so people can get a sense of like, you
know, what's at play here?
Right.
So the four things that we have now, package, a Python package called FastUI, which I was
just showing you there the types for.
Yep.
And then we have NPM package called FastUI.
Again, it's in the Pydantic organization, which is where the meat of the logic resides.
And that's implementing basically the most of the components and all of the wiring to mean
that when I return a button, the button component gets rendered.
And then, but obviously, we don't probably want to end up using a vanilla button when we come
to display it.
So then I've implemented basically customization of the FastUI React library using Bootstrap.
So all that's really doing is it's deciding what classes to append to use with each component
and also just customizing a few of them.
So for example, modal, there's no like nice way to do a vanilla modal.
So the modal in the default FastUI, the end package just basically shows me alert saying
this isn't implemented.
Whereas the Bootstrap one uses a nice Bootstrap modal.
And then we have finally FastUI prebuilt, which basically uses the FastUI package, customizes
it with FastUI Bootstrap, and then builds it.
And that means we can go and basically return that prebuilt React app without having to get
our hands dirty with NPM on Yarn and Vite and all the other.
All the webpacky bundling, minifying, transpiling business.
But the cool bit, in my opinion, of FastUI is that at its core, it's really the definition
of a bunch of different schemas effectively.
Those schemas are defined in Pydantic and they're defined in TypeScript, but they could
perfectly well be, and really nicely, I just merged this the other day, we now use the JSON
schema generated by Pydantic and JSON schema generated by the React types to basically go
and test that there's an equivalent between those two models everywhere.
But in theory, there's nothing to stop the front end from being built with another JavaScript
library or even with something like HTML and HTMLX.
Or even you could go and use React Native and build, or even some kind of embedded device,
you could go and implement those components.
And then on the other side, and this is even more achievable, you could go and return data
that matches those models from a Rust or Go service.
And in theory, you don't have to change your UI at all, because all you're doing is I promise
that I'm going to match these schemas, and then whatever front end or whatever back end
can then communicate.
Whether that comes to pass, I don't know yet.
And obviously, I built the default back end in Pythin, because that's what I know best,
and where I think Pydantic is really helpful.
And I built the first front end in React and TypeScript, because one, that's what I know,
and two, it's what we're using within Pydantic.
But lots of people have asked about HTMX.
People have also asked about Svelte and others.
I think I wouldn't see the point in building fast UI in Vue, because I don't think it adds
much.
It's just a lot of work.
But I think there's a world where we build a HTMX template rendered version of fast UI's
front end that could be super valuable.
That's interesting.
So first point is, these different components sound like they are potentially a little mix
and match.
You know, you could take it all as one big thing, or you could say, really like the way
it defines the React front end, but we're going to implement it some other endpoint.
Yeah.
I think it's something like, it'll be slightly skewed now because of tests, but I'd say it's
sort of twice as much front end to back end at the moment, as in the, yeah, it's skewed
a bit by tests, but even now there's more TypeScript.
So I think the simplest thing to do, and you could do it pretty trivially would be to
use another backend, another language for your backend service.
And as long as it matches those types, and you could even go and use something like JSON
Schema to enforce that.
But yeah, re-implementing the front end, probably a bigger piece of work, but totally doable.
I mean, I did it in my spare time in two weeks, built the whole thing.
So it's not, you know, millions of different things.
There's kind of 20 components at the moment that are then composable to build reasonably
sophisticated like UIs.
So this is a web front end, like Flask or Django sort of framework, but a way that really
incorporates building the UI in Python and validating and enforcing that with Pydantic
rather than just, hey, file new HTML.
Let's just start typing and hope they line up, you know, like instead of trying to juggle
all those different languages, CSS, HTML, all the JavaScript tooling for packing up stuff,
just let's write Python, right?
So maybe you have a simple example of what it looks like to define a real simple example
here on the readme.
It's got a very interesting parity between what is in the HTML DOM and is what is in the Python
abstract syntax tree, I guess, right?
And visually as well, the way you look at the code, it looks like the way it might look in
HTML.
Like give us a sense of what writing a UI in this would look like.
Right.
So I think the first of all, we have to talk about like the two enormous, the two most obvious
pitfalls for this.
One end of the pitfall you have, which I think is the biggest temptation is to basically mirror
all of HTML in Python.
And for those of us who are happy writing HTML or writing React, that sounds like hell.
It's going to be slow because you have to do some weird rendering, but it's also just going
to be a pig because I don't want to have to define every A, HRA, and everything else in
Python code.
It says, and there are going to be, it requires for a start, it requires you to know two things,
Python and HTML.
Whereas for HTML, you only need to know one.
This portion of Talk Python to Me is brought to you by Bright Data.
Bright Data helps you turn websites into structured data.
There's an unimaginable amount of data available on the internet.
And we're lucky to live in a time where we have so many APIs to access structured data.
But the truth is that most of the data out there is not served up over a clean API.
It's just sitting there on a web page as HTML.
Maybe it's even further obscured behind some front-end JavaScript framework like Vue or React.
What if you need access to that data?
Web scraping to the rescue, right?
Yes, but just like you wouldn't set up your own production infrastructure in your home office,
running a web scraping job on a single computer at a fixed location can lead to a web
your program being unreliable with data pinned to that IP's location and much of the time
blocked for rate limits and other such causes.
If you need to do professional web scraping, Bright Data is the place to start.
They have award-winning proxy networks and powerful web scrapers.
What's more is they have ready-to-use datasets for download,
so you might not even need to scrape data at all.
And if you can't find the dataset in their marketplace,
they'll even build a custom dataset for you.
From listening to the show, you know that I'm a privacy-conscious person,
and that's why I'm happy to see that they are both CCPA and GDPR compliant.
Bright Data has both low-code solutions as well as Python programming models with Async,
IO, and Playwright.
So if you have serious data needs and those websites don't offer APIs,
then you need Bright Data.
check them out today at talkpython.fm/brightdata.
And please use that URL.
That way they know you heard about them from us.
That's talkpython.fm/brightdata.
The link is in your podcast player show notes.
Thank you to Bright Data for supporting the show.
I always find these things that try to dodge,
like dodge the fact that HTML exists.
I find them, I don't know, I just, they don't resonate with me.
I'm not entirely sure why.
It's like, we have really nice things like CSS,
and we have really, there's just so much tooling and frameworks,
you know, you mentioned Brutestrap already, right?
That just plug into there.
And if it's like, well, we're just going to write, recreate it in Python.
Well, it has all the oddities of HTML if it's going to be really high parity.
And then you just have a less well-known way to do the same weird thing.
You know, I don't know.
It just, it doesn't resonate super with me.
I agree.
And I found the same thing at times with ORMs,
that you end up, the worst case of an ORM is you work out what you need to do in SQL.
Then you try and translate back from SQL to ORM,
and it would be much nicer just to write my SQL.
I mean, not always the case.
ORMs can be powerful, but I think that they both can fall into the same trap if you're not careful.
And then I was going to say, at the far end of the spectrum,
the other end of the spectrum, you have, and I guess Django's admin view,
for understandable reasons, could suffer from this,
that you basically have a very small set of things.
You have a table page and a details page and a form page, and that's kind of it, right?
So there's this difficult trade-off, and where in that continuum
do we try to choose what size of component to implement, right?
So for example, here we have a heading,
which is almost one-for-one matches what you would do in HTML.
We have the text that goes within it, and we have the level,
which, you know, it's slightly different syntax,
but it's basically one-for-one matching an HTML tag.
But then we have a table, which it doesn't look very much like an HTML table at all.
We're not having to explicitly define the table body versus the table head.
We're not having to put in each column.
We're not having to worry.
Yeah, there's lots of stuff here that is much less like it.
And that's where it's in these very common components where there is consistent things
that lots of people want to do, or lots of places in your app where you might want to do them,
where I think a framework like Fast UI gets super powerful,
because we can get you a table here with users defined and with a few columns with some customization
on what happens when you, how we render each column much more quickly,
then we could go write out all the HTML for that.
And it's much more concise to read.
It's like, it's consistent enough that something like GitHub Copilot will help you write it out
where you do have a bit of customization to do.
I think this is where it can be super powerful.
Yeah, it is pretty interesting.
And I like the hierarchy.
For people listening, just check out github.com/pydantic slash fast UI.
The example right there on the page.
But what you do is you create a, in this case, a FastAPI, API endpoint,
and then you return a hierarchy of elements out of fast UI.
So we have a page.
The page has components.
The components are a list of a header and a table.
The table has data, which maps over to a list of pydantic models,
which then help say what goes in the field and for the column headings and things like that.
It's pretty interesting.
I think it's neat.
Yeah.
And obviously we can add other components like pagination that works.
I think just to come back to the top, to how we do these views.
The very simple, and it's most simple what fast UI's React app does,
is it basically takes whatever the URL is you go to.
So in this case, you might go to slash, to the base URL,
and it prepens slash API and makes a request to that endpoint to basically say,
what should I render?
And it gets back.
So here we're basically returning a list of pydantic models.
All that the fast UI model is really doing is taking that list of pydantic models
and calling model dump JSON on it to get the JSON that we return to the front end.
And as I say, the front end then knows how to render each of those,
each dictionary in the list is what it is.
At its core, it's a list of objects to use JavaScript parlance.
It just knows how to render each of them and renders each of them in turn.
And then obviously they can then have nested other models,
all of which it knows how to render.
Yeah.
It reminds me of a couple of things.
I have an example.
Is this?
No.
Somewhere along here.
I pulled it up.
It reminds me of kind of what React looks like.
If people have done React, you know,
you write a function that returns kind of an HTML thing,
but then it has JavaScript arrow functions, right?
But it has the same nested feel, right?
Did React inspire you to create it this way or not really?
Yeah, it did.
I've done quite a lot of React and I like it a lot.
I know as a popular piece of technology,
there were lots of people who like to berate it,
but I do think React has been a powerful step forward.
And the greatest form of flattery is copying.
There are enough other, like, sure, there are other more powerful,
arguably more powerful, arguably more performant,
new front-end libraries, but everything is component-based now.
Like, you know, React has changed the,
there was a sea change in how we did front-end
with that component architecture.
And JSX, similarly, is super powerful.
So one of the things that I think we're going to get to,
I don't want to dive into it yet,
but like in React, you would say like,
we're going to return a photo context or a switch
or something that is not typically known in HTML.
And these are higher order building blocks in the UI space, right?
So when people think about what they're creating here in Python,
it's not just the fundamental DOM objects and elements, is it?
Right. So that is actually, yeah.
So page here is a bit of ambiguity
about how we're going to define a page.
Like default implementation does something reasonably sensible.
It like, you know, pads it, et cetera.
But like heading isn't, there isn't much to do really.
You're going to return a heading,
but when you come to a table,
there's a lot of debate about how you're going to do that.
And then when you move on to like even higher order components,
like a modal, then that's the,
how exactly that's implemented is, you know,
in some sense it's completely the choice
of how you've implemented it in the front end.
You could, you could do lots of different things,
but yeah, the whole point is that it doesn't
and shouldn't be like each HTML tag is written out.
Because as I say,
I think that would be a like obvious failure mode for this.
Yeah.
The other thing this reminds me of,
by the way, just for people out there listening is
that it looks a lot like a Flutter.
If people have done any Flutter,
you've got these widget hierarchies.
You build them, you maybe set some properties,
you add in a bunch of,
a bunch of elements, you know,
set some children to an array of other sub elements.
And this is done, of course, in Dart,
but it's, you know,
this is kind of a Python version.
That's similar as well.
These higher order widgets.
Yeah, absolutely.
Similar thing.
And actually, the other place where I've built this before
is that internally Pydantic core,
the Rust bit of Pydantic,
is effectively not entirely different to this, right?
You define these nested structures of different validators.
Everything at its core is a like combined validator,
which is in Rust terms,
an enormous enum of all the different types of validator,
some of which have nested within them,
more and more validators.
And that's how you build up nested structures of Pydantic models,
which in turn is what these are.
We're getting there.
Yeah, the validators in the UI,
they kind of like have a similar structure.
A bit of a sidebar,
just a bit of a piece of code in here.
You've got table,
which is a class,
square bracket,
user,
which is another class,
square bracket.
I imagine that you and your team
are deeper into the Python type system
than the vast majority of others out there
with all the work with Pydantic
and the interoperability with Rust.
What is that?
Tell people about this.
Yes, a table is a generic.
So if you,
you can imagine if you were doing list events,
you would do list,
square bracket,
int.
And that's basically the point is that
list is a generic around its elements.
Same as a dict is generic around its keys and its values.
Well,
table here is generic around the Pydantic model
that you're using to,
using for each row.
And particularly what that means is that,
what it means practically is that table has access
to the class when it's deciding what the default columns are.
So if you don't define the columns list as we have here
to say what columns to display,
it'll show all of the fields in the Pydantic model.
And the point is we get access to that,
to the user before we've,
even if,
even if data was empty,
before the validation has happened.
Is it necessary?
Is it slightly like,
yeah,
fancy use of Pydantic types,
Python types,
maybe it is,
but yeah,
if you know,
forgive the Pydantic team or me in particular for occasionally doing fancy things with Python types.
That is definitely occupational hazard of what we do.
Yeah.
I didn't mean it as a negative.
I just thought it was interesting.
No,
I agree.
And actually,
I had it somewhere else on forms and I removed it and realized it was,
it was,
it was unnecessary.
So you can definitely do too much,
such a thing as too much Python typing.
Yeah.
For sure.
It is pretty interesting.
So let's maybe talk about some of the examples.
Actually,
before we do,
just give us a sense of where does this fit in the UI space for Python?
On one hand,
we've got Flask,
Django,
FastAPI,
returning HTML,
et cetera,
where it's all on you.
you're doing all the five languages of web apps,
SQL or some query language,
Python,
JavaScript,
CSS,
some other tools,
right?
Like you're doing all that and you're doing my hand.
On the other end,
we've got tools that are pretty cool.
Like we've got Anvil that lets you just write Python and do a draggy dropy sort of thing,
which is,
is really neat,
but it fits into a kind of a,
a box for those types of apps.
I just discovered DropBase.
Have you heard of DropBase?
Not seen DropBase.
Yeah.
We've seen a lot of these like,
get me a UI more quickly.
A lot of them are like kind of low code.
Anvil,
maybe I wouldn't really quite put it there,
but they're pretty like low code,
but then there's places where Python goes to make it dynamic,
right?
So where in that spectrum would you put fast UI as it is today?
Interestingly,
and one of the reasons I wanted to come and talk to you was I heard your,
you were,
you were talking the other day on,
on your other podcast and I heard you talking about fast UI and kind of,
I'd say categorizing it into that,
that group.
And what I wanted to kind of,
one of the things I wanted to come and say was,
yes,
we can do that.
But the,
the use case we have within Pydantic is actually to go and build a pretty complex,
fully fledged application with,
with front end developers building components,
but just get rid of that churn.
Right.
Something more like Gmail,
less like,
here's a table that I can click on and see some related table.
Right.
Exactly.
And what I should probably put in the demo and probably where Pydantic is people most associated
and where it's,
this is going to be most useful is within forms.
So I don't know if you want to go to the,
to the demo and I can talk people through,
but like within fast UI is dedicated to forms.
We can do things like nested Pydantic models all become components within a form.
And obviously we can do client side validation with a whole bunch of stuff,
but we can also do server side validation,
but then we get all the fancy stuff.
Like if the,
if the data is invalid and you get a validation error on the,
on the server side,
we'll then basically re-render the form with the errors in place.
All that stuff that like anyone building a web application has to go and implement some version of it.
At the moment there's,
there are some,
some react libraries that will build you a form from JSON schema,
but they don't perfectly fit in with,
with what Pydantic does or with,
with FastAPI.
And so I have built some variant of that about five times.
I still think the state of the art until now is Django,
but like lots of us don't want to build our web applications completely with Django
because it's,
it's pretty all or nothing despite the wonder that it's Django.
And so that's the kind of space where for me,
this,
this like becomes a really stands out because what would have been to do it properly?
It's days of work to get form,
to get form submission to work,
get client side validation,
server side validation,
get the redirect after your form.
None of that stuff is,
is entirely trivial,
even for those of us who've done it before.
Whereas with the theory is with fast UI and in,
although fast UI does not require FastAPI,
the form stuff is,
is quite tightly integrated with FastAPI.
and you can get,
yeah,
a really good experience of building,
building stuff like forms.
I think that,
that where the alternative really today is,
is to use no disrespect to any of the fast libraries or any of the other things.
But I think the only real alternative right now is implement it yourself or use Django.
Yeah.
But I do also want to,
but maybe before we get to that,
let's try to take a little survey of what are these widgets,
these building blocks that you can use.
Yeah.
Is that right?
Yeah,
absolutely.
I think I can find them here.
Yes.
Yeah.
So you've got a fast UI demo,
which I'll link to at onrender.com prefix,
but you talk about some of the things that you can just create in that Python hierarchy
that you return that builds up your UI there.
So maybe we talk us through some of the things that are here.
Yes.
We have the kind of generic markdown component,
which will go up and renders a markdown.
This table itself is,
is implemented using the markdown component.
Just a one side note,
the markdown and the code,
because they have quite a lot of JavaScript associated with them,
but they're actually lazily loaded to make the,
make the prebuilt fast UI app faster to load.
Then we have text,
probably the simplest one of all,
just render some text paragraph.
Again,
very simple page titles,
a slightly funny one.
It doesn't actually display anything on the page,
but it changes the,
the browser title.
So what you see in the tab at the top of the page,
it's not always easy to do.
Like how do you inject it into the head when you're in the body?
And like,
it takes a little bit of integration there.
Yeah.
Right.
Exactly.
Heading again,
very simple,
like one to six HTML heading code,
bit more sophisticated.
And if you click on code,
maybe,
maybe those who can see it will be able to click through code.
Yeah.
So code is there.
We,
we get a like highlighted bit of,
a bit of source code displayed.
It's color coded with like class types,
having a color and keywords,
having a color.
That's nice.
Like you would see in,
in GitHub or something like that.
So again,
just,
just like work out the box.
Then we have some components like a link list and link,
which are used in other components mostly.
So if you,
the nav bar,
you see at the top of the page there that uses a link list.
And then we have links.
Then we get into kind of more sophisticated components.
So the first one,
you see a button,
which loads a modal and then the button,
which loads a dynamic modal.
So that when the modal loads,
it will make a request to get the content.
You want to see within that modal.
So that could be a form or it could be customized depending on,
on the form in the page.
Then we have loading content from the server,
which is the same thing we were doing in the modal,
but on the page.
Then we have this SSE component.
So again,
very simple to use within fast UI,
but like quite a lot of work to use server side events to basically
dynamically update a react component.
If you weren't using that.
So your server load SSE widget that provides,
like you said,
server sent events,
which I don't know how many people are familiar with SSE.
I'm sure they're familiar with web sockets and they're familiar with just
like a JavaScript event,
but this is like an intermediate sort of lightweight one directional,
but the normally the opposite in reverse,
I guess from the server to the client sort of pushing out stuff.
Right.
So that's a really powerful thing.
And if it's,
if it's that easy to just hook a function call when something happens,
that's pretty cool.
One of the things I want to try with SSE that I think will work
really nicely is LLM responses where you get like one token at a time
because you don't want to wait for the whole thing.
Yeah.
The center events would be perfect for basically printing out the response
from an LLM.
And again,
it would be like,
you know,
two lines of code to add that to an app with fast UI.
It would not be two lines of code to go and implement that yourself,
whether you're using pure JavaScript or react or whatever framework.
Yeah.
And we have,
have iframe,
which again,
kind of map,
we're back to kind of mapping one-to-one to a component.
One of the nice things to say about both iframe and image is they were
by other people.
So I don't think I'd even created an issue asking for them,
but people have come along and added them.
It's been one of the nice things to see.
I think we had 18 or so people contribute to the first release,
first release after my initial release,
or sorry,
the second release of fast UI.
So yeah,
good engagement from lots of people.
Image.
Yeah.
So you've got a bunch of UI stuff here and it just,
as I look at this and I see what you're building,
it just makes me think of like,
wow,
there's an opportunity for stuff like,
like what you get out,
not necessarily the same as,
but like what you get out of say tailwind UI,
where the things you might work with are on off switches,
you know,
like toggles,
like you might see in your phone or other sort of elements that have like
a lot of design imbued in them that people can just grab and use almost
like a Django philosophy for the front end in a sense there.
Is that something that you are dreaming of or?
Someone was complaining somewhere that we didn't have a grid component yet.
And I think we'll do one,
but like those bits get quite opinionated,
but yeah,
like calendar completely obvious choice,
right?
Complete faff to go and implement that yourself in HTML.
Commonly used trivial to define because,
because the definition,
there aren't that many different things to define.
You,
you choose your month,
you know,
most of us are on the Gregorian calendar,
right?
We're not,
we're not going to have to change too much what calendar we're going to render.
So yeah,
that's a perfect example of the kind of thing.
Tiles like this,
again,
totally possible to go and implement them.
And again,
obviously you can use,
we can provide some nice default,
but also if you're a bigger company and you want to go and customize it,
you can totally do that.
And you can have a front end developer go through and implement the classes that basically customize,
customize the look.
I wanted to come back just and show you some of the,
some of that,
some of the other components.
So we were on,
yeah,
this one.
Yeah.
I don't know if we have anything more below that,
but I would love to show you the tables because the tables and the forms are really where it comes into.
So cities is probably the best example.
Cities is the one.
Okay.
Yeah.
Awesome.
This is a list of cities just for some public data set with country and population.
But at the top,
you see,
we have a filter to choose by country.
And if we click here,
if you start,
start searching like UN or something,
you'll see we're doing a server side.
We're loading from the server,
the list of cities.
So again,
this component to go and implement,
if you were going to do that from scratch,
you've got to have,
use some like,
whatever,
this is a list of countries.
So if you do like,
all countries,
sorry,
I'm typing in cities.
Good.
Like UN,
United Kingdom and United States.
Yeah.
Perfect.
There you go.
And then we do United States or whatever.
Yeah.
And then we'll get a bunch of cities in the United States.
Building this and wiring it all up and using one of the,
we use react select here,
but you can use select two or one of those components.
It's not trivial.
You need to also set up the backend.
You need to set up,
there's like a few hundred lines of react dedicated just to setting up those,
those selects correctly.
And as you'll see in a minute on a form,
you can add this to a,
to form with us UI pretty trivially.
Secondly,
if you go to the bottom of the page on cities,
you'll see pagination again,
not a trivial thing to go and set up.
If you've got,
if you're just starting from scratch and you want to show like build an internal
endpoint,
for example,
to show all of your users doing all that pagination and like wiring all that
up is not trivial,
but we effectively do the work for you to have that component and do the maths of
which page we're on and stuff like that.
Nice.
I want to like reiterate,
this is the fast UI is not just designed as a kind of Django admin interface
alternative.
We within financing are going to go and use it for UI that we're going to show
to end users.
But obviously it also comes into its own when people want to just get something
up quickly.
This portion of talk Python to me is brought to you by Sentry,
you know,
Sentry for the air monitoring service,
the one that we use right here at talk Python.
But this time I want to tell you about a new and free workshop.
He means the Kraken managing a Python monorepo with Sentry.
Join Salma Alam Nayor,
Senior developer advocate at Sentry and David Winterbottom,
head of engineering at Kraken Technologies for an inside look into how he and his team develop,
deploy,
and maintain a rapidly evolving Python monorepo with over 4 million lines of code that powers
the Kraken utility platform.
In this workshop,
David will share how his department of 500 developers who deploy around 200 times a day
use Sentry to reduce noise,
prioritize issues,
and maintain code quality without relying on a dedicated Q&A team.
You'll learn how to find and fix root causes of crashes,
ways to prioritize the most urgent crashes and errors,
and tips to streamline your workflow.
Join them for free on Tuesday,
February 27th,
2024 at 2 a.m.
Pacific time.
Just visit talkpython.fm/sentry dash monorepo.
That link is in your podcast player show notes.
2 a.m.
might be a little early here in the U.S.,
but go ahead and sign up anyway if you're a U.S. listener,
because I'm sure they'll email you about a follow-up recording as well.
Thank you to Sentry for supporting this episode.
If we have a design language or something like that,
or even using a framework,
I mean,
you mentioned Bootstrap,
but Tailwind or Bulva,
is that one of the new ones?
Like,
if we're working with one of those and we wanted to use this,
like,
how easy is it to sort of bring in those elements there?
So if I show you here on Bootstrap,
to ask you how we customize it with Bootstrap,
which is probably the best definition of it.
So you'll see here,
this is in the,
this is the,
where am I looking?
This is the pre-built version.
So this,
this is obviously the pre-built version of Fast UI you can get,
but it's actually just,
it's a very simple app in terms of React.
this app has one,
well,
two components.
It has a div,
which contains the Fast UI component.
And then we customize it in a bunch of ways.
We have a like component that we render for not found.
We have a component we render for spinner and for transitioning.
but then these are the two that really matter where we can customize the
classes and we can customize how we render certain components.
So if we come in here to have this function from Bootstrap,
which is how we customize the classes,
you'll see that at its core,
it's just this big old switch.
So this is all TypeScript,
like type safe because types are very powerful in TypeScript,
but like all of the props will have this type key.
As I showed you earlier,
when we were looking at the Python code and all the different things.
Yeah.
Based on the switch,
we just go through,
and this is all just like defining the classes we want for all of the
different components.
Some of them depending on the exact state of the component.
So all of these form inputs,
we customize them depending on which type they are and on which mode we're in,
et cetera,
et cetera.
But it's,
it's all very mechanical,
just like laying out the classes we need for each and each individual case.
And then we have the other way of customizing it,
which is to use custom components.
We basically for three in particular components,
nav bar,
modal and pagination,
we define our own,
custom react components.
So here's the one for nav bar where we use a bunch of bootstrap types to render a bootstrap nav bar.
So you can basically create a react component that has all the settings necessary to create a nav bar in tailwind or whatever.
Right.
And then just plug that stuff in.
So,
so if you wanted to use tailwind,
what's this like 20,
it's like a hundred lines of code to define all of the classes and it's pretty mechanical code,
right?
So it would be,
it wouldn't be hard at all to go and use tailwind,
tailwind CSS.
And then you might want to define a few of your components specifically.
Yeah.
But actually modal,
modal,
I think is the only one that really requires it to be custom implemented because the default just shows you an alert because there's nothing.
Right.
JavaScript.
The page says,
it's like,
oh,
no,
the page doesn't say this isn't going to work.
Yeah.
So,
yeah,
I think this is one of the bits I'm most proud of here is that like how much you could customize it and how simply you could start to customize it.
Right.
Those are really like kind of pluggable or extensible.
So you don't have to,
you know,
get in and know too much about it.
You just plug in the class name generator and the renderer for a specific one.
And so,
yeah,
and all of the types,
it's all typescripted.
So you,
the type should do a lot of help telling you what,
what you can implement.
The last thing I'll show you is,
yeah,
so here in the default build,
as I said,
we,
our custom render function is not just a bootstrap one.
We do one special thing,
which is where we,
we have this idea of a custom component,
which basically all it has is a subtype,
which basically you should use to render it however you like.
So in our case,
we hit take custom.
And if the subtype is cow say,
we render that as a particular block,
like use this,
this component here.
And we print out the cow says,
whatever it was that the input was from the server.
And otherwise we just go back to using the bootstrap render.
And so if you look at,
look at that component here.
Yeah.
We've got this like slightly silly example of a custom component of cow say,
saying something.
Oh,
that's fun.
But yeah,
it shouldn't be too difficult to customize.
And then even if you're customizing to go back to using bootstrap for,
for the fallback case of everything else.
Okay.
So you could almost just for one section that has to be really specialized to some custom,
but otherwise just lean on a framework.
Yeah.
Okay.
Yeah.
This looks like something that one person could take one for the team,
create a tailwind or a whatever generator,
class name generator,
and then put that as either a contribution or put it up on GitHub.
And then you just,
you're kind of good to go.
Yeah.
I think we might,
we might actually do it.
We're,
we're using tailwind and radix within Pydantic.
So I suspect our front end guys will at some point get annoyed with my use of bootstrap
and go off and go and change it.
One of the reasons I use bootstrap is that because bootstrap is completely customized via
SCSS and there's SCSS compilers for Python.
We have the,
at least the possibility in future to allow you to customize the complete look and feel of your
app without ever having to touch NPM.
Cause you just go change basically the color definitions as we do here.
So,
so the,
the default version of,
uh,
maybe I can even change it here and as it's running,
it'll change.
But if I hear you see,
I've set the primary color to be black.
And so you'll see the buttons here are all rendered as black.
If I were to change it,
I haven't tried this for a bit,
so I hope it works commented out primary.
You'll see that the primary,
uh,
which is the bootstrap primary button.
If I changed the,
I got rid of the default font.
You would see,
we went back to whatever the other font was.
So there's a world in future where we allow you to customize the look and feel
even within bootstrap from Python code.
Yeah.
Tell people maybe who don't know what SCSS is.
They probably know what CSS is.
It's generally referred to as SAS,
which is S A S S S,
which was,
is,
is basically,
uh,
a more powerful version of,
of CSS where you can.
SAS and less.
Those were the two.
Yeah.
there was SAS and less.
And then we kind of settled on SAS,
but then we had a CSS,
which is SAS with more CSS syntax.
It's a way to like do slightly more powerful things in,
in CSS and minify it and have stuff like variables for,
they were available in CSS and,
and defaults.
And even you can do weird stuff like map functions.
And they use very heavily in bootstrap.
But the nice bit is because the compiler is written in C.
There's Libsass in Python,
where you can get kind of a front end customization without needing the whole of
node and the,
the whole dog and pony show of front end development.
Yeah.
Excellent.
It's got a lot of legs.
So when I saw this and I saw,
okay,
this is so for,
for web apps and it's kind of got this,
this Python code running that defines the backend and it's got the UI and it's all
a little self-contained.
One of the thoughts I had was,
wouldn't it be neat if there was a,
got a little bundler type of thing that made this into an electron app?
Would this be possible?
Can we get something that you could send out?
Or is this really just going to be intended to be,
you know,
kind of a friend of Django type of thing?
I have not used electron for a very long time,
so I don't pretend to be an expert.
What I will say is that unlike some of the other UI libraries,
we're not trying to do clever things with web sockets and do all of the,
all of the rendering requiring duplex communication between the client and the
server.
It's pretty simple.
It's like make a request and the Jason contains some information about how to
render it.
And then the front end goes off and renders it.
So it's the result.
What you get when you finish is very,
in terms of a networking point of view,
very,
very simple,
very conventional.
It's like make an HTTP request,
get back Jason,
JavaScript knows how to render it.
And so I don't see why it shouldn't,
shouldn't work in electron.
There's even the world in which we don't need the whole of electron.
And we could,
someone could go and build fast UI components for,
for whatever native library.
And we could get like native apps running that are based on fast drive.
not saying that's necessarily a good idea,
but like those possibilities exist.
It is.
It does exist.
Okay.
Yeah.
Very interesting.
Another thing that is convention,
I suppose.
I'll see if I can pull it out here is the UI.
A lot of times you'll have either just slash,
you'll have slash users,
but then you'll have an API that backs it.
And there's this convention that if it's in the URL,
if you have slash API slash,
in this example,
we were talking about before,
it's like slash table slash cities.
If you say API slash table slash,
that's the data endpoint.
And then if you drop the API,
that's the front end that then turns around and calls the backend with the API
inserted.
Right.
You want to talk about that convention a little bit?
So people kind of see where that's going.
So that's how,
how I've set it up in the default app.
It doesn't,
you don't have to do it like that.
And I think we're using a separate subdomain to avoid like path-based
routing and all that fun.
But yeah,
the,
the principle that the default simplest way of basically doing a,
excuse me,
a calculation to go from,
I've got a URL.
How do I get the data for it?
Is as I said earlier,
basically prepend slash API.
So maybe a more general way to think about it is for every page,
there is an endpoint that is a FastAPI endpoint or a pair of them.
Maybe even one returns the HTML front end stuff that makes it run.
It talks around and goes back to itself.
Right.
Yeah.
So what we have in the default app here,
what I would generally recommend is where are we?
We have a bunch of routers that connect and do all of the API stuff.
And I've just been implementing all,
which I can show you in a minute,
but that's not available.
There's a PR for it,
but it's not available in the demo you're looking at.
But then we have this like basically catch all endpoint,
which if nothing else has been hit,
will render the standard HTML.
And one of the nice things is that the Python library gives you this prebuilt HTML,
which will basically render you some,
render you the HTML that you'll get.
If you,
I went here and I view page source,
you'll see.
You just go to home page, yeah.
Returning.
Well,
yeah.
In this particular,
if I went to 8,000,
then it wouldn't be messed up by Vite.
You just get this very simple HTML,
which in turn renders the app.
So yeah,
there's effectively,
you're right.
There's two,
there's two,
there's like matching endpoints for,
for every view you might want to have one to get,
to return the Jason,
the one to,
to render the HTML.
But you don't write,
you don't write them both,
right?
You write the API one and then fast UI magically turns out into UI.
Right.
And whatever,
and this would,
all of most of this,
with the exception of the form submission would all just work out the box with,
with any Python web framework.
You just need to produce your financing model,
dump it to Jason and return that in a response.
But one of the really nice things about the,
this being the like actual data existing in Jason is that writing a test.
There's quite a lot here,
but you'll see most of it is,
is markdown.
So writing a test that our views contain what we expect them to is massively easier
when we're testing against Jason,
which we can convert to Python objects and tests than it would be.
If we've got an HTML page,
we're running a bunch of regexes for does this page contain the user's name?
Does it contain the word logout?
Blah,
blah,
blah.
Yeah.
By a right type of things or those types of tests.
Sure.
Oh yeah.
Even worse.
You end up with like play,
right.
And like play,
right.
That's an image of it and see if the image looks like the image used to look.
And yeah,
things I don't want to have to build.
I mean,
they have to happen occasionally,
but like we're,
and ironically we'll probably end up with them in fast UI to like even more
certainty that our components work correctly,
but hopefully that thereby avoid everyone else having to,
having to go and build.
Is there any concern that maybe there's unintended APIs in the sense that like
all of this stuff,
I'm sure this is probably true for pretty much any react site,
but like a lot of the page is available also as an API,
even if you don't intend it to be an API,
like what's.
Yeah.
That's a limitation of any,
I mean,
in some ways the data will be slightly less nice to.
Yeah.
You're right.
If you're a company that give people foreign exchange rates and you want them
to always come to your site,
you obviously can't render that with,
with react because there's going to be a Jason endpoint where someone can just
go scrape your exchange rates or whatever else.
Right.
But you can still do session based off and say you have to log in to do it.
Right.
It's not just that it's public.
It just,
there's always a Jason version,
but honestly,
there's so many interesting ways to pull data out of HTML.
Like,
yeah.
If someone's that valuable,
someone will do it anyway.
I also think that like,
in theory,
if your options are build pure react or do this,
and this has the,
the,
like,
as I say,
there's the realistic chance.
Someone's going to come along and implement a fast UI front end that,
that renders HTML.
And then,
and then you don't have to expose your,
expose those Jason endpoints at all.
And you could,
you could return HTML from your server.
We just haven't got around to building it yet.
Yeah.
I guess you could maybe do some kind of server side rendering potentially as well.
Exactly.
That's what I mean.
Whether it's Python server side rendering,
or whether it's JavaScript server side rendering,
or whether it's edge rendering.
I've tried to build a sort of edge rendering thing in Cloudflare years ago using Rust.
And for a bunch of reasons,
it didn't quite work,
but there's real possibility of doing like,
yeah,
any number of different things in that direction.
That's interesting.
Some of the CDNs have pretty dynamic stuff right at the edge,
where you can sort of put your last bit of code.
I haven't done anything with that.
That's kind of what Remix is doing,
and Next.js to a lesser extent.
But again,
in theory,
I mean,
maybe I'm overblowing it,
and Fast UI will remain what it is now.
But like,
in theory,
we've set up this language of different components that hopefully is,
whilst by no means universal,
complete enough that you can build lots of common user interfaces with it.
And then,
if it really gains adoption,
then people can go and build new backends and new frontends,
and they all,
in theory,
should be able to mix and match with each other.
We'll see if that happens.
Yeah.
And widgets too,
right?
Kind of like,
see a Tailwind UI create a paid thing for higher order widgets,
potentially.
Just being React already makes that,
that probably exists,
and I just don't know.
And there's been a number of issues of people wanting to render existing,
basically build extensions to Fast UI to render their widgets.
I think we will probably support the rep for HTML,
that things like Pandas data frames already returned,
so that you could,
for example,
return a data frame,
and it might not be pretty,
but you'll get something coming up as HTML,
and,
you know,
start ugly,
and then move on to doing those things in an even more powerful way.
Sure.
Yeah,
I didn't even think of the data science side,
but there's probably a lot of cool dashboard widgets connected to pandas and pullers that are potential out there.
Yeah.
And charts and visualizing data is something Pydantic is interested in.
There's no reason why a lot of them couldn't be implemented as Fast UI components and then displayed.
Okay.
We are running pretty short on time.
I feel like we should probably bring a little more Pydantic to the side.
Just talk real quickly about forms,
right?
What do you think?
Yeah,
absolutely.
So if you,
probably easiest,
if you share,
let me see,
share my screen.
I'll do it from here,
because I can also,
it's like,
you can show more behind the scenes.
Yeah,
yeah,
yeah.
It's probably most interesting if we,
if we look at the,
how the form is implemented in the code first,
and then we look at what that,
what that means for the UI.
So this is the,
the login form that Michael,
you were just showing here that I can show,
which is just,
so there's a login form with an email address,
password,
some validation,
basically like that.
Yeah.
powered entirely by,
again,
a completely vanilla Pydantic model.
And the way that we return that is we return three things,
heading,
which is like just telling the person what we're looking at here in the demo.
And then this third thing is the,
it's the interesting bit where again,
actually the model form is again,
generic around the Pydantic model.
And then it takes one other argument,
which is the submit URL.
And that's enough information.
Right.
So what you're returning as part of that hierarchy in Python is a model form
and you give it a Pydantic model.
And so it looks at the Pydantic class and says,
we're going to create like an email address and a password field and so on.
Right.
Exactly that.
Awesome.
Okay.
And then when you submit that form,
it's submitted as form data.
So is it not as,
as JSON data,
but as a vanilla HTML form,
a standard form post type of thing.
Post form.
And then we have this,
it's this syntax is definitely slightly funky here,
but,
but it's how we do it in fast.
You are a FastAPI.
We have form,
which is annotated as a login form,
but it's also got fast UI form,
which in turn,
which also takes login form,
all of which looks a bit ugly.
But what we're really doing in the background is converting form data into the Pydantic model,
including flattening and deflattening the model in the case where we have nested models,
which I'll show you in a minute.
But the result of this is once we,
in our,
in our post endpoint,
we get an instance of,
of the login form that we can then go do stuff with.
If I show you a more comprehensive or complex example,
this is big model here becomes big form.
And this has,
has a bunch more stuff in it.
So it has file inputs.
Now file inputs are one of the reasons we can't just submit,
submit JSON because,
Yeah.
Because we need a multi-part encoding and all those things.
Yeah.
All those things.
Right.
And so here we have name.
We use bold again,
as I have before to,
to indicate required fields.
So we could,
I don't know,
have got some Pydantic logos here that I'll use as images.
This one is multiple images.
So we can select multiple images,
a date field in this case.
I've got a calendar picker.
Very nice.
Is that just input type equals?
That's just input type equals,
equals date.
Okay.
We have switches.
We have,
and then you'll see here,
we have size model arrow width and size model arrow height.
And the,
the point is that we're doing here,
and these are integer fields,
but the cool bit is that they map to a nested Pydantic model within the big
model.
What fast UI is doing internally is basically flattening this into,
one list of form fields,
which is then what we get rendered here.
I see.
So in your Pydantic model,
you have a size object,
but then in the form,
it just has the width and the height,
the one after another.
Size width,
size height.
Exactly.
If I put a,
a requirement or a restriction like min or max onto the field in the size
model,
would that become a client side min and max in the form?
There's an open PR to do exactly that.
Yeah.
Awesome.
But obviously we will get server side validation as well.
And then for a couple of weeks.
So like it's,
there's more to do,
right?
But that's awesome.
That'll be fun.
And then you'll,
you'll see in uploads,
we have some,
some quite powerful things we can do here.
So we use the upload file,
which is a starlet type,
but we can also annotate it with form file,
file,
which takes two optional arguments of what rule,
what accepts to apply.
So that will both in the browser,
when you open the,
when you choose a file browse dialogue,
yeah,
it'll tell you.
You have a MIME.
So for people listening,
you have the MIME type set,
not like a extension,
but you have image slash star,
which means,
you know,
image slash JPEG,
PNG,
WebP,
et cetera.
Right.
And that's understood by the browser and then by the,
and then by the OS to,
to let you select files,
but it's also validated server side.
So if someone goes and edits their HTML and submits a not image,
the server side validation will check at least based on the file extension
that it,
that it looks like an image and you get back the bytes.
So you could also go do validation that the bytes are a valid image.
If you,
if you say you can read the bomb,
the,
the mark that indicates the file type that's sometimes in these different files.
Yeah.
If I submit this,
but let's say,
well,
first of all,
if I try and submit this,
because we've got server side validation of which fields are required,
it won't let me submit if this file field is not completed.
And then I think if we put a name and we don't capitalize it in this case,
we'll go off and do the validation and come back and we'll say,
name will start with the capital because I've implemented it.
Where's that validation?
Oh,
I see.
That's a function that you write.
Right.
So just to prove the point,
I've just written a validator in,
in Pydantic,
which says this must start with,
with uppercase.
And if I then went in here and edited that,
print out form,
is that going to now clear my form?
No,
it's not,
which is magic.
And if I submit that,
you'll see here where I printed out the form.
We got the,
we got the different file objects and we got the raw data all come through as a Pydantic model.
Yeah,
that's really cool.
And so I love how even the custom validators in Pydantic,
like Python code that you wrote appears on what feels like client side,
but is really server side validation run by React,
right?
Yeah,
exactly that.
so we'll do stuff like link checks and all the things you can do on an input client side as well.
But of course,
there'll also be,
be enforced server side,
which obviously if you're building anything that you're going to be exposed to the internet,
you've got to do.
Yeah,
you should never,
never trust what comes into your web app.
It's just put it online for five minutes and look at the log.
It's already trying.
Somebody's already after WP admin.php,
you know?
Yeah,
exactly that.
And then the last thing I'll show,
I know we haven't got very long at all is authentication,
which I've just been working on now.
This is,
again,
it's a simple form.
I'm just going to select an email,
put in a random password and I can log in.
And in this case,
I've logged it.
It just says who I am and how many people are logged in.
If I come back to this page,
it'll show me logged in and I can do post requests to log out.
And what it's doing internally is,
and again,
this is the kind of thing that would be lots and lots of work to implement if you're doing it yourself,
is it's storing in session storage,
the auth token,
then adding it as a header where we do the fetch from the front end to the back end.
So we can effectively store,
store sessions that way.
Oh yeah.
Very cool.
Yeah.
That auth token's coming in as a header item or being set as a header item.
Excellent.
Right.
Exactly.
Cool.
So yeah,
I hope that we've done a bit of a whirlwind tour through,
through fast UI and what's there now and what,
what I hope is coming up and the like slightly philosophy of how,
why I,
why I built it.
But yeah,
that was interesting.
It's super interesting.
And it's really early days.
I'm,
I'm looking forward to two things to see what people go do with it,
what widgets and stuff they build.
So,
you know,
can you drop in,
like you said,
a calendar or something awesome like that.
And I'm also looking forward to see what you all internally release in a couple months.
Absolutely.
Yeah.
Thanks so much for,
for having me and letting me witter on about,
about this,
this random library.
Yeah,
of course.
Good work.
It's certainly creative.
Maybe just give people a sense of,
you know,
as we wrap it up,
can they use it now?
Should they use it now?
Can they contribute?
Maybe they're interested.
What do you tell that crew?
I'd love people to contribute both.
I mean,
almost most useful is,
it's issues saying how you're using it,
where it's working,
where it's not.
There is a bunch of people who've already submitted PRs and,
and continue to do so.
And yeah,
I think what works works pretty rigorously and it's probably better implemented and tested than lots of like private code,
but definitely within internal uses,
use it now.
And like I say,
Pynantic is building things,
building things with it now.
So look,
I mean,
I'm not,
I give the open source guarantee that it's relatively safe,
which is the guarantee that means nothing.
But mostly because at the end,
it's just defining how you build your UI and how you implement your session authentication.
It's not having strong opinions about that.
So yeah,
I think it's,
I think it's the place where people should go and try it and give,
give feedback.
Excellent.
All right.
Well,
thanks again for coming on the show.
Looking forward to talking to you next week.
No,
just kidding.
Like two in a row.
I suppose.
Looking forward to talking to 2024.
Absolutely.
Have a good Christmas.
Thank you so much.
Yeah.
Thanks.
Bye.
This has been another episode of talk Python to me.
Thank you to our sponsors.
Be sure to check out what they're offering.
It really helps support the show.
Bright data is professional web scraping and a dataset marketplace.
If you need data and it doesn't have an API,
check out talkpython.fm/bright data today.
Take some stress out of your life.
Get notified immediately about errors and performance issues in your web or mobile applications with
Sentry.
Just visit talkpython.fm/sentry and get started for free.
And be sure to use the promo code talkpython,
all one word.
Want to level up your Python?
We have one of the largest catalogs of Python video courses over at Talk Python.
Our content ranges from true beginners to deeply advanced topics like memory and async.
And best of all, there's not a subscription in sight.
Check it out for yourself at training.talkpython.fm.
Be sure to subscribe to the show.
Open your favorite podcast app and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes,
the Google Play feed at /play,
and the direct RSS feed at /rss on talkpython.fm.
We're live streaming most of our recordings these days.
If you want to be part of the show and have your comments featured on the air,
be sure to subscribe to our YouTube channel at talkpython.fm/youtube.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
I'll see you next time.