Live Code Review | FastAPI

Key Takeaways

good afternoon morning night everybody wherever you are welcome to the under the hood live stream today I'm really excited to um have you again with me and we're going to look at some code today just have a good time I hope you're doing well let me know if you're here in the comments let me know where you're from um let me know if you had a good year 2024 it's just a few weeks until it's Christmas in the end of the year so uh I hope you all had a good year that you learned a lot that you made some progress in your life in your career as a developer uh just let me know in the chat section now as usual we're going to take a look at uh some interesting open source Library I have my uh three envelopes here A and C we're going to pick one randomly and then we're going to take a look at the code and see if we can figure out some of the design aspects of it if we can find some interesting things to talk about uh as always I have not prepared this I don't know what code I'm going to take a look at so you're going to see my reaction live if you see something uh that you think is interesting for me to take a closer look at just let me know by posting a comment in the chat and then I'm going to take a look so what I'm going to do as a first step is I am going to switch to my code editor there we go and I have my random picker here and and let me just run that and see what we are going to get so apparently we have envelope C so let's see what is inside envelop C what are we going to take a look at all right then that's a big one we're going to look take a look at the fast API codes interesting interesting I'm really looking forward to that uh let me see if there's any messages in the chat so there is uh ala from Iran great that you join here Sergey from Ukraine welcome IRC hi and fips from Germany John Eve as well hi great that you're here thanks for joining okay let me switch to the browser and we're going to look up the code of fast API uh which uh is going to be interesting to take a look at of course uh lots of people are using fast API nowadays I remember when I did the first video about it was like I think two years ago or something uh when not that many people are using it actually and it's grown like really popular it's very interesting um okay so I'm just going to Google this fast API Python and perhaps okay so here we have the site and then I'm just going on GitHub so let's take a look together at the at the code maybe we can start by just take taking a look at like the overall setup in GitHub and see if we can uh get an understanding of that um so the first thing is so of course you can see fast API is like really popular it has like 70 87,000 Stars which is insane um uh the license is also interesting that's an MIT license means you can just use it commercially for free which is great and uh what else do we have it's also interesting to to look at the releases right so there's many of them uh actually there's uh uh uh one guide Tango that's uh mainly maintaining this I'm not sure how many other people are contributing so there's quite a few few contributors also which is really nice so uh yeah some refactors I don't I don't want to go through all the release notes but it's always interesting to see what is actually happening here so uh lots of smaller updates translations yeah yeah nice okay so um what else do we want to look at before I actually take a look at the code um I think with fast API things like the documentation everything they're going to be in order which is nice I think what's also nice is that fast API is a pretty newish Library it's not like I don't know the request library or something which has pretty old code fast API that's pretty recent so I also hope when we take a look at the source code that we're also going to see some more modern python features usage I thinking particularly about things like um um oh wait for some reason my camera is resetting just give me a minute there we go um so in terms of modern uh python features would be nice to see of course things like type annotations but perhaps also uh generics and uh things like that so I'm going I'm quite curious about that okay let me just uh check out the code so uh just give me a minute and let me switch to my IDE and then I'm going to add the fast API folder all right so so here we are uh let's see few other people in the chat uh Abby from India Anan from India as well and uh code python Pro from Spain great that you join very good very good all right so let's take a look at the code and see if we can figure out how fast API actually works so one of the things that I remember is that fast API actually depends on a lower level framework for managing the actual backend server and that's Starlet if I recall correctly so we have here the pipe project file I think that's a good point to start so we can have an idea of what are the kind of things that fast API actually depends on so one thing that is interesting is uh it requires python 3.8 or newer also mean means that um there's going to be some features that it won't use like uh like the python generics that were introduced in Python 3.12 for example and I believe python 3.9 also introduced quite a few features that I use regularly I don't exactly remember but 3.8 is relatively old I'd say but of course if you have a big commonly used Library like this you also have to make sure that you have compatibility with all the python versions because well quite a few people still use those so that's always a balance you have to look for right okay let's see what else we have so we have here uh the starlets dependency that's uh what I was saying so this is the um the package that it relies on for the lower level uh server that that it's actually running and there's of course pantic which is used for all of the models that are being used in Fast API and for um representing the responses and etc etc and then there's typing extensions as well so um hope we're going to find out how fast API is actually using these things uh we have a few others here um optional dependencies okay so there's CLI I haven't used that actually fast API CLI would be interesting htpx okay for the test clients there's Ginger too for templates okay we have some things for forms file uploads if you need those things of course uh uvicorn used to running the server and then here we have uh a couple of other things as well o Json response I'm not exactly sure what this is actually if you know what this is let me know in the chat I haven't used this okay so this is interesting um so there asked why fast API is much quicker than flask and Django so I think the reason is that Starlet is actually highly optimized uh library for uh apis and fast API is basically built directly on top of that so that's why it's really fast because Starlet is actually really fast I'm not sure fast API actually does kind of lowlevel optimizations itself for uh for for running the API server not entirely sure maybe we can find out by look at the code later on but I think the main reason it's faster is because of Starlet uh actually uh we can probably see that if if I look for the project itself in Google so Starlet you see it's a really uh it's a lightweight framework um so let's see if uh what else it says so yeah so it has great performance I I think that's that's the main reason fast API is fast um yeah so M mat says quicker for what development speed it's slower than D Jango once your app gets bigger you'll spend 90% of time implementing features you get included in D Jango yeah that's actually always like a tradeoff right and I I think it's the also one of the reasons why some people think I don't know python is like a a toy language or something you know where people are like oh don't use Python use a real language like C or uh something like that and there it's also like okay maybe a language like C or rust is way more performance than python for sure I mean it can make a huge difference but if you're developing software in Python it's slower for sure in terms of execution speed but it's much faster in terms of iteration speed so you can just code up something really quickly and make an iteration and improve your code very quickly and I think that's a huge win for uh for working in Python and I think that's also why you know you have these uh I think that's like once a week somebody post on LinkedIn this chart with the least green programming language and python is somewhere at the bottom but that purely looks at efficiency and I don't think that's correct because if you're developing if your iteration time is much faster if you're able to improve the code much faster you're also going to be able to simplify your code much faster and make design changes that are going to make your code better and more efficient overall without even thinking about performance uh so I think that's uh you know that's you need to take a look at a at a complete picture and I think something similar happens with Frameworks like Fast API or Django so Jango is of course way more complete right there's lots of extra features that fast API doesn't have because it's a more basic limited focused framework and that all depends on what what you want to do like if you know beforehand that the main features that you're going to need are all in Jango yeah why start using fast API and having to build all that stuff yourself it's just a waste of time right but if you if you know that okay I I need something very basic very performant I need a lot of control because I want to do you know a lot of special things then it's often better to start with a more basic framework because that simply gives you more control so that's always yeah that's the cost of uh of of of of making those decisions and that's why being a senior engineer it's I think that's one of the most important things you learn right make those decisions where do you give away control for uh faster development time versus where do you actually go bit lower level give you more control but it also means you're going to need to spend a bit more time on development anyway back to uh fast API it's more of a side note so so we have our by project file I just want to take a look at the actual code and see where are we going to start so first and I think this is one thing that fast API does really well and that is unit test and test in general so you can see that uh there's a test folder uh we have uh lots of lots of different tests uh fast API uses spy test for that um and um yeah I'm I'm not going to go through all the test in details but you can see that how it works is uh creates a test client this is a test client and then there is some uh get requests that this test is is going to check is going to check uh it creates uh some okay so that's interesting it creates some data that's being used for this particular test client and then let me scroll down a bit more uh and then you see that it calls these things uh using a parameterized test which is a great way to feed multiple uh test data points to a test function and then it's just going to assert that it gets the right status code that the Json is what it is expected Etc so it's a really really good setup for testing and uh let me just check so this is test annotated and then if we go to the source folder which is in here so um ideally you would have each file here uh correspond to also a test file so I don't see the annotated file here so this is probably more of a higher level test but if we look at the rest so we have um a bunch of uh of extra files here uh so there is for example test path test query and do we have those things here as well uh yeah so there not like a direct match between these module names and the test module names if you're writing unit test it's something that I would recommend so um try to keep the structure of your test folder similar to the structure of your source code because that way it's really easy to find the actual test um okay that's about unit this maybe we'll revisit this folder later on uh there's another folder here scripts and there we have some shell scripts so looks like these are mainly used for um running the test yeah that's what you see here we have uh linting um so this also interesting so fast API uses rough now uh which is really good and another thing that I noticed so there is requirements at cxd there is a project file I'm not really sure what kind of um that can use other this PDM okay okay so it use PDM uh can we also see that in the GitHub actions so there's workflows we have here different workflows for publishing this will publish it on uh pii probably yeah so that's uh that's exactly what you see here so um interesting thing uh is that this actually uses python 3.10 so it's not 3.8 3.10 I'm wondering why that is it's very hard to keep all this consistent by the way okay and then we have PDM builds here that actually seems to do what does this do build initialize okay so this get some uh meta data custom config from environment variables okay so I must admit I haven't used PDM myself um I've now switched actually completely to UV uh that works really well actually I record a video about it two weeks ago uh so we're currently uh editing that that's going to come out next week so stay tuned next week for a video an in-depth video about UV I'll share my thoughts about that I spoiler I think you should switch to UV from poetry if you're ready for that so to say okay let's go back to the code so we have all of these uh files here uh the GitHub action uh then this is where we have the actual code so let's take a look at some of these files so maybe data structures that sounds like something relatively basic to start with um this Imports a bunch of stuff from Starlet so there's a URL there's address form data headers Etc um and then let's see what do we have okay so we have a class upload file that's a subass of Starlet upload file and what does this actually do okay so this adds um some members like a file name a [Music] size and these things are annotated yeah okay yeah okay so that adds annotations like in in this case documentation yeah so this seems to be a pretty minimal wrapper around uh the data structure yeah and that just calls the super methods but it adds some extra information yeah okay and we have validation this also interesting right so some of the methods are are not available if you're not using the new version of pantic um and this is actually quite uh quite an interesting pattern so we're using it's fast API use an if statement here to uh optionally define a class method so some of these methods are not available if you if you're on an older version of byen it is kind of hard I think to keep track of the methods that you have that are actually there U because some of them might not be depending on the baning version and I'm curious to find out if the IDE actually understands that if it's actually going to know that okay this this method is not going to be there that might not always go right um another thing that's also compatibility is you see this still us is the uppercase dictionary so in more modern versions of python you would actually write this uh but I think that has something to do with compatibility with python 3.8 okay let's take a look at another file so that was Data uh data structure then uh let's see let's go to exceptions that's always interesting as well so here again it looks like we have a class wrapper around the Starlet HTTP exception so it seems like uh it's it's almost like an an uh an adapter layer around Starlet by using inheritance that's probably adds like uh type annotations documentation these kind of things because I expect that in Starlet that's not going to be there right so if for example if I take a look at this the http exception so this is from Starlet and uh let's see so Starlet actually does use some typing which is interesting so it do use typing um actually not bad it even returns has a like a non return type which is pretty clean and there is optional types so this is actually pretty pretty good this is pretty good uh but what fast API adds is it adds the documentation and that seems to be mostly it so it's really just the wrapper to add documentation and is that the same for the other exceptions as well so there is some things here that are commented out oh this is the documentation sorry uh yeah so there's an example yeah so it's these are really wrappers to add documentation um now I'm curious so where does the new stuff actually come in so we have these wrappers around basic things like data structures and exceptions uh there is okay very simple logger we have um some imports that are being used so these are mostly these are also looks like mostly just wrappers so let's see what else do we have here uh I think the middleware section might be interesting to take a look at like a course for example okay that's actually also just uh an import and these ones are as well okay so this is after all not that interesting to to take a look at okay so what I find interesting is how much it actually relies on Starlet it's basically until now what from whatever we've seen it's it's a pretty lightweight wrapper around startet right so I'm wondering where is the stuff that um go my camera is keeps switching on I where is the part of fast API that actually adds all the um the type annotation analysis and so on let's see if we can figure out where it is what is applications okay this is definitely a bigger file so this should contain a bunch of new things okay so there is the fast API class that's the entry point that's the app that we create which interestingly is also a subass of Starlet so it does seem like the design of the the way that it wraps around Starlet seems to be focused very much on inheritance I think another option could have been to have the class fast API have an an object of type Starlet because now actually fast API also exposes all the features all the methods of the startet class and that might not be something that you want right depends on how you plan to use this obviously because this basically means that you can go beyond the documentation and actually just interact directly with startlet which might be nice if you want to do some lowlevel work you might want to access directly things in Starlet but I think it's also nice to have a sort of clear separation a clear boundary between the low level thing which is Starlet and fast API which is a a more of a higher level wrapper around that uh so let's see what else do we have here there's again more documentation so course fast API is lot of documentation um I think later on I want to take a look at how documentation is actually used from the code to to generate the documentation that's going to be interesting as well okay so most of the contents of the file you can also see that here on the right is actually documentation um so where is the where is stuff actually happening so here there is something happening okay so we create a router that's uh lots of passing around of [Music] arguments okay I'm just going to scroll down a bit faster because there's a lot of rappers here it's pretty extreme uhuh okay I think the problem with a rapper like this is of of course fast is highly dependent on Starlet right if there's like a major change in the Starlet Library well fast is is going to need to update the code quite a bit the issue with having fast API be a subclass of Starlet is that any users of fast API are also going to be affected by changes in Starlet and that's kind of a Pity in my opinion I think if you expose a more limited set of classes and meth me to your users and things that are more straightforward which I think is also the main goal of FIA to to simplify things then you could hide the Starlet details behind that encapsulate Starlet basically and that means that changes in Starlet are going to have less effect on the end users of fast API so if I were to develop fast API which I I don't right and to be C it's it's a an amazing job that uh Sebastian has is done with fast API I would probably start with making Starlet an object that's part of fast API using composition instead of inheritance but I don't know what what do you think would that be your approach as well um yeah so uh code python says automatic documentation is one of the things that fast API built yeah so we're going to take a look at that later and see how that works so a lot of this is documentation um and it also just goes to show how important that is right proper documentation is really important not just for developers but in particular for users so it's good that uh that he spent the time on that um and there's more here so these are also documentation on background tasks um let's see param functions that might be this might be the part where it accesses the the typing information let's see if we can figure that out so here I have a param file so this this is actually a class param which is a subass of field info that's from pantic all right and okay so there is some uh penic V1 deprecation lots and lots of arguments let's see if we can figure out what this actually does so um this okay so this seems to modify some of the schema details of pantic let's see if we can understand what is going on here then we have we have the bath class which is a subass of param and param if I recall correctly that was the class that was defined here yeah so we start to have a sort of layers of inheritance [Music] here okay yes I'm I'm not a fan of initialized that have this many arguments that might be just because of the underlying structure of pantic I'm not a fan of that uh it's very brittle because it means that any change that happens in one of these super classes especially in in these arguments uh it's it's going to affect all of the sub classes and that's tends to become from uh bid messy if you're not careful okay let's see yeah that's basically the same everywhere so we have uh query which is also a subass of param and there's this seems to be some um identifier type so that we know that it's a query okay so this is basically a redefinition of all of these different parameters and okay I'm not going to look at the rest because I think this is going to be the same for most of these I think that's also a problem right if you have this many arguments and you have this type of inheritance structure it means that all for all of these sub class you have to redefine all of these values and then uh call the super class and and then pass all these things around so there like it's on a boiler plate code here I'm wondering if there is maybe an easier way to do this so here we have functions so are these just there again for documentation purposes it looks like it it looks like it okay boiler plate City I would call this boilerplate city that it's it's really hard uh because I I totally understand the need for adding the documentation but it also adds like a ton of boiler plate I'm wondering if there is like an easier way to do this cuz this is like a complete to to manage but I get it it's it's hard this is hard okay I'm looking for okay types St is that something I'd like to know where the decorators are being defined that you use as part of your fast API app is that here maybe routing let's see okay lots of imports um okay this is more about dealing with the with the model depending on the data type it does different things to the to the response also this part might actually do the automatic conversion from different models to actually the Json response data that's interesting um and there is lots of is instance checks uh code Pon you're writing for those aggressive if statements I'm I'm not sure if you if you refer to these ones I mean this does look like something where a strategy pattern could could work or you could perhaps create a dictionary that Maps types to uh specific actions so then you won't have to do all these instance checks but you can simply do a mapping I think that's one of the most powerful ways of using dictionaries in Python actually uh let's see okay serialization okay so that calls this prepare response content okay so this is more about the the actual response uh uh then so this seems to be a file where there is a lot that is happening uh and it's not just about uh more documentation this is where things actually happening okay and it actually it would have been helpful to have a bit of documentation here like what what is this doing like what is get request Handler doing right so uh there's a lot of focus in in the in the code about generating documentation for the end users but I think it would be helpful to have a bit more documentation for developers especially in this file and also there's lots of indentation here we have if statements containing other if statements uh and that makes it kind of hard to read um so for example here there is a check like if there is a body field then this is what we're going to do you can also Swap this and basically say that well if there's not a body field then we do a continue or a break or a return depending on uh What uh on on what you need to do in the function right and then you can reduce the ination of all of this part and you can also simplify often uh if else statements like this by uh instead of having an if else that's so this is the simple form right that here actually write a return and then this whole part you can de indent and if you go through the code in that way you can reduce indentation it becomes more of a step-by-step process and that's typically a bit easier to understand okay so then we have exceptions that map basically to the different types of exceptions that we have okay so validation error oh yeah so here you see that these errors I get quite a lot if I'm using fast API so we can also see where it's coming from yeah okay um let's see what else can we take a look at here um so if you look at the codes like these uh functions are pretty long there's again quite a bit of boilerplate code in the sense of passing around things right so we we store things in in the instance like all of these these things um I think that's also dangerous it sort of uh complicates things if you have this many arguments and I think that's that's an issue in in other places in the code as well so you could solve that by structuring the data more uh for example a response model has uh include exclude by Alias exclude onet etc etc so this itself could be an object and then you don't have to write all these lines you have a sing a single line to actually set the response model options um another thing you can do is maybe think about whether you really need to store all these things in the self object maybe some things are not necessary and you don't need in the in initialization state but you could pass uh at a later stage or you could split out the the options completely and maybe we don't need all of that information in the API route but that's simply a separate object that contains the information that sometimes we pass along there's lots of different ways in which you could approach this but I think this is a lot of data to store in a single object and that also results in the the the method being quite long right here you see that uh the initializer is quite a few different lines and that also makes it a bit hard to read um one thing you could already do is like split out some things and not put all this stuff in the initializer method but perhaps make this for Loop for example a separate function call because this does seem to be doing some specific things like um adding an additional status code so that could be a separ methods to kind of structure things a bit more um okay let's see and then okay so this is a helper method to get a request Handler and there you also again have to pass all the data I think that's like one of the hardest things to solve in design like how do you make sure that your classes your objects are struct structures in such a way that communication is limited that you don't need to pass like hundreds of arguments to functions and it's really hard to solve especially in case of a complex Library like uh fast API but if you can do that well it's going to make your design way less brittle because you're going to have to way less information that's that's passed around um and instead of trying to solve design by using inher several layers of inheritance which often just makes the problem worse a more functional approach can sometimes be helpful because then it forces you to think about how data flows through your application and by thinking about your design in terms of functional Concepts like uh functions and uh higher order functions things like that you you you force yourself to think about okay how can I design it in such a way that the data flow is optimal that I don't have to pass around too much data everywhere and that's by taking that approach it might lead to different design that can be a bit easier to deal with than than what you can what you see here okay and then we have the the API router so I'm still curious where uh if I can figure out where these things are defined uh these uh decorators is there a decorators file here let me see if I can find that I'm guessing it won't be here yes this is the dependency is this the dependency injection framework okay I'm getting sideline now um here it's probably also not routing did I take a look there already no this is again not what I'm looking for utils just curious if fast API uses a context manager maybe we can find it that way um um okay yeah yeah yeah okay okay utils okay I already had that open so uh no wait fast API dependencies utils okay I just want to open it this way might be a bit easier to read so is this where we can find this just scrolling down see if we can find that [Music] doesn't look like it um okay okay so this is really seems to be more like a wrapper to help with generators I'm not entirely sure what this is supposed to be doing um what I've forgotten myself into is this something no okay okay I want to I'm I'm I'm going to look at something else because this becomes a bit much um what I'm I'd like to see is maybe we can take a look at the documentation framework so uh that comes from uh typing extensions that's interesting okay so this is a uh documentation class I haven't used this actually uh so that's that is actually interesting so what I'm just going to do is I'd like to figure out what this is exactly so here we have the typing extensions module [Music] um so is there something here about doc okay yeah so here this is what uh what fast API is using yeah so uh um you can use doc to Define documentation of a type annotation okay that makes sense okay I thought it was something that perhaps fast API developed on their own but it looks like that that is actually from type annotations so is there can we find in the docs something about how this is being generated so uh here we have doc source so are these tutorials yeah so these are examples that are used by fast API interesting and then we have the actual documentation just going to open the the English version of that but it's uh it's interesting that uh there's a lot of documentation in different languages here which is nice um even in Dutch okay that's maybe not so much or is it here oh yeah okay so there's there's Dodge documentation I'm I'm proud of my country now I'm really proud of my country okay back to the English docs so this uses make docs I've also used that in the past it's quite nice actually um yeah so all the actual documentation that's in here um so this is where where everything is um okay let me close that up so let's see what else do we want to take a look at if you have something in specifically that you'd like me to take a look at just post it in the chat just let me know let t clients oh again lots of imports and simple wrappers around Imports so in the end okay there's compatibility yeah okay okay so this seems to be actually a lot of the uh scaffolding around pantic schemas that's interesting okay so then yeah so these are U model Fields so this is like a wrapper on pantic mhm okay just scrolling down a bit more yeah so these are basically two versions right we have the old pantic and the new pantic I'm still not entirely sure why you would want to keep these two versions I mean it would make does it make sense are there people who would like to use the new Fast API but with the old pantic because that's what you would then use it for I mean the more straightforward way to do this would be to Simply upgrade to penic V2 in fast API but that might actually lead to some compatibility issues if you really want to support older python versions or uh if there is a clear reason why people would still want to use the old pantic I'm not entirely sure I'm not entirely sure but yeah it's um it's it basically uh it's this is a compatibility layer it looks like that overrides most of the things from penic V1 and makes it more like penic V2 because there is also the model dump uh method for example that then uh uses this because but of course in pantic V2 this is uh deprecated pance even gives me an error about that or a warning okay yeah so lots of uh compat ability code um so my overall feeling of this is is it's a pretty thin layer around Starlet there's lots of uh Imports that are then just being overwritten maybe adding some documentation which is good which is good there's nothing wrong with that but the actual fast API code is then concentrated in just a few files like um uh like where was I like the uh like the the data structures file for example or um there's like a couple of files here that actually contain all of the fast API code and it would have been nice if that would have been like split up and organized a bit more and if that part actually also contained a bit of documentation I also not sure about the using inheritance this much to basically create a sort of inheritance layer around Starlet I would more sooner opt for a simpler interface to the outside that would hide actually the the implementation details of it using Starlet I think it would make the overall design a bit less brittle I would split up functions more make them smaller um split up into more separate files so we have a better overview of how everything works together uh that's that's my overall feeling about the code but that being said it's of course also a a a very big library in a sense lots of people are using this so you need to think about compatibility um you need to make sure that it contains all the features that you need an API engine like Fast API to to to have so I I I kind of understand I I I understand that it is complex and it is hard to design something like this but I think reducing inheritance might help a bit with keeping keeping it yeah more uh a bit cleaner a bit cleaner but I don't know what what do you think about the design what do you think actually I'm going to start a poll and I'm going to let you grade the design and I'm going to give you three options where the first option is the worst design ever and then we have two and then we have three which is the best design since Dutch sliced bread and I'm going to start to pull so let me know what you think what are your thoughts about this design worst design ever average or the best let me know what you think now that you've looked now that you've seen the code would you actually continue using fast API or would you consider switching to Starlet or you don't really care how it works on the hood let me know what you think I mean I'm not going to stop using it to be honest I think it's still a um it's it's still a really really nice Library I I mean I'm I'm using it quite a bit in in some of our own backend systems so to me it's it's a really useful tool and I think the added documentation that's on top of Starlet is is really good that's really helpful and of course it also introduces some simplifications right by having uh decorators uh having type annotated end points so I I do think in terms of usability fast API is actually really nice which is makes sense because uh lots of people are using it for exactly that reason um I I do hope uh it also gives you an idea of like if you look at some of these packages that these are being developed by normal people the design is not going to be perfect uh there's going to be mistakes in there there's always going to be things to improve I mean I'm not a perfect designer either right if if I create a package or I work on something code it's also going to contain mistakes and uh I'm going to make iterations on the design and improve things step by step and that's that's just part of the process I think part of the process of learning of of doing coding is that while you do it you learn about the domain you learn about how everything fits together and that leads you to new insights which then means you are going to make changes to the design so the refactoring part is a really important aspect of software design uh it's it's software design in that sense almost like an emergent property of doing coding because by by coding we we get a better understanding of the problem because we're we're modeling the problem by writing code and by modeling the problem we get insights and we can improve the model and that's why it's so important that if you work on code it's not just about getting things to work it's about refactoring that work and improving things because that's how you learn the most about the problem in my own experience so uh I hope you enjoyed this quick look at fast API and let's take a look at your responses so we have um most people think this is a two I think I agree with that yeah there's definitely space for improvement but we should also so appreciate the fact that fast API is actually a really nice library and works really well so uh it's it's for for that reason alone design is not just about how the code is structured it's also about how as an end user you interact with the code and I think that part fast API obviously does a really great job at so uh in short I think this was uh really interesting to look at um um it's the last under the hood session for this year um I uh I really enjoyed doing these live streams with you guys I hope you also enjoyed watching them U hopefully you learned a bit from these live streams and uh it helps you also to look at your own code maybe slightly differently so uh I'm going to close off for today like to thank you so much for joining um wish you a great evening wish you also great holiday season I hope you have uh some opportunity to spend time with your family and friends and enjoy the end of the year and uh that you have lots of plans for next year this Friday there's another video coming out um so check it out uh it's it's a nice one I think you'll enjoy the topic and like I said next week is going to be the UV video which I'm really excited about so thanks so much for watching have a great evening and talk to you soon bye-bye