Why Python Devs Are Ditching Raw Drivers for Beanie

0:00Hello, hello everyone. Thank you all so much for tuning in. So why don't we go ahead and we'll get started. So this is a super, super exciting episode today as we have Ramon, the creator of Beanie here to chat with and we we are going to be covering some frequently asked questions about the Python library. You're going to chat all together, go through a hands on demo and then leave some time at the end for questions straight from all of you, all from the audience.

0:31So I'm going to go ahead and I'm going to turn it over to Roman and allow you to introduce yourself. Hey, hello, everyone. Thank you. Thank you for having me here. Yeah, I'm Roman. I'm a software engineer. Currently I'm working at Microsoft as a senior software engineer. And he has a reason why I'm here. A few years ago I've created a binodem. It's ODM for mongo DB that uses identic and I mongo and motor in previous sessions. So that's it. Awesome. And now over to you, Shubham.

1:08Hey everyone, hope you're doing well. My name is Shubham, I'm a product manager at Mongo DB for our Python client libraries. I primarily own. I mongo now duplicated motor I mongo aero and recently launched Django mongo DB back end library. Looking forward to a live stream. Perfect. And how about you, AFY Hi. Everyone, I'm afy, I'm a dev advocate, I'm mongo DB and I'm specialized for jungle and Python. Awesome. OK, now that we're all acquainted, let's go ahead and jump into our agenda for today.

1:43So first, of course, it's a very small agenda. We have some housekeeping that we're just going to quickly go over. We are going to chat about the Beanie ODM library. Roman is going to take you through the hands on demo. It's super, super cool. If you have any questions, please leave them in the chat and then we'll see if we're able to get to your questions during the live stream. But we're definitely going to allocate some time at the very end of the live stream to answer any questions that we may have missed and also give all you have some fantastic resources to learn more.

2:20So here is our housekeeping. First and foremost, there are absolutely no bad questions. So please use the chat feature and we will answer your questions at the end. So you can chat from either YouTube or LinkedIn, wherever you're watching from. And even if you you know, if you miss the live stream and you watch it later on on either of those platforms still, please feel free to answer your questions and someone from the Deborah team or another team will definitely try to answer your question.

2:52So let's get started. Let's start off with some intros about what beanie is so Roman. For those in the audience who may not be aware of what Beanie is, can you please quickly explain the Python package? Yeah, sure. So Beanie is Object Document Mapper ODM. Probably people face things like, I don't know, it's called Alchemy for POST, Graysqual and and so on. So Bini is mostly making the same thing. It's mapping item objects to structures that are stored in the Mongo DB itself and manipulate with them.

3:37Like it can search, it can update, it can remain and it can aggregate data. So in general Bini is simplifies developers life and it supports like more platonic way to manipulate data in mongo DB. Awesome. Thank you for that, that introduction and that explanation. I have another quick little question because you mentioned what ODM is. So I just wanted to ask, you know, either Ramen or Shiva, whoever wants to take this one, what is the difference between an ODM and an ORM? So I'm sure a lot of our viewers and listeners, they probably are more familiar with what an ORM is. Yeah, happy to take that one.

4:23And ORM literally stands for Object Relational Mapper. It basically maps the objects in your code to rows and Collins in a relational database. And ODM on the other hand is an object. Document Mapper maps the objects in your code to documents in Mongo DB. I think functionally they do the same thing for developers that let you work with native language objects and queries instead of writing either SQL for all MQL commands. The main differences in underlying data model relational versus document based. Very cool.

4:56That's a fantastic, fantastic explanation. Anyone who's watching has any questions about the differences between an ODM and an ORM, please let us know in the chat and we'll get to your questions. But kind of going off of that, back to you, Roman. So what was the motivation behind creating this library, especially because we already have some Python packages such as motor and Pymongo that already exist. So how are you hoping to have Beanie stand out from there? Yeah, for sure there are drivers like Pymongo and motor, but it's a bit low level like people have to work with as Shuman talked with various directly, while actually there are Odms is spelled like Mongo engine.

5:43But in the time, by the time when I was creating mini like it was 4 even five years ago, there's a very no asynchronous ODM for Z for Mongo DB at all. And I was working on my projects or some personal pet projects and I decided why shouldn't I create one And that time it was raising off fast API so identic stack and I decided that it's everything should be must be compatible so and I created vini on that stack as well. That's awesome. So can you go into some of the really key design principles that you kept in mind while you were creating Vini? Yeah, sure.

6:28So every I wanted to first of all to mimic everything as possible from motor, from from Pymonga. I mean, all the operations should work exactly the same, but with some abstraction level. What does it mean? For example, if operations are atomic would be done in a single shot in a single comments to Mongo to be it must still stay atomic because otherwise we will have race conditions and other problems. Is that developers we'll never know about and we'll have a lot of problems because it's super hard to debug. And only when all those features were implemented, we added more and more on top using this basic. So this, this was just a general principle. And yeah, for sure, we always communicated with the with the community because honestly, my own usage scenario, not that rich as users suggest, like we need to do this, we want to do this and so on.

7:38And like every time, it was great ideas to add features to to Benny loved. That thank you for going over that. So kind of from from your answer, I wanted to ask how does Benny's async first approach really change the way that we not only model but also query our data? I can say that so it is just modern world of Python. Unlike everything it should be and must be asynchronous right now. And interacting with Mongo DB is, you know, book example principle like when we have to use such because it's IO operation where we have to call to wait what's going on on that side on the Mongo DB side and consume the response from Mongo DB. So if we will use blocking approach, synchronous approach, we will lose a lot of like we can do everything in parallel with asynchronous with and it's very cheap because we don't have to create any threats and so on.

8:45We just can use asyncrovate approach for that. And yeah, this is just modern and it gives us much more resources to be used. Yeah, just wanted to tailwind on what Roman said. Like sometimes I've seen some users using async even though they're not really should be using like it. It should only be using async when you really have like Roman said like out blocking codosome blocking operation. Very cool. And I have a question for you ship on too. So I know that you know the adoption of fast API and Mongo DPR is rising among Python users as like the main PM.

9:31Have there been any particular trends that you've observed from your side even with Beanie? Yeah. The. Few things that I've noticed I mean, like both Mongo DB and fast API are super, super popular. And as like I've been tracking this space from last few years and every year this stack is becoming more and more popular. And now there was a term called farm stack with like fast API, React and Mongo DB. In terms of trend, like I'm really seeing a lot of new AIML application that is being built are using fast API and and you know, on the database side, Mongo DB is one of the top choices among other databases just because we have added native vector storage capability as well as now with our voyage AI position, you can generate embeddings within the one platform or would you be access platform.

10:25So it's really one one of those spaces where I'm seeing a lot Mongo DB fast API being used a lot. Another use case that I've seen is, you know, API first micro services architecture is just because, you know, it's so easy to spin up something in fast API. And Mongo DB is also very sort of like a plug and play because Atlas provides you the flexible to create a cluster deploy, not much of A supervision, you know, everything is done for you. So it really adds a lot of velocity to what you're doing.

10:57Love that, Sir. Thank you. Oh, sorry, Avi, go ahead. Yeah, sounds great. Roman. I realised that there's the synchronous version of Bini, which is Bunnet. Could you kindly shed a little light on that? Says I see more more attention on Bini than Bunnet. Yeah, sure. So Bini is a back port, Bunnet is a back port of Bini to synchronous world. Like we synchronize them twice, maybe three times per year after every major update is happening. And we don't synchronize like after every single PR because it takes too much.

11:37So what? What is the reason to have ban it? There are still a lot of people that use synchronous tech like synchronous Flask, some Django applications and so on, which uses synchronous and for that. And if people want still to use bini like Mongo DB, spydintic, they have to do some workarounds to make a synchronous library synchronous. And this is additional overhead of protesting time and in general it's not that nice. So we decided to support synchronous version as well as soon pymonga support synchronous calls forum our site.

12:23It's not that complicated to just rework everything to support internals as well. So one that is completely the same as being about synchronous, and it's a bit, it consumes, updates a bit, you know, slower than than being itself, but it's stable. Next that works. Awesome. Great question, Afri. Thank you for asking it. Perfect. So I would like for us to dive into the demo now because one of my main questions, and I'm sure you get this question all the time, Robin, but you know, how would you define a document schema in Beanie using identic models?

13:05So if you could give us a little explanation, but if you need to show us, that would be awesome as well. Yeah, sure. So Pidentic is a library that gives us all the all the freedom of how we can use the data, use different types and makes the data nested. As well as Mongo DB supports everything like this, like nestiness, a lot of fields and any data types are supported. So in that sense. But then it can help with structure, like if we want to keep a schema more or less clean and we still want to use freedom of types and so on.

14:04But we still want to understand like in general what we keep in our collection and to be able to work with everything. Adenjek helps with this a lot because it can help with structure and it can validate like what you'll post to your database and what you receive from a database. Bini supports a few different ways to store things like. Here you can see the very simple model User. It consists of name and e-mail only as strings. Here you can put any data type. It can be your ID, numbers, date, date, time and so on. So it doesn't matter actually.

14:53But this is kind of plain model. It means there is only one level of nestedness here as well we can add a bit more like we can for example for this user we can using this models we can add for example post it would look like this so. Sorry, is there any way that you could please make your the code on your screen a little bit bigger? Yeah, sure, let's make it this pic. Is it OK or should I make it even even bigger? Can we do a little bit bigger, just so, just so the audience can see? Yeah.

15:39Thank you. So much sorry for that. 200% I think it should be visible right now, yes. Yes, that's a lot better. Thank you. Sylvia and here we can like in the post. Here for example we can use User as user mapping directly directly the document or base model that was already implemented. Another way to keep nesting stuff here is references all links as we name them in mini. So you can use a link here as a type as a generic type and put a user into the bracket. So it means how how we did work.

16:31User will stay in the same collection as before. For in the user collection post to live in the post collection, we name it posts here and autofill in the database level will be a link to another collection. But when we will work with Python code with Bini everything would be fetched and we can work with everything together. And as there is another one interesting sync in Bini, you can use single collection to keep your documents in different CMOS actually like you can create a base document post in our case then you can say that it's a root document, it's a type of the document like everything would be inherited from. And then in actually make derived models that will have another field set like summary for article level for tutorial. And everything would stay in the same collection in the post collection.

17:46But we can work with them all and together like I can get all the types of the posts in a single query or I can, for example, ask to get only articles or only tutorials or only posts. Yeah, so this is this is how we can organise data using mini. So it adds a bit more flexibility even in compared to to monitor to be raw usage. Should I go next to to ask them right? Yeah. But quickly, I believe AFY has a question. Yeah. What are some best practices that you could recommend when defining document schemers? So my recommendation would be try to keep everything simple and increase complexity like with step by step without, you know, without trying to make huge huge schemas from the first shot.

19:02Like make everything as simple as possible at the at the very beginning, because refactoring the schemas later is usually a problem, an issue and waste of the time. But in general, Mongo DB after the fifth version at least can handle like huge schemas, huge indexes, text indexes and number indexes and so on. And everything works really fast on their side. On our side, on the Python side, identical civil validation library also was reworked with Rust, so it works much faster than before because Python validation is slow. But Rust validation is almost as fast as civil validation, so it's great.

19:55It means we have much less limitations now than we had like even five years ago or even 10 years ago and when we were working with 3.6 Mongo DB. So right now developers has much better conditions to work with. Nice, nice. So keeping things simple, over to you Anaya and. Also just wanted to say in MongoDB 8 dot O we delivered massive performance gains so that should also help a lot in in getting a better performance out of Mahodb. Perfect. And then so a lot of people when they use Mongo DB, they rely on indexes, right?

20:35So can you discuss a little bit about how does B need generate and manage Mongo DB indexes? Oh yeah, I think I didn't add it here, but you can use let's me, let's me import. We can import indexes and this way we can just tap like if if for example title should be indexed and it's a very simple way to index singles fields and we also can set up it in the settings. It would be a bit more complicated, but it looks completely the same as if we add indexes in π Mongo because it uses the same the same syntax.

21:34I think. I will not edit here, but we can go to the documentation. Let's go here because there are so many ways actually to work with indexes because this is highly important part of of bin itself. So here is how we create can create indexes in the settings. Why I may I I tell that it's it could work a different way because indexes is not only single field indexes, it could be compound indexes with different with different properties like name like way to sort ascending, ascending and so on. So on.

22:16This way we can create many indexes per collection just in the inner settings class for the, for the model, for the, for the document model. In this example we create test int it's single field. We create compound using just a list and we create another one user index model. Index model is actually Pi mongo index model, so we can create it the same way as we do it for π mongo. That kind of leads me into my next question. So what exactly is the difference between working with complex queries in Beanie and motor or pymaca?

23:00And this one can be for either you Rahman or you Shubham. I can do this one. So when you're working with long to win Python, you got a few ways. For example, order pymongo or like like BD. Working with native driver like pymongo gives you full control over your query is, which is our fault, but it also means you're writing a lot of boilerplate code and writing complex queries, handling validation, etcetera. I just add a lot on the application level.

23:29There's beeni on the other hand, which is built on top of Pymongo gets you much more pytonic feel if you have this pytantic model, you know just like fast API. So your scheme as is strongly typed and validated out-of-the-box. And also when you're writing queries in in Beanie you are doing it in the more expressive pythonic way than raw MQL in Mongo DB. So many developers love prefer to work with a neat interface like Beanie to write code. This way the code is much more maintainable and and just scalable. That said, with an Odeon like Beanie, sometimes lose a little little bit of low flexibility that comes with, with writing queries, for example, optimization that you may want to do in your queries.

24:15And that has been a problem with that whole OMODM space in general. But it's a trade off. You know, it's between control and productivity and really comes down to your development style and then what kind of project you're building. That's awesome. That's good to know. What about, you know, for other more advanced features? I believe Ashley, you had an awesome question that I saw earlier. Yeah. I just wanted to find out what is the difference when you're creating aggregation pipelines, because after indexes and queries, you have aggregation pipelines which help purchase documents and perform operations like the filter matching and so too.

24:56How is that done in BD and how is that different from other ODMS? So aggregation pipeline as soon aggregation pipeline it. In general aggregation framework as we name it in Mongo DB is a very complicated thing. So Bini supports aggregation but it supports it on a low level. We can create a pipeline and we should use this computer to the same MQL syntax as we would use for pymongo or motor or or any other way to send comments to mongo DB. The only additional thing is we can fetch everything into the models. So there is no such example here. But we also can can add a model here into the aggregate command where we will fetch everything into. So it as a result would not be dictionaries or belong there list of dictionaries but will be identic model. But this is all we can do with such complicating as aggregation framework.

26:15So what is about indexes? It still works more or less the same As for Mongo DB itself, because we don't control this part. But there is interesting addition on bin side, how we also use aggregation framework, because bin supports some magic things that I'd like to show you. So the scale is a bit huge. We support links, So what link is? I before told that we can link to different collections and we can use document from one collection as part of the document of the another collection.

26:59And in general how it works internally. As soon Mongo DB doesn't support such references, we use aggregation framework under their hood. And for this for sure we have to use indexes. If we need links from one thing to another we already can use ID index because like default ID index that is created by default for every collection. But when we need to make opposite operations like to check for this link all the documents that contain it, we have to create other indexes.

27:38But this is already complicated scenarios. So yeah, in general we use aggregations a lot under the hood of Biny and not only to make aggregations like directly as user want, but we also use aggregations under the hood to support some features that are not supported by by Mongo DB itself. Thank you for that. So then can I ask what happens if your, you know, your pigdantic model changes how? Like how would you handle schema migrations? How are things different or the same? Can you dive into a little bit of that? Yes, sure, let's go to the documentation again. Bini itself supports migration.

28:32It's not that simple as with relation databases, because when we work with relation databases the schema change cannot be that complicated As for Mongo DB, because Mongo DB is super flexible, right? So we can for example move values from 1 field into different nested sub fields and so on. And this means we have to support not only schema migration but data migration in bini. So for that we use migrations as just Python modules that we can add to the project that uses bini. For example, here is alt tag, this is this is alt node, this is node and we need to to migrate it. And there are different migration type forward and backward.

29:33Why we do support both Forward is migration from old to new. It's just, you know, straightforward migration to make the schema and data changes. And we support backward migration. It works to make rollback possible, because sometimes after migration some data could be corrupted, something could be not supported yet in the services and so on. So there is a lot of headache in case you migrated everything and you have no way to migrate everything backward.

30:05So we support both forward migration and backward migration. And there is in case that user wants to implement a really complicated migration like as I told before, when user need to move data not from one document to even different collections. For example, we support migrations called free fall migrations. It means user just tap all the logic of the migration into this Python module and we just go forward and backward as well as we did before. So in general there are simple way like we just set up mapping between old and new documents and it works. And there is a more complicated fail called free fall immigration, where users set up everything on their own. Fantastic.

31:01Thank you so much for that very, very thorough explanation. I really appreciate that. And I wanted to show so you had some resources. I wanted to allow the all the watchers to see those resources as well. Let me put my screen up. I believe it. There we go. OK, so all the watchers, if you have any questions from Roman's demo, please leave a question for us to answer later on. If you have general questions, that would be awesome as well and we'll answer them as as soon as we can. But I wanted to not switch gears, but I had, there's been recent talk about, you know, motor being depreciated recently.

31:48And I kind of wanted to ask a question to you, Shivam, about that, about motor being depreciated in favor of async API and π Mongo. We've had a lot of people from the community ask about this. We want to bring that up. Can you explain kind of what drove that decision and how it could impact existing projects? Yeah. So historically Python team, we maintain 2 separate libraries for for Python, you know, Pymongo for synchronous use case and and Motor for asynchronous application.

32:23However, Motor was built as a wrap around pymongo and while it exposed and all sync IO compatible interface, it generally delivered the full performance benefit of true async IO. You know, and under the hood, I relied on threads to handle blocking operations, which introduced overhead and limited the scalability for highly congruent applications. Then recently with the Python ecosystem, particularly O sync, IO has also matured a lot. And we saw unfortunately take advantage of these improvements to deliver a more efficient and streamlined solution for O sync workload at the same time maintaining 2 separate libraries that was also sort of like a technic for internal team as well. So about a year ago, we began proof of concept integrate native awesome support into the pie Mongo itself. And after several iteration sent it all testing. We released API in pie Mongo may may fucking we did the T release and and our internal benchmarks show performance gains of up to 10 to 30% for highly print workloads. If you're using async API in Timeongo, so it's a win, win. And and you know, for developers

33:31who are currently using more of the migration part is pretty straightforward. And, and we have published the migration guide and documentation as well. And I think Ruben also recently migrated from the using motor to sync API in PD and I think probably we're going to talk a little bit about that as well. So I would love to hear what Robin has to say. Yeah, Yeah. Actually we created the PR to migrate from motor to, I think payment. I think half a year ago when it was just after, after, after the first message that payment will support a synchronous way. We immediately created this, this thing. And yeah, we've emigrated.

34:12It sexually was straightforward. We only had to remove everything about motor from our code base and replace with pymongo. But we introduced a few breaking changes because of the naming convention like before that we for that model we named collection as motor collection and we could not name it this way anymore. So and this why we introduced the Bini version 2, it's only the major change there is it supports by Mongo I think way instead of motor but as soon as it's a braking change it's the second version of Beni now.

35:02Yeah, that's awesome. I was going to ask about that because I know that Beni version 2 was released last weekend, right? So it's very new. Have you heard any feedback from the community about amusing version 2? Or what are some features that you can talk about besides I don't? Actually, this is a good news. We didn't hear any complaints about this. It means we created everything correctly, because usually after major or even small release we and if we introduced some, you know, incompatibility, some bugs and so on, we immediately can see the audience reaction.

35:41While if we just make a small version bump without any bugs introduced, everything is quiet in our channels and this is a good sign. So version 2 is a quiet version, so nobody complaints. That's perfect. That's awesome. You got a shout out. I put it on the screen, but I'll put it here. Again, huge shout out. Many thanks, Roman for creating Beanie little rocket ship. That's awesome. I know a lot of people are very excited about, you know, Beanie in general, so it's awesome to have you here.

36:19Another question that I had was a lot of people use, you know, fast API, Flask, Django. How does Beanie integrate with those popular frameworks? Yeah. So as soon one of the reasons to create Binu was to support the new stack and by design it was supporting like it was implemented on base of identity, which means it can be integrated into fast API really smoothly. In fast API there are a few corner cases how it creates, for example, how it creates open API contracts and so on. And being supports such such corner cases as well to only show the necessary information like without showing fields that we use only under the hood and we don't want to expose them for example in the contracts and so on. So yeah, by design it's identic stack and it's supports well by fast API and other potential based frameworks and libraries. Thanks.

37:40Considering all the talks with the new features and the things coming up, what's the near future for Bini within the next 12-6 to 12 months and what should we get excited about? So actually Beeni currently is a very stable library. Like the time when we introduced it to like new big feature every few months was like 2-3 years ago. Currently we mostly work about performance, scalability and other stuff. So currently I'm working on making Beeni a bit more lightweight on a startup because Bini is not only used in micro services where the warm up step could be. So if it can be, it can be long and it's not a problem. But Bini is also used in Lambda functions and alternatives in different cloud providers where this is critical, like how fast library could be installized, for example. So currently I'm working on this, on making installation step lightweight, making everything as lazy as possible and so on.

38:56So mostly working on performance and scalability because this is critical in our time as well. Yeah, that's I think that's the answer. Heard that. Thank you so much for that. OK, so I I have a little question. If people want to contribute to Beanie, what is the best way for them to do so? Yeah, we already have a team of contributors and I'm I super appreciate their help and they do most of the work already without me like last year probably. They are super active as developers, as community managers and so on. We have a Discord channel where we communicate where we plan our new features and what we can do and what we actually should do. And we help others, people who just joined community or started to work with Bini.

39:56There are special sections there like help and other discussions. And if you want to help with Bini development, please join our Discord server. And so we have a few groups there, public and private, where we can discuss how we could help. Perfect and. Then, is the Beanie Discord the best way for anyone who's watching to get in touch with you? If you just faced like a problem, like issue or any bug, you just can send GitHub issue and it would be enough.

40:39So we read all of them and we try to answer fast and if it's critical or high importance, we for sure we'll solve it fast as well. But if you want to chat to talk, it's better to go to Discord server, yeah. Perfect. And so which resources do you recommend that developers look at when they're first getting started? We have a documentation on the website Bini dash ODM dot dev. It's well written documentation comprehensive like it's written in shape of tutorial admin.

41:25So we tried to explain every user scenario and how it could be covered by Bini features. So please firstly go there. There are fast start section and comprehensive tutorial documentation there. I think you will read everything you need for your first steps there. And yeah, and you can go to the GitHub channel as soon as this is item, you just can read the code itself. It's pretty clear to understand the logic there. So if you faced any corner cases and you want to dig deeper, you just can read the quote. Perfect.

42:05And you're getting a lot of love in the comments right now, but from everyone who's watching, if you have any questions at all, now is the time for you to ask all of them. You can ask the experts yourself. If any questions for Shupon, any questions for Roman, any questions for me, any questions for Avi, please feel free. But yeah, that demo was incredible. The explanations were fantastic. The questions asked were great. So I just want to say, Roman, thank you so much, you know, for taking the time to be here. I know that Beanie is super beneficial for so many developers.

42:43Oh, I'm seeing that. We have a couple questions. OK, So what are the best practices for creating composite or text indexes? Is the first one, and there's another one, but I'll answer that or I'll ask that actually the first one's answered. So it's always hard to answer such questions without knowing the context of the lot profile of the, how big the collections and and so on. I'd say you have to like if you need to compound index, then you understand that you query using that combinations of these fields and you already understand your load profile.

43:31So then you just have to create such a combined index and it will work that if you don't understand your load profile, you probably have to create some load tests to understand what is hot pass for your query. Like when you what is the most frequent request and for which requests you spend the most time and then like the most time is literally in milliseconds. Like which request single request takes a lot as most of the time. And in some like there are situations when single request is very slow but you request like a few times per day and there are more or less fast requests but you shoot them like 1000 times per second.

44:23And actually, this is a place to improvement. So yeah. And then you can just understand what you're looking for and exactly how you're looking for. You should tap your indexes. This is this is a best practice. Perfect. And then do you have any advice for indexes on a vector field? That is the second part of the question. Sir, could you please repeat on which field? On vector fields. Yeah, I see. Actually I'm, I'm not that experienced in that field. I'm just playing with this.

45:05So I cannot have expert opinion about factor fields, but but yeah, it's it's fun. It's fun to play with them. So I'm just starting to play with them as well. So sorry audience, but I'm not the the one who could answer this. Yes, we, we, we can chat offline about this. We have been working internally on on a project for adding vector source capability and some of the Odms and and I think this is a great collaboration of our study for us to talk. Thanks.

45:40I'll set up some time for us. And then you have some more love from Marco, who's saying that it is his favorite manga DPODM, which is awesome. Thank. You it's my favorite as well. Well. Mine too, mine too Roman. You do a great job at not only creating the library, but maintaining and keeping us. Is a great shape and. Will thank you. Thank you so much and thank you everyone for joining. If you have any questions leftover that we weren't able to ask, please just leave them in the comment section of either the YouTube link or the LinkedIn link, and then someone will definitely be able to get to you.

46:22But if no one has any more questions, then we can end the live stream here. Thank you everyone for watching. Thank you, Roman and Shubham and AFI for joining me today. This has been a ton of fun. Yeah. Thank you so much for everyone. Thank you very much.