1 00:00:00,040 --> 00:00:03,040 Hello, hello everyone. Thank you all so much for tuning 2 00:00:03,040 --> 00:00:04,800 in. So why don't we go ahead and 3 00:00:04,800 --> 00:00:08,160 we'll get started. So this is a super, super 4 00:00:08,160 --> 00:00:11,480 exciting episode today as we have Ramon, the creator of 5 00:00:11,480 --> 00:00:16,160 Beanie here to chat with and we we are going to be covering some 6 00:00:16,239 --> 00:00:19,640 frequently asked questions about the Python library. 7 00:00:19,880 --> 00:00:23,680 You're going to chat all together, go through a hands on 8 00:00:23,680 --> 00:00:28,200 demo and then leave some time at the end for questions straight 9 00:00:28,240 --> 00:00:30,320 from all of you, all from the audience. 10 00:00:31,160 --> 00:00:34,360 So I'm going to go ahead and I'm going to turn it over to Roman 11 00:00:34,360 --> 00:00:36,040 and allow you to introduce yourself. 12 00:00:37,280 --> 00:00:39,240 Hey, hello, everyone. Thank you. 13 00:00:39,400 --> 00:00:42,440 Thank you for having me here. Yeah, I'm Roman. 14 00:00:42,640 --> 00:00:45,120 I'm a software engineer. Currently I'm working at 15 00:00:45,240 --> 00:00:47,400 Microsoft as a senior software engineer. 16 00:00:47,920 --> 00:00:49,880 And he has a reason why I'm here. 17 00:00:50,000 --> 00:00:52,920 A few years ago I've created a binodem. 18 00:00:53,320 --> 00:01:02,320 It's ODM for mongo DB that uses identic and I mongo and motor in 19 00:01:02,320 --> 00:01:03,840 previous sessions. So that's it. 20 00:01:05,120 --> 00:01:07,400 Awesome. And now over to you, Shubham. 21 00:01:08,400 --> 00:01:10,200 Hey everyone, hope you're doing well. 22 00:01:10,560 --> 00:01:13,440 My name is Shubham, I'm a product manager at Mongo DB for 23 00:01:13,440 --> 00:01:16,520 our Python client libraries. I primarily own. 24 00:01:16,800 --> 00:01:21,040 I mongo now duplicated motor I mongo aero and recently launched 25 00:01:21,040 --> 00:01:22,760 Django mongo DB back end library. 26 00:01:22,880 --> 00:01:24,040 Looking forward to a live stream. 27 00:01:25,080 --> 00:01:28,720 Perfect. And how about you, AFY Hi. 28 00:01:28,720 --> 00:01:32,880 Everyone, I'm afy, I'm a dev advocate, I'm mongo DB and I'm 29 00:01:32,960 --> 00:01:34,840 specialized for jungle and Python. 30 00:01:36,520 --> 00:01:38,040 Awesome. OK, now that we're all 31 00:01:38,040 --> 00:01:41,760 acquainted, let's go ahead and jump into our agenda for today. 32 00:01:43,760 --> 00:01:46,280 So first, of course, it's a very small agenda. 33 00:01:46,960 --> 00:01:49,800 We have some housekeeping that we're just going to quickly go 34 00:01:49,800 --> 00:01:52,520 over. We are going to chat about the 35 00:01:52,520 --> 00:01:55,760 Beanie ODM library. Roman is going to take you 36 00:01:55,760 --> 00:01:58,600 through the hands on demo. It's super, super cool. 37 00:01:58,600 --> 00:02:02,120 If you have any questions, please leave them in the chat 38 00:02:02,280 --> 00:02:05,480 and then we'll see if we're able to get to your questions during 39 00:02:05,480 --> 00:02:07,280 the live stream. But we're definitely going to 40 00:02:07,280 --> 00:02:10,720 allocate some time at the very end of the live stream to answer 41 00:02:10,720 --> 00:02:13,920 any questions that we may have missed and also give all you 42 00:02:13,920 --> 00:02:16,480 have some fantastic resources to learn more. 43 00:02:19,960 --> 00:02:23,880 So here is our housekeeping. First and foremost, there are 44 00:02:23,880 --> 00:02:28,720 absolutely no bad questions. So please use the chat feature 45 00:02:30,160 --> 00:02:32,360 and we will answer your questions at the end. 46 00:02:32,480 --> 00:02:35,480 So you can chat from either YouTube or LinkedIn, wherever 47 00:02:35,480 --> 00:02:38,960 you're watching from. And even if you you know, if you 48 00:02:38,960 --> 00:02:42,200 miss the live stream and you watch it later on on either of 49 00:02:42,200 --> 00:02:44,960 those platforms still, please feel free to answer your 50 00:02:44,960 --> 00:02:47,960 questions and someone from the Deborah team or another team 51 00:02:48,120 --> 00:02:50,120 will definitely try to answer your question. 52 00:02:52,440 --> 00:02:57,560 So let's get started. Let's start off with some intros 53 00:02:57,560 --> 00:03:01,840 about what beanie is so Roman. For those in the audience who 54 00:03:01,840 --> 00:03:04,760 may not be aware of what Beanie is, can you please quickly 55 00:03:04,760 --> 00:03:09,680 explain the Python package? Yeah, sure. 56 00:03:10,000 --> 00:03:15,040 So Beanie is Object Document Mapper ODM. 57 00:03:16,400 --> 00:03:21,880 Probably people face things like, I don't know, it's called 58 00:03:21,880 --> 00:03:24,480 Alchemy for POST, Graysqual and and so on. 59 00:03:24,480 --> 00:03:27,960 So Bini is mostly making the same thing. 60 00:03:28,120 --> 00:03:34,040 It's mapping item objects to structures that are stored in 61 00:03:34,040 --> 00:03:37,040 the Mongo DB itself and manipulate with them. 62 00:03:37,320 --> 00:03:43,080 Like it can search, it can update, it can remain and it can 63 00:03:43,080 --> 00:03:48,440 aggregate data. So in general Bini is simplifies 64 00:03:48,440 --> 00:03:53,880 developers life and it supports like more platonic way to 65 00:03:53,880 --> 00:03:57,520 manipulate data in mongo DB. Awesome. 66 00:03:57,640 --> 00:04:00,080 Thank you for that, that introduction and that 67 00:04:00,080 --> 00:04:02,840 explanation. I have another quick little 68 00:04:02,840 --> 00:04:05,680 question because you mentioned what ODM is. 69 00:04:05,680 --> 00:04:08,720 So I just wanted to ask, you know, either Ramen or Shiva, 70 00:04:08,840 --> 00:04:12,000 whoever wants to take this one, what is the difference between 71 00:04:12,000 --> 00:04:15,880 an ODM and an ORM? So I'm sure a lot of our viewers 72 00:04:15,880 --> 00:04:19,360 and listeners, they probably are more familiar with what an ORM 73 00:04:19,399 --> 00:04:22,240 is. Yeah, happy to take that one. 74 00:04:23,480 --> 00:04:27,400 And ORM literally stands for Object Relational Mapper. 75 00:04:27,400 --> 00:04:31,040 It basically maps the objects in your code to rows and Collins in 76 00:04:31,040 --> 00:04:35,280 a relational database. And ODM on the other hand is an 77 00:04:35,280 --> 00:04:37,960 object. Document Mapper maps the objects 78 00:04:37,960 --> 00:04:40,040 in your code to documents in Mongo DB. 79 00:04:41,240 --> 00:04:43,960 I think functionally they do the same thing for developers that 80 00:04:43,960 --> 00:04:46,640 let you work with native language objects and queries 81 00:04:46,640 --> 00:04:50,360 instead of writing either SQL for all MQL commands. 82 00:04:50,400 --> 00:04:53,080 The main differences in underlying data model relational 83 00:04:53,080 --> 00:04:56,120 versus document based. Very cool. 84 00:04:56,120 --> 00:04:59,200 That's a fantastic, fantastic explanation. 85 00:04:59,400 --> 00:05:02,640 Anyone who's watching has any questions about the differences 86 00:05:03,240 --> 00:05:06,440 between an ODM and an ORM, please let us know in the chat 87 00:05:06,440 --> 00:05:09,560 and we'll get to your questions. But kind of going off of that, 88 00:05:10,520 --> 00:05:12,680 back to you, Roman. So what was the motivation 89 00:05:12,680 --> 00:05:16,160 behind creating this library, especially because we already 90 00:05:16,160 --> 00:05:19,920 have some Python packages such as motor and Pymongo that 91 00:05:19,920 --> 00:05:22,200 already exist. So how are you hoping to have 92 00:05:22,200 --> 00:05:26,840 Beanie stand out from there? Yeah, for sure there are drivers 93 00:05:26,840 --> 00:05:32,120 like Pymongo and motor, but it's a bit low level like people have 94 00:05:32,120 --> 00:05:38,720 to work with as Shuman talked with various directly, while 95 00:05:38,720 --> 00:05:43,560 actually there are Odms is spelled like Mongo engine. 96 00:05:43,760 --> 00:05:47,800 But in the time, by the time when I was creating mini like it 97 00:05:47,800 --> 00:05:52,840 was 4 even five years ago, there's a very no asynchronous 98 00:05:53,240 --> 00:06:00,080 ODM for Z for Mongo DB at all. And I was working on my projects 99 00:06:01,120 --> 00:06:04,640 or some personal pet projects and I decided why shouldn't I 100 00:06:04,640 --> 00:06:10,160 create one And that time it was raising off fast API so identic 101 00:06:10,160 --> 00:06:13,240 stack and I decided that it's everything should be must be 102 00:06:13,240 --> 00:06:15,880 compatible so and I created vini on that stack as well. 103 00:06:17,160 --> 00:06:20,360 That's awesome. So can you go into some of the 104 00:06:20,360 --> 00:06:23,880 really key design principles that you kept in mind while you 105 00:06:23,880 --> 00:06:28,040 were creating Vini? Yeah, sure. 106 00:06:28,040 --> 00:06:35,280 So every I wanted to first of all to mimic everything as 107 00:06:35,280 --> 00:06:38,840 possible from motor, from from Pymonga. 108 00:06:38,840 --> 00:06:42,720 I mean, all the operations should work exactly the same, 109 00:06:42,720 --> 00:06:46,120 but with some abstraction level. What does it mean? 110 00:06:46,120 --> 00:06:51,360 For example, if operations are atomic would be done in a single 111 00:06:51,360 --> 00:06:56,080 shot in a single comments to Mongo to be it must still stay 112 00:06:56,080 --> 00:06:59,440 atomic because otherwise we will have race conditions and other 113 00:06:59,440 --> 00:07:02,400 problems. Is that developers we'll never 114 00:07:02,400 --> 00:07:05,280 know about and we'll have a lot of problems because it's super 115 00:07:05,280 --> 00:07:10,480 hard to debug. And only when all those features 116 00:07:10,480 --> 00:07:15,640 were implemented, we added more and more on top using this 117 00:07:15,640 --> 00:07:18,560 basic. So this, this was just a general 118 00:07:18,560 --> 00:07:22,240 principle. And yeah, for sure, we always 119 00:07:23,400 --> 00:07:28,720 communicated with the with the community because honestly, my 120 00:07:28,760 --> 00:07:35,080 own usage scenario, not that rich as users suggest, like we 121 00:07:35,080 --> 00:07:37,600 need to do this, we want to do this and so on. 122 00:07:38,000 --> 00:07:41,640 And like every time, it was great ideas to add features to 123 00:07:41,760 --> 00:07:47,360 to Benny loved. That thank you for going over 124 00:07:47,360 --> 00:07:49,320 that. So kind of from from your 125 00:07:49,400 --> 00:07:53,800 answer, I wanted to ask how does Benny's async first approach 126 00:07:53,800 --> 00:07:57,200 really change the way that we not only model but also query 127 00:07:57,200 --> 00:08:04,280 our data? I can say that so it is just 128 00:08:04,280 --> 00:08:07,000 modern world of Python. Unlike everything it should be 129 00:08:07,000 --> 00:08:08,920 and must be asynchronous right now. 130 00:08:09,280 --> 00:08:13,680 And interacting with Mongo DB is, you know, book example 131 00:08:13,680 --> 00:08:17,600 principle like when we have to use such because it's IO 132 00:08:17,640 --> 00:08:23,120 operation where we have to call to wait what's going on on that 133 00:08:23,120 --> 00:08:29,440 side on the Mongo DB side and consume the response from Mongo 134 00:08:29,440 --> 00:08:32,919 DB. So if we will use blocking 135 00:08:32,919 --> 00:08:38,960 approach, synchronous approach, we will lose a lot of like we 136 00:08:38,960 --> 00:08:42,960 can do everything in parallel with asynchronous with and it's 137 00:08:42,960 --> 00:08:45,800 very cheap because we don't have to create any threats and so on. 138 00:08:45,800 --> 00:08:48,920 We just can use asyncrovate approach for that. 139 00:08:50,600 --> 00:08:55,560 And yeah, this is just modern and it gives us much more 140 00:08:55,600 --> 00:09:00,280 resources to be used. Yeah, just wanted to tailwind on 141 00:09:00,280 --> 00:09:03,240 what Roman said. Like sometimes I've seen some 142 00:09:03,240 --> 00:09:08,520 users using async even though they're not really should be 143 00:09:08,520 --> 00:09:10,880 using like it. It should only be using async 144 00:09:10,880 --> 00:09:13,280 when you really have like Roman said like out blocking codosome 145 00:09:13,280 --> 00:09:17,880 blocking operation. Very cool. 146 00:09:17,960 --> 00:09:20,040 And I have a question for you ship on too. 147 00:09:20,040 --> 00:09:25,200 So I know that you know the adoption of fast API and Mongo 148 00:09:25,200 --> 00:09:31,040 DPR is rising among Python users as like the main PM. 149 00:09:31,040 --> 00:09:34,240 Have there been any particular trends that you've observed from 150 00:09:34,240 --> 00:09:38,200 your side even with Beanie? Yeah. 151 00:09:39,480 --> 00:09:41,520 The. Few things that I've noticed I 152 00:09:41,520 --> 00:09:44,920 mean, like both Mongo DB and fast API are super, super 153 00:09:44,920 --> 00:09:46,840 popular. And as like I've been tracking 154 00:09:46,840 --> 00:09:52,680 this space from last few years and every year this stack is 155 00:09:52,680 --> 00:09:55,400 becoming more and more popular. And now there was a term called 156 00:09:55,400 --> 00:09:58,360 farm stack with like fast API, React and Mongo DB. 157 00:09:59,560 --> 00:10:03,480 In terms of trend, like I'm really seeing a lot of new AIML 158 00:10:03,480 --> 00:10:09,120 application that is being built are using fast API and and you 159 00:10:09,120 --> 00:10:12,280 know, on the database side, Mongo DB is one of the top 160 00:10:12,280 --> 00:10:16,240 choices among other databases just because we have added 161 00:10:16,360 --> 00:10:19,600 native vector storage capability as well as now with our voyage 162 00:10:19,680 --> 00:10:24,120 AI position, you can generate embeddings within the one 163 00:10:24,120 --> 00:10:25,920 platform or would you be access platform. 164 00:10:25,920 --> 00:10:29,560 So it's really one one of those spaces where I'm seeing a lot 165 00:10:29,560 --> 00:10:32,640 Mongo DB fast API being used a lot. 166 00:10:33,640 --> 00:10:38,160 Another use case that I've seen is, you know, API first micro 167 00:10:38,160 --> 00:10:40,440 services architecture is just because, you know, it's so easy 168 00:10:40,440 --> 00:10:42,040 to spin up something in fast API. 169 00:10:42,040 --> 00:10:45,360 And Mongo DB is also very sort of like a plug and play because 170 00:10:45,360 --> 00:10:49,160 Atlas provides you the flexible to create a cluster deploy, not 171 00:10:49,160 --> 00:10:52,160 much of A supervision, you know, everything is done for you. 172 00:10:52,160 --> 00:10:54,560 So it really adds a lot of velocity to what you're doing. 173 00:10:57,880 --> 00:10:59,440 Love that, Sir. Thank you. 174 00:10:59,440 --> 00:11:02,080 Oh, sorry, Avi, go ahead. Yeah, sounds great. 175 00:11:02,600 --> 00:11:04,480 Roman. I realised that there's the 176 00:11:04,920 --> 00:11:07,920 synchronous version of Bini, which is Bunnet. 177 00:11:08,240 --> 00:11:10,480 Could you kindly shed a little light on that? 178 00:11:10,480 --> 00:11:15,600 Says I see more more attention on Bini than Bunnet. 179 00:11:17,240 --> 00:11:20,560 Yeah, sure. So Bini is a back port, Bunnet 180 00:11:20,560 --> 00:11:23,800 is a back port of Bini to synchronous world. 181 00:11:24,920 --> 00:11:29,760 Like we synchronize them twice, maybe three times per year after 182 00:11:29,760 --> 00:11:34,080 every major update is happening. And we don't synchronize like 183 00:11:34,080 --> 00:11:37,520 after every single PR because it takes too much. 184 00:11:37,840 --> 00:11:40,360 So what? What is the reason to have ban 185 00:11:40,360 --> 00:11:43,440 it? There are still a lot of people 186 00:11:43,440 --> 00:11:49,880 that use synchronous tech like synchronous Flask, some Django 187 00:11:50,440 --> 00:11:55,680 applications and so on, which uses synchronous and for that. 188 00:11:55,720 --> 00:12:01,840 And if people want still to use bini like Mongo DB, spydintic, 189 00:12:02,720 --> 00:12:07,320 they have to do some workarounds to make a synchronous library 190 00:12:07,320 --> 00:12:10,640 synchronous. And this is additional overhead 191 00:12:10,640 --> 00:12:14,680 of protesting time and in general it's not that nice. 192 00:12:15,120 --> 00:12:18,440 So we decided to support synchronous version as well as 193 00:12:18,440 --> 00:12:23,760 soon pymonga support synchronous calls forum our site. 194 00:12:23,760 --> 00:12:26,880 It's not that complicated to just rework everything to 195 00:12:26,880 --> 00:12:30,560 support internals as well. So one that is completely the 196 00:12:30,560 --> 00:12:36,360 same as being about synchronous, and it's a bit, it consumes, 197 00:12:36,360 --> 00:12:41,160 updates a bit, you know, slower than than being itself, but it's 198 00:12:41,160 --> 00:12:44,480 stable. Next that works. 199 00:12:46,200 --> 00:12:47,480 Awesome. Great question, Afri. 200 00:12:47,480 --> 00:12:51,360 Thank you for asking it. Perfect. 201 00:12:51,640 --> 00:12:55,760 So I would like for us to dive into the demo now because one of 202 00:12:55,760 --> 00:12:57,960 my main questions, and I'm sure you get this question all the 203 00:12:57,960 --> 00:13:01,360 time, Robin, but you know, how would you define a document 204 00:13:01,360 --> 00:13:05,160 schema in Beanie using identic models? 205 00:13:05,520 --> 00:13:07,880 So if you could give us a little explanation, but if you need to 206 00:13:07,880 --> 00:13:09,840 show us, that would be awesome as well. 207 00:13:12,440 --> 00:13:22,600 Yeah, sure. So Pidentic is a library that 208 00:13:22,600 --> 00:13:30,080 gives us all the all the freedom of how we can use the data, use 209 00:13:30,080 --> 00:13:33,720 different types and makes the data nested. 210 00:13:35,680 --> 00:13:40,080 As well as Mongo DB supports everything like this, like 211 00:13:40,080 --> 00:13:48,000 nestiness, a lot of fields and any data types are supported. 212 00:13:49,200 --> 00:13:52,400 So in that sense. But then it can help with 213 00:13:52,400 --> 00:13:57,400 structure, like if we want to keep a schema more or less clean 214 00:13:57,840 --> 00:14:04,320 and we still want to use freedom of types and so on. 215 00:14:04,320 --> 00:14:08,360 But we still want to understand like in general what we keep in 216 00:14:08,360 --> 00:14:11,600 our collection and to be able to work with everything. 217 00:14:12,560 --> 00:14:16,920 Adenjek helps with this a lot because it can help with 218 00:14:16,920 --> 00:14:20,920 structure and it can validate like what you'll post to your 219 00:14:20,920 --> 00:14:23,560 database and what you receive from a database. 220 00:14:24,880 --> 00:14:29,960 Bini supports a few different ways to store things like. 221 00:14:29,960 --> 00:14:35,240 Here you can see the very simple model User. 222 00:14:35,760 --> 00:14:39,560 It consists of name and e-mail only as strings. 223 00:14:40,040 --> 00:14:47,520 Here you can put any data type. It can be your ID, numbers, 224 00:14:48,680 --> 00:14:52,440 date, date, time and so on. So it doesn't matter actually. 225 00:14:53,240 --> 00:14:57,920 But this is kind of plain model. It means there is only one level 226 00:14:57,920 --> 00:15:07,440 of nestedness here as well we can add a bit more like we can 227 00:15:07,840 --> 00:15:15,160 for example for this user we can using this models we can add for 228 00:15:15,160 --> 00:15:20,080 example post it would look like this so. 229 00:15:20,080 --> 00:15:24,000 Sorry, is there any way that you could please make your the code 230 00:15:24,000 --> 00:15:25,560 on your screen a little bit bigger? 231 00:15:26,320 --> 00:15:31,160 Yeah, sure, let's make it this pic. 232 00:15:31,800 --> 00:15:34,640 Is it OK or should I make it even even bigger? 233 00:15:35,520 --> 00:15:38,480 Can we do a little bit bigger, just so, just so the audience 234 00:15:38,480 --> 00:15:39,320 can see? Yeah. 235 00:15:39,320 --> 00:15:45,280 Thank you. So much sorry for that. 200% I 236 00:15:45,280 --> 00:15:47,080 think it should be visible right now, yes. 237 00:15:47,640 --> 00:15:49,360 Yes, that's a lot better. Thank you. 238 00:15:50,440 --> 00:15:54,160 Sylvia and here we can like in the post. 239 00:15:54,160 --> 00:16:00,600 Here for example we can use User as user mapping directly 240 00:16:00,600 --> 00:16:07,280 directly the document or base model that was already 241 00:16:08,000 --> 00:16:12,160 implemented. Another way to keep nesting 242 00:16:12,280 --> 00:16:17,640 stuff here is references all links as we name them in mini. 243 00:16:18,120 --> 00:16:26,200 So you can use a link here as a type as a generic type and put a 244 00:16:26,200 --> 00:16:30,720 user into the bracket. So it means how how we did work. 245 00:16:31,600 --> 00:16:35,880 User will stay in the same collection as before. 246 00:16:36,320 --> 00:16:39,960 For in the user collection post to live in the post collection, 247 00:16:40,880 --> 00:16:47,240 we name it posts here and autofill in the database level 248 00:16:47,840 --> 00:16:51,440 will be a link to another collection. 249 00:16:51,440 --> 00:16:55,080 But when we will work with Python code with Bini everything 250 00:16:55,080 --> 00:16:59,040 would be fetched and we can work with everything together. 251 00:17:01,360 --> 00:17:06,000 And as there is another one interesting sync in Bini, you 252 00:17:06,000 --> 00:17:11,680 can use single collection to keep your documents in different 253 00:17:11,680 --> 00:17:15,760 CMOS actually like you can create a base document post in 254 00:17:15,760 --> 00:17:22,400 our case then you can say that it's a root document, it's a 255 00:17:22,400 --> 00:17:25,280 type of the document like everything would be inherited 256 00:17:25,280 --> 00:17:28,600 from. And then in actually make 257 00:17:28,600 --> 00:17:38,280 derived models that will have another field set like summary 258 00:17:38,280 --> 00:17:43,880 for article level for tutorial. And everything would stay in the 259 00:17:43,880 --> 00:17:45,920 same collection in the post collection. 260 00:17:46,320 --> 00:17:51,920 But we can work with them all and together like I can get all 261 00:17:51,920 --> 00:17:57,160 the types of the posts in a single query or I can, for 262 00:17:57,160 --> 00:18:02,120 example, ask to get only articles or only tutorials or 263 00:18:02,120 --> 00:18:08,120 only posts. Yeah, so this is this is how we 264 00:18:08,120 --> 00:18:13,040 can organise data using mini. So it adds a bit more 265 00:18:13,120 --> 00:18:17,960 flexibility even in compared to to monitor to be raw usage. 266 00:18:24,330 --> 00:18:26,970 Should I go next to to ask them right? 267 00:18:28,530 --> 00:18:32,330 Yeah. But quickly, I believe AFY has a 268 00:18:32,330 --> 00:18:33,970 question. Yeah. 269 00:18:35,290 --> 00:18:38,530 What are some best practices that you could recommend when 270 00:18:38,530 --> 00:18:46,010 defining document schemers? So my recommendation would be 271 00:18:46,010 --> 00:18:53,200 try to keep everything simple and increase complexity like 272 00:18:53,720 --> 00:18:58,120 with step by step without, you know, without trying to make 273 00:18:58,120 --> 00:19:02,200 huge huge schemas from the first shot. 274 00:19:02,200 --> 00:19:07,920 Like make everything as simple as possible at the at the very 275 00:19:07,920 --> 00:19:13,840 beginning, because refactoring the schemas later is usually a 276 00:19:13,840 --> 00:19:16,800 problem, an issue and waste of the time. 277 00:19:17,160 --> 00:19:22,160 But in general, Mongo DB after the fifth version at least can 278 00:19:22,160 --> 00:19:29,800 handle like huge schemas, huge indexes, text indexes and number 279 00:19:29,800 --> 00:19:32,800 indexes and so on. And everything works really fast 280 00:19:32,800 --> 00:19:35,840 on their side. On our side, on the Python side, 281 00:19:37,680 --> 00:19:42,240 identical civil validation library also was reworked with 282 00:19:42,360 --> 00:19:47,720 Rust, so it works much faster than before because Python 283 00:19:47,720 --> 00:19:51,440 validation is slow. But Rust validation is almost as 284 00:19:51,440 --> 00:19:53,960 fast as civil validation, so it's great. 285 00:19:55,560 --> 00:19:59,920 It means we have much less limitations now than we had like 286 00:19:59,920 --> 00:20:03,360 even five years ago or even 10 years ago and when we were 287 00:20:03,360 --> 00:20:09,560 working with 3.6 Mongo DB. So right now developers has much 288 00:20:09,600 --> 00:20:13,480 better conditions to work with. Nice, nice. 289 00:20:13,480 --> 00:20:17,520 So keeping things simple, over to you Anaya and. 290 00:20:17,520 --> 00:20:21,080 Also just wanted to say in MongoDB 8 dot O we delivered 291 00:20:21,080 --> 00:20:25,360 massive performance gains so that should also help a lot in 292 00:20:25,360 --> 00:20:27,040 in getting a better performance out of Mahodb. 293 00:20:30,120 --> 00:20:32,120 Perfect. And then so a lot of people when 294 00:20:32,120 --> 00:20:35,680 they use Mongo DB, they rely on indexes, right? 295 00:20:35,880 --> 00:20:39,440 So can you discuss a little bit about how does B need generate 296 00:20:39,440 --> 00:20:45,000 and manage Mongo DB indexes? Oh yeah, I think I didn't add it 297 00:20:45,000 --> 00:20:54,480 here, but you can use let's me, let's me import. 298 00:20:57,080 --> 00:21:08,160 We can import indexes and this way we can just tap like if if 299 00:21:08,160 --> 00:21:13,640 for example title should be indexed and it's a very simple 300 00:21:13,640 --> 00:21:18,640 way to index singles fields and we also can set up it in the 301 00:21:18,640 --> 00:21:20,760 settings. It would be a bit more 302 00:21:20,760 --> 00:21:25,600 complicated, but it looks completely the same as if we add 303 00:21:25,600 --> 00:21:31,480 indexes in π Mongo because it uses the same the same syntax. 304 00:21:34,520 --> 00:21:37,240 I think. I will not edit here, but we can 305 00:21:37,240 --> 00:21:43,760 go to the documentation. Let's go here because there are 306 00:21:43,760 --> 00:21:46,800 so many ways actually to work with indexes because this is 307 00:21:47,240 --> 00:21:50,400 highly important part of of bin itself. 308 00:21:50,920 --> 00:21:56,600 So here is how we create can create indexes in the settings. 309 00:21:57,280 --> 00:22:00,960 Why I may I I tell that it's it could work a different way 310 00:22:00,960 --> 00:22:04,520 because indexes is not only single field indexes, it could 311 00:22:04,520 --> 00:22:09,400 be compound indexes with different with different 312 00:22:09,720 --> 00:22:14,880 properties like name like way to sort ascending, ascending and so 313 00:22:14,880 --> 00:22:16,440 on. So on. 314 00:22:16,440 --> 00:22:21,000 This way we can create many indexes per collection just in 315 00:22:21,000 --> 00:22:27,440 the inner settings class for the, for the model, for the, for 316 00:22:27,440 --> 00:22:31,840 the document model. In this example we create test 317 00:22:31,840 --> 00:22:37,280 int it's single field. We create compound using just a 318 00:22:37,280 --> 00:22:42,120 list and we create another one user index model. 319 00:22:42,120 --> 00:22:45,960 Index model is actually Pi mongo index model, so we can create it 320 00:22:45,960 --> 00:22:48,120 the same way as we do it for π mongo. 321 00:22:50,480 --> 00:22:52,840 That kind of leads me into my next question. 322 00:22:53,080 --> 00:22:56,040 So what exactly is the difference between working with 323 00:22:56,040 --> 00:23:00,000 complex queries in Beanie and motor or pymaca? 324 00:23:00,560 --> 00:23:03,280 And this one can be for either you Rahman or you Shubham. 325 00:23:04,600 --> 00:23:08,360 I can do this one. So when you're working with long 326 00:23:08,360 --> 00:23:09,960 to win Python, you got a few ways. 327 00:23:09,960 --> 00:23:13,280 For example, order pymongo or like like BD. 328 00:23:14,440 --> 00:23:17,840 Working with native driver like pymongo gives you full control 329 00:23:17,880 --> 00:23:20,960 over your query is, which is our fault, but it also means you're 330 00:23:20,960 --> 00:23:24,960 writing a lot of boilerplate code and writing complex 331 00:23:24,960 --> 00:23:26,720 queries, handling validation, etcetera. 332 00:23:26,720 --> 00:23:28,680 I just add a lot on the application level. 333 00:23:29,840 --> 00:23:33,280 There's beeni on the other hand, which is built on top of Pymongo 334 00:23:33,400 --> 00:23:37,280 gets you much more pytonic feel if you have this pytantic model, 335 00:23:37,920 --> 00:23:40,400 you know just like fast API. So your scheme as is strongly 336 00:23:40,400 --> 00:23:42,560 typed and validated out-of-the-box. 337 00:23:43,120 --> 00:23:45,760 And also when you're writing queries in in Beanie you are 338 00:23:45,760 --> 00:23:50,520 doing it in the more expressive pythonic way than raw MQL in 339 00:23:50,520 --> 00:23:53,840 Mongo DB. So many developers love prefer 340 00:23:53,840 --> 00:23:57,680 to work with a neat interface like Beanie to write code. 341 00:23:57,680 --> 00:24:01,600 This way the code is much more maintainable and and just 342 00:24:01,760 --> 00:24:05,360 scalable. That said, with an Odeon like 343 00:24:05,360 --> 00:24:09,320 Beanie, sometimes lose a little little bit of low flexibility 344 00:24:09,320 --> 00:24:11,720 that comes with, with writing queries, for example, 345 00:24:11,720 --> 00:24:15,360 optimization that you may want to do in your queries. 346 00:24:15,360 --> 00:24:18,520 And that has been a problem with that whole OMODM space in 347 00:24:18,520 --> 00:24:21,760 general. But it's a trade off. 348 00:24:21,880 --> 00:24:24,080 You know, it's between control and productivity and really 349 00:24:24,080 --> 00:24:26,680 comes down to your development style and then what kind of 350 00:24:26,680 --> 00:24:31,000 project you're building. That's awesome. 351 00:24:31,040 --> 00:24:36,000 That's good to know. What about, you know, for other 352 00:24:36,000 --> 00:24:39,920 more advanced features? I believe Ashley, you had an 353 00:24:39,920 --> 00:24:41,680 awesome question that I saw earlier. 354 00:24:42,480 --> 00:24:45,000 Yeah. I just wanted to find out what 355 00:24:45,000 --> 00:24:47,720 is the difference when you're creating aggregation pipelines, 356 00:24:47,720 --> 00:24:50,680 because after indexes and queries, you have aggregation 357 00:24:50,680 --> 00:24:53,960 pipelines which help purchase documents and perform operations 358 00:24:53,960 --> 00:24:55,800 like the filter matching and so too. 359 00:24:55,960 --> 00:24:58,800 How is that done in BD and how is that different from other 360 00:24:58,800 --> 00:25:04,960 ODMS? So aggregation pipeline as soon 361 00:25:05,000 --> 00:25:07,600 aggregation pipeline it. In general aggregation framework 362 00:25:08,000 --> 00:25:12,600 as we name it in Mongo DB is a very complicated thing. 363 00:25:12,640 --> 00:25:20,080 So Bini supports aggregation but it supports it on a low level. 364 00:25:20,680 --> 00:25:25,160 We can create a pipeline and we should use this computer to the 365 00:25:25,160 --> 00:25:32,640 same MQL syntax as we would use for pymongo or motor or or any 366 00:25:32,640 --> 00:25:35,920 other way to send comments to mongo DB. 367 00:25:37,400 --> 00:25:45,120 The only additional thing is we can fetch everything into the 368 00:25:45,120 --> 00:25:48,680 models. So there is no such example 369 00:25:48,680 --> 00:25:56,240 here. But we also can can add a model 370 00:25:56,240 --> 00:26:01,480 here into the aggregate command where we will fetch everything 371 00:26:01,480 --> 00:26:04,120 into. So it as a result would not be 372 00:26:04,120 --> 00:26:08,160 dictionaries or belong there list of dictionaries but will be 373 00:26:08,240 --> 00:26:11,640 identic model. But this is all we can do with 374 00:26:12,120 --> 00:26:14,520 such complicating as aggregation framework. 375 00:26:14,960 --> 00:26:20,600 So what is about indexes? It still works more or less the 376 00:26:20,600 --> 00:26:25,960 same As for Mongo DB itself, because we don't control this 377 00:26:25,960 --> 00:26:28,480 part. But there is interesting 378 00:26:28,640 --> 00:26:34,400 addition on bin side, how we also use aggregation framework, 379 00:26:34,840 --> 00:26:40,520 because bin supports some magic things that I'd like to show 380 00:26:40,520 --> 00:26:45,080 you. So the scale is a bit huge. 381 00:26:45,400 --> 00:26:48,560 We support links, So what link is? 382 00:26:49,040 --> 00:26:53,520 I before told that we can link to different collections and we 383 00:26:53,520 --> 00:26:56,800 can use document from one collection as part of the 384 00:26:56,800 --> 00:26:59,160 document of the another collection. 385 00:26:59,640 --> 00:27:03,400 And in general how it works internally. 386 00:27:03,480 --> 00:27:07,160 As soon Mongo DB doesn't support such references, we use 387 00:27:07,240 --> 00:27:09,200 aggregation framework under their hood. 388 00:27:09,760 --> 00:27:12,920 And for this for sure we have to use indexes. 389 00:27:14,360 --> 00:27:19,560 If we need links from one thing to another we already can use ID 390 00:27:19,560 --> 00:27:24,840 index because like default ID index that is created by default 391 00:27:24,840 --> 00:27:29,760 for every collection. But when we need to make 392 00:27:29,760 --> 00:27:36,000 opposite operations like to check for this link all the 393 00:27:36,000 --> 00:27:38,760 documents that contain it, we have to create other indexes. 394 00:27:38,760 --> 00:27:40,800 But this is already complicated scenarios. 395 00:27:41,280 --> 00:27:45,840 So yeah, in general we use aggregations a lot under the 396 00:27:45,840 --> 00:27:50,560 hood of Biny and not only to make aggregations like directly 397 00:27:50,560 --> 00:27:55,240 as user want, but we also use aggregations under the hood to 398 00:27:55,240 --> 00:28:00,520 support some features that are not supported by by Mongo DB 399 00:28:00,520 --> 00:28:06,720 itself. Thank you for that. 400 00:28:07,400 --> 00:28:10,720 So then can I ask what happens if your, you know, your 401 00:28:10,720 --> 00:28:16,200 pigdantic model changes how? Like how would you handle schema 402 00:28:16,200 --> 00:28:18,520 migrations? How are things different or the 403 00:28:18,520 --> 00:28:20,280 same? Can you dive into a little bit 404 00:28:20,280 --> 00:28:24,480 of that? Yes, sure, let's go to the 405 00:28:24,480 --> 00:28:30,240 documentation again. Bini itself supports migration. 406 00:28:32,400 --> 00:28:36,920 It's not that simple as with relation databases, because when 407 00:28:36,920 --> 00:28:41,880 we work with relation databases the schema change cannot be that 408 00:28:41,880 --> 00:28:45,440 complicated As for Mongo DB, because Mongo DB is super 409 00:28:45,440 --> 00:28:48,360 flexible, right? So we can for example move 410 00:28:50,480 --> 00:28:54,760 values from 1 field into different nested sub fields and 411 00:28:54,760 --> 00:28:58,680 so on. And this means we have to 412 00:28:58,680 --> 00:29:04,640 support not only schema migration but data migration in 413 00:29:04,640 --> 00:29:09,600 bini. So for that we use migrations as 414 00:29:09,800 --> 00:29:15,480 just Python modules that we can add to the project that uses 415 00:29:17,160 --> 00:29:20,920 bini. For example, here is alt tag, 416 00:29:21,680 --> 00:29:27,400 this is this is alt node, this is node and we need to to 417 00:29:27,400 --> 00:29:30,000 migrate it. And there are different 418 00:29:31,040 --> 00:29:33,200 migration type forward and backward. 419 00:29:33,400 --> 00:29:37,680 Why we do support both Forward is migration from old to new. 420 00:29:39,640 --> 00:29:42,120 It's just, you know, straightforward migration to 421 00:29:42,880 --> 00:29:44,520 make the schema and data changes. 422 00:29:44,800 --> 00:29:46,520 And we support backward migration. 423 00:29:47,040 --> 00:29:51,440 It works to make rollback possible, because sometimes 424 00:29:51,440 --> 00:29:55,080 after migration some data could be corrupted, something could be 425 00:29:55,080 --> 00:29:58,040 not supported yet in the services and so on. 426 00:29:58,040 --> 00:30:02,720 So there is a lot of headache in case you migrated everything and 427 00:30:03,320 --> 00:30:05,280 you have no way to migrate everything backward. 428 00:30:05,720 --> 00:30:10,280 So we support both forward migration and backward 429 00:30:10,320 --> 00:30:13,760 migration. And there is in case that user 430 00:30:13,760 --> 00:30:17,520 wants to implement a really complicated migration like as I 431 00:30:17,520 --> 00:30:22,760 told before, when user need to move data not from one document 432 00:30:22,760 --> 00:30:26,920 to even different collections. For example, we support 433 00:30:27,320 --> 00:30:29,560 migrations called free fall migrations. 434 00:30:30,240 --> 00:30:34,240 It means user just tap all the logic of the migration into this 435 00:30:34,240 --> 00:30:39,400 Python module and we just go forward and backward as well as 436 00:30:39,400 --> 00:30:43,360 we did before. So in general there are simple 437 00:30:43,360 --> 00:30:48,520 way like we just set up mapping between old and new documents 438 00:30:49,040 --> 00:30:53,120 and it works. And there is a more complicated 439 00:30:53,120 --> 00:30:56,440 fail called free fall immigration, where users set up 440 00:30:56,520 --> 00:31:01,360 everything on their own. Fantastic. 441 00:31:01,360 --> 00:31:04,360 Thank you so much for that very, very thorough explanation. 442 00:31:04,360 --> 00:31:08,240 I really appreciate that. And I wanted to show so you had 443 00:31:08,240 --> 00:31:13,560 some resources. I wanted to allow the all the 444 00:31:13,560 --> 00:31:16,040 watchers to see those resources as well. 445 00:31:17,040 --> 00:31:21,280 Let me put my screen up. I believe it. 446 00:31:22,680 --> 00:31:25,760 There we go. OK, so all the watchers, if you 447 00:31:25,760 --> 00:31:29,640 have any questions from Roman's demo, please leave a question 448 00:31:29,880 --> 00:31:33,880 for us to answer later on. If you have general questions, 449 00:31:33,880 --> 00:31:37,680 that would be awesome as well and we'll answer them as as soon 450 00:31:37,680 --> 00:31:41,920 as we can. But I wanted to not switch 451 00:31:41,920 --> 00:31:46,200 gears, but I had, there's been recent talk about, you know, 452 00:31:46,360 --> 00:31:48,640 motor being depreciated recently. 453 00:31:48,840 --> 00:31:52,560 And I kind of wanted to ask a question to you, Shivam, about 454 00:31:52,560 --> 00:31:56,680 that, about motor being depreciated in favor of async 455 00:31:56,680 --> 00:31:59,800 API and π Mongo. We've had a lot of people from 456 00:31:59,800 --> 00:32:02,120 the community ask about this. We want to bring that up. 457 00:32:02,280 --> 00:32:05,360 Can you explain kind of what drove that decision and how it 458 00:32:05,360 --> 00:32:08,560 could impact existing projects? Yeah. 459 00:32:09,960 --> 00:32:14,320 So historically Python team, we maintain 2 separate libraries 460 00:32:14,640 --> 00:32:19,800 for for Python, you know, Pymongo for synchronous use case 461 00:32:19,800 --> 00:32:22,520 and and Motor for asynchronous application. 462 00:32:23,000 --> 00:32:26,320 However, Motor was built as a wrap around pymongo and while it 463 00:32:26,320 --> 00:32:29,320 exposed and all sync IO compatible interface, it 464 00:32:29,320 --> 00:32:31,560 generally delivered the full performance benefit of true 465 00:32:31,560 --> 00:32:34,440 async IO. You know, and under the hood, I 466 00:32:34,440 --> 00:32:37,360 relied on threads to handle blocking operations, which 467 00:32:37,360 --> 00:32:39,880 introduced overhead and limited the scalability for highly 468 00:32:39,880 --> 00:32:43,920 congruent applications. Then recently with the Python 469 00:32:43,920 --> 00:32:47,120 ecosystem, particularly O sync, IO has also matured a lot. 470 00:32:47,120 --> 00:32:49,680 And we saw unfortunately take advantage of these improvements 471 00:32:49,680 --> 00:32:54,760 to deliver a more efficient and streamlined solution for O sync 472 00:32:54,760 --> 00:32:58,160 workload at the same time maintaining 2 separate libraries 473 00:32:58,480 --> 00:33:01,440 that was also sort of like a technic for internal team as 474 00:33:01,440 --> 00:33:04,000 well. So about a year ago, we began 475 00:33:04,080 --> 00:33:07,040 proof of concept integrate native awesome support into the 476 00:33:07,040 --> 00:33:10,760 pie Mongo itself. And after several iteration sent 477 00:33:10,760 --> 00:33:16,120 it all testing. We released API in pie Mongo may 478 00:33:16,120 --> 00:33:20,720 may fucking we did the T release and and our internal benchmarks 479 00:33:20,720 --> 00:33:24,360 show performance gains of up to 10 to 30% for highly print 480 00:33:24,360 --> 00:33:27,480 workloads. If you're using async API in 481 00:33:27,480 --> 00:33:31,200 Timeongo, so it's a win, win. And and you know, for developers 482 00:33:31,200 --> 00:33:33,800 who are currently using more of the migration part is pretty 483 00:33:33,800 --> 00:33:35,760 straightforward. And, and we have published the 484 00:33:35,760 --> 00:33:37,720 migration guide and documentation as well. 485 00:33:38,200 --> 00:33:43,280 And I think Ruben also recently migrated from the using motor to 486 00:33:43,320 --> 00:33:46,000 sync API in PD and I think probably we're going to talk a 487 00:33:46,000 --> 00:33:48,040 little bit about that as well. So I would love to hear what 488 00:33:48,080 --> 00:33:52,120 Robin has to say. Yeah, Yeah. 489 00:33:52,120 --> 00:33:56,520 Actually we created the PR to migrate from motor to, I think 490 00:33:56,520 --> 00:33:59,480 payment. I think half a year ago when it 491 00:33:59,480 --> 00:34:05,280 was just after, after, after the first message that payment will 492 00:34:05,280 --> 00:34:09,000 support a synchronous way. We immediately created this, 493 00:34:09,000 --> 00:34:12,800 this thing. And yeah, we've emigrated. 494 00:34:12,800 --> 00:34:18,480 It sexually was straightforward. We only had to remove everything 495 00:34:19,000 --> 00:34:24,880 about motor from our code base and replace with pymongo. 496 00:34:26,520 --> 00:34:29,639 But we introduced a few breaking changes because of the naming 497 00:34:29,639 --> 00:34:33,719 convention like before that we for that model we named 498 00:34:33,719 --> 00:34:38,080 collection as motor collection and we could not name it this 499 00:34:38,080 --> 00:34:41,520 way anymore. So and this why we introduced 500 00:34:41,520 --> 00:34:48,080 the Bini version 2, it's only the major change there is it 501 00:34:48,080 --> 00:34:53,840 supports by Mongo I think way instead of motor but as soon as 502 00:34:53,840 --> 00:34:57,320 it's a braking change it's the second version of Beni now. 503 00:35:02,280 --> 00:35:04,240 Yeah, that's awesome. I was going to ask about that 504 00:35:04,240 --> 00:35:08,360 because I know that Beni version 2 was released last weekend, 505 00:35:08,360 --> 00:35:09,640 right? So it's very new. 506 00:35:10,560 --> 00:35:14,760 Have you heard any feedback from the community about amusing 507 00:35:14,760 --> 00:35:17,120 version 2? Or what are some features that 508 00:35:17,280 --> 00:35:19,080 you can talk about besides I don't? 509 00:35:20,080 --> 00:35:23,680 Actually, this is a good news. We didn't hear any complaints 510 00:35:23,680 --> 00:35:25,880 about this. It means we created everything 511 00:35:25,880 --> 00:35:31,520 correctly, because usually after major or even small release we 512 00:35:31,720 --> 00:35:36,800 and if we introduced some, you know, incompatibility, some bugs 513 00:35:36,800 --> 00:35:40,960 and so on, we immediately can see the audience reaction. 514 00:35:41,400 --> 00:35:48,920 While if we just make a small version bump without any bugs 515 00:35:48,920 --> 00:35:53,400 introduced, everything is quiet in our channels and this is a 516 00:35:53,400 --> 00:35:58,920 good sign. So version 2 is a quiet version, 517 00:35:59,120 --> 00:36:04,200 so nobody complaints. That's perfect. 518 00:36:04,200 --> 00:36:06,680 That's awesome. You got a shout out. 519 00:36:06,920 --> 00:36:08,720 I put it on the screen, but I'll put it here. 520 00:36:08,720 --> 00:36:11,120 Again, huge shout out. Many thanks, Roman for creating 521 00:36:11,120 --> 00:36:13,560 Beanie little rocket ship. That's awesome. 522 00:36:13,560 --> 00:36:16,360 I know a lot of people are very excited about, you know, Beanie 523 00:36:16,360 --> 00:36:19,320 in general, so it's awesome to have you here. 524 00:36:19,600 --> 00:36:22,520 Another question that I had was a lot of people use, you know, 525 00:36:22,520 --> 00:36:27,200 fast API, Flask, Django. How does Beanie integrate with 526 00:36:27,240 --> 00:36:31,680 those popular frameworks? Yeah. 527 00:36:32,080 --> 00:36:37,720 So as soon one of the reasons to create Binu was to support the 528 00:36:37,720 --> 00:36:44,520 new stack and by design it was supporting like it was 529 00:36:45,520 --> 00:36:52,080 implemented on base of identity, which means it can be integrated 530 00:36:52,080 --> 00:36:57,120 into fast API really smoothly. In fast API there are a few 531 00:36:57,520 --> 00:37:03,400 corner cases how it creates, for example, how it creates open API 532 00:37:03,400 --> 00:37:07,360 contracts and so on. And being supports such such 533 00:37:07,360 --> 00:37:11,320 corner cases as well to only show the necessary information 534 00:37:11,320 --> 00:37:17,200 like without showing fields that we use only under the hood and 535 00:37:17,200 --> 00:37:23,720 we don't want to expose them for example in the contracts and so 536 00:37:23,720 --> 00:37:27,280 on. So yeah, by design it's identic 537 00:37:27,280 --> 00:37:34,000 stack and it's supports well by fast API and other potential 538 00:37:34,000 --> 00:37:39,400 based frameworks and libraries. Thanks. 539 00:37:40,160 --> 00:37:43,360 Considering all the talks with the new features and the things 540 00:37:43,360 --> 00:37:47,560 coming up, what's the near future for Bini within the next 541 00:37:47,560 --> 00:37:51,520 12-6 to 12 months and what should we get excited about? 542 00:37:54,040 --> 00:37:57,840 So actually Beeni currently is a very stable library. 543 00:37:57,840 --> 00:38:03,280 Like the time when we introduced it to like new big feature every 544 00:38:03,680 --> 00:38:08,000 few months was like 2-3 years ago. 545 00:38:08,040 --> 00:38:12,720 Currently we mostly work about performance, scalability and 546 00:38:12,720 --> 00:38:15,440 other stuff. So currently I'm working on 547 00:38:16,520 --> 00:38:22,840 making Beeni a bit more lightweight on a startup because 548 00:38:22,840 --> 00:38:27,840 Bini is not only used in micro services where the warm up step 549 00:38:28,000 --> 00:38:31,280 could be. So if it can be, it can be long 550 00:38:31,280 --> 00:38:36,440 and it's not a problem. But Bini is also used in Lambda 551 00:38:36,440 --> 00:38:41,120 functions and alternatives in different cloud providers where 552 00:38:41,120 --> 00:38:45,000 this is critical, like how fast library could be installized, 553 00:38:45,000 --> 00:38:48,360 for example. So currently I'm working on 554 00:38:48,360 --> 00:38:53,520 this, on making installation step lightweight, making 555 00:38:53,520 --> 00:38:56,200 everything as lazy as possible and so on. 556 00:38:56,200 --> 00:39:00,760 So mostly working on performance and scalability because this is 557 00:39:00,760 --> 00:39:07,480 critical in our time as well. Yeah, that's I think that's the 558 00:39:07,480 --> 00:39:09,640 answer. Heard that. 559 00:39:10,720 --> 00:39:14,880 Thank you so much for that. OK, so I I have a little 560 00:39:14,880 --> 00:39:17,360 question. If people want to contribute to 561 00:39:17,360 --> 00:39:20,240 Beanie, what is the best way for them to do so? 562 00:39:21,200 --> 00:39:25,520 Yeah, we already have a team of contributors and I'm I super 563 00:39:25,520 --> 00:39:30,160 appreciate their help and they do most of the work already 564 00:39:30,680 --> 00:39:33,840 without me like last year probably. 565 00:39:33,840 --> 00:39:36,920 They are super active as developers, as community 566 00:39:36,920 --> 00:39:41,120 managers and so on. We have a Discord channel where 567 00:39:41,120 --> 00:39:46,640 we communicate where we plan our new features and what we can do 568 00:39:46,640 --> 00:39:52,280 and what we actually should do. And we help others, people who 569 00:39:52,280 --> 00:39:56,200 just joined community or started to work with Bini. 570 00:39:56,600 --> 00:40:01,440 There are special sections there like help and other discussions. 571 00:40:02,000 --> 00:40:06,400 And if you want to help with Bini development, please join 572 00:40:06,400 --> 00:40:11,160 our Discord server. And so we have a few groups 573 00:40:11,360 --> 00:40:16,400 there, public and private, where we can discuss how we could 574 00:40:16,400 --> 00:40:20,560 help. Perfect and. 575 00:40:20,560 --> 00:40:25,040 Then, is the Beanie Discord the best way for anyone who's 576 00:40:25,040 --> 00:40:26,560 watching to get in touch with you? 577 00:40:27,720 --> 00:40:33,920 If you just faced like a problem, like issue or any bug, 578 00:40:34,000 --> 00:40:39,040 you just can send GitHub issue and it would be enough. 579 00:40:39,040 --> 00:40:43,680 So we read all of them and we try to answer fast and if it's 580 00:40:43,680 --> 00:40:48,120 critical or high importance, we for sure we'll solve it fast as 581 00:40:48,120 --> 00:40:52,360 well. But if you want to chat to talk, 582 00:40:52,640 --> 00:40:54,760 it's better to go to Discord server, yeah. 583 00:40:56,440 --> 00:41:05,080 Perfect. And so which resources do you 584 00:41:05,080 --> 00:41:08,360 recommend that developers look at when they're first getting 585 00:41:08,360 --> 00:41:13,040 started? We have a documentation on the 586 00:41:13,040 --> 00:41:20,480 website Bini dash ODM dot dev. It's well written documentation 587 00:41:20,480 --> 00:41:25,120 comprehensive like it's written in shape of tutorial admin. 588 00:41:25,120 --> 00:41:29,440 So we tried to explain every user scenario and how it could 589 00:41:29,440 --> 00:41:34,040 be covered by Bini features. So please firstly go there. 590 00:41:34,040 --> 00:41:38,640 There are fast start section and comprehensive tutorial 591 00:41:38,640 --> 00:41:42,360 documentation there. I think you will read everything 592 00:41:42,360 --> 00:41:43,840 you need for your first steps there. 593 00:41:46,240 --> 00:41:49,200 And yeah, and you can go to the GitHub channel as soon as this 594 00:41:49,200 --> 00:41:52,400 is item, you just can read the code itself. 595 00:41:52,920 --> 00:41:56,600 It's pretty clear to understand the logic there. 596 00:41:56,600 --> 00:42:01,520 So if you faced any corner cases and you want to dig deeper, you 597 00:42:01,520 --> 00:42:04,680 just can read the quote. Perfect. 598 00:42:05,120 --> 00:42:10,040 And you're getting a lot of love in the comments right now, but 599 00:42:10,040 --> 00:42:13,880 from everyone who's watching, if you have any questions at all, 600 00:42:14,200 --> 00:42:16,920 now is the time for you to ask all of them. 601 00:42:17,440 --> 00:42:19,520 You can ask the experts yourself. 602 00:42:19,520 --> 00:42:22,440 If any questions for Shupon, any questions for Roman, any 603 00:42:22,440 --> 00:42:25,800 questions for me, any questions for Avi, please feel free. 604 00:42:27,280 --> 00:42:29,320 But yeah, that demo was incredible. 605 00:42:29,320 --> 00:42:32,640 The explanations were fantastic. The questions asked were great. 606 00:42:33,000 --> 00:42:35,280 So I just want to say, Roman, thank you so much, you know, for 607 00:42:35,280 --> 00:42:38,920 taking the time to be here. I know that Beanie is super 608 00:42:38,920 --> 00:42:41,520 beneficial for so many developers. 609 00:42:43,120 --> 00:42:47,400 Oh, I'm seeing that. We have a couple questions. 610 00:42:48,000 --> 00:42:52,040 OK, So what are the best practices for creating composite 611 00:42:52,040 --> 00:42:56,200 or text indexes? Is the first one, and there's 612 00:42:56,200 --> 00:42:59,560 another one, but I'll answer that or I'll ask that actually 613 00:42:59,560 --> 00:43:05,800 the first one's answered. So it's always hard to answer 614 00:43:05,800 --> 00:43:10,600 such questions without knowing the context of the lot profile 615 00:43:10,920 --> 00:43:17,000 of the, how big the collections and and so on. 616 00:43:17,120 --> 00:43:22,200 I'd say you have to like if you need to compound index, then you 617 00:43:22,200 --> 00:43:27,400 understand that you query using that combinations of these 618 00:43:27,400 --> 00:43:31,040 fields and you already understand your load profile. 619 00:43:31,040 --> 00:43:35,360 So then you just have to create such a combined index and it 620 00:43:35,360 --> 00:43:39,800 will work that if you don't understand your load profile, 621 00:43:41,480 --> 00:43:46,800 you probably have to create some load tests to understand what is 622 00:43:46,800 --> 00:43:51,920 hot pass for your query. Like when you what is the most 623 00:43:51,920 --> 00:43:56,040 frequent request and for which requests you spend the most time 624 00:43:56,360 --> 00:44:02,120 and then like the most time is literally in milliseconds. 625 00:44:02,120 --> 00:44:05,760 Like which request single request takes a lot as most of 626 00:44:05,760 --> 00:44:08,680 the time. And in some like there are 627 00:44:08,680 --> 00:44:13,280 situations when single request is very slow but you request 628 00:44:13,280 --> 00:44:16,920 like a few times per day and there are more or less fast 629 00:44:16,920 --> 00:44:22,920 requests but you shoot them like 1000 times per second. 630 00:44:22,960 --> 00:44:26,640 And actually, this is a place to improvement. 631 00:44:28,320 --> 00:44:30,400 So yeah. And then you can just understand 632 00:44:30,960 --> 00:44:35,760 what you're looking for and exactly how you're looking for. 633 00:44:35,760 --> 00:44:41,120 You should tap your indexes. This is this is a best practice. 634 00:44:42,400 --> 00:44:44,880 Perfect. And then do you have any advice 635 00:44:44,880 --> 00:44:49,040 for indexes on a vector field? That is the second part of the 636 00:44:49,080 --> 00:44:51,640 question. Sir, could you please repeat on 637 00:44:51,640 --> 00:44:54,160 which field? On vector fields. 638 00:44:56,520 --> 00:45:01,480 Yeah, I see. Actually I'm, I'm not that 639 00:45:01,480 --> 00:45:04,680 experienced in that field. I'm just playing with this. 640 00:45:05,040 --> 00:45:14,680 So I cannot have expert opinion about factor fields, but but 641 00:45:14,680 --> 00:45:16,840 yeah, it's it's fun. It's fun to play with them. 642 00:45:16,840 --> 00:45:19,440 So I'm just starting to play with them as well. 643 00:45:19,440 --> 00:45:24,080 So sorry audience, but I'm not the the one who could answer 644 00:45:24,080 --> 00:45:28,760 this. Yes, we, we, we can chat offline 645 00:45:28,760 --> 00:45:30,920 about this. We have been working internally 646 00:45:30,920 --> 00:45:34,760 on on a project for adding vector source capability and 647 00:45:34,760 --> 00:45:39,000 some of the Odms and and I think this is a great collaboration of 648 00:45:39,000 --> 00:45:40,800 our study for us to talk. Thanks. 649 00:45:40,880 --> 00:45:45,200 I'll set up some time for us. And then you have some more love 650 00:45:45,200 --> 00:45:50,040 from Marco, who's saying that it is his favorite manga DPODM, 651 00:45:50,320 --> 00:45:53,400 which is awesome. Thank. 652 00:45:53,400 --> 00:45:58,440 You it's my favorite as well. Well. 653 00:45:58,440 --> 00:46:01,920 Mine too, mine too Roman. You do a great job at not only 654 00:46:01,920 --> 00:46:03,680 creating the library, but maintaining and keeping us. 655 00:46:03,680 --> 00:46:06,040 Is a great shape and. Will thank you. 656 00:46:07,760 --> 00:46:10,400 Thank you so much and thank you everyone for joining. 657 00:46:10,400 --> 00:46:13,800 If you have any questions leftover that we weren't able to 658 00:46:13,800 --> 00:46:17,440 ask, please just leave them in the comment section of either 659 00:46:17,440 --> 00:46:20,520 the YouTube link or the LinkedIn link, and then someone will 660 00:46:20,520 --> 00:46:22,320 definitely be able to get to you. 661 00:46:22,320 --> 00:46:25,440 But if no one has any more questions, then we can end the 662 00:46:25,440 --> 00:46:27,960 live stream here. Thank you everyone for watching. 663 00:46:28,160 --> 00:46:31,400 Thank you, Roman and Shubham and AFI for joining me today. 664 00:46:31,760 --> 00:46:34,480 This has been a ton of fun. Yeah. 665 00:46:34,480 --> 00:46:37,280 Thank you so much for everyone. Thank you very much.