April 15, 2026 • 46 mins
Watch this episode in video format on Spotify!
If you're building Python applications on MongoDB and still writing raw queries by hand, you're leaving a lot of developer productivity on the table. Beanie, the async-first ODM built on Pydantic, was created to fix exactly that — and this episode goes deep on how and why it works.
You'll learn how Beanie maps Python objects to MongoDB documents without sacrificing atomicity or performance, why async-first design matters for modern Python stacks, how schema migrations actually work in a document database, and what the deprecation of Motor means for your existing codebase. The episode also covers Beanie's integration with FastAPI, how it handles indexes and aggregation pipelines under the hood, and what's coming in the next phase of the library.
Ramon, the creator of Beanie and a senior software engineer at Microsoft, built this library five years ago to fill a gap nobody else had addressed. He's joined by Shubham, MongoDB's product manager for Python client libraries, for a live demo and Q&A.
Follow The MongoDB Podcast so you never miss an episode.
-
- [00:00] Introduction & Guest Welcome
- [01:00] What Is Beanie? The ODM Explained
- [04:10] ODM vs ORM — What's the Difference?
- [05:20] Why Ramon Built Beanie (The Origin Story)
- [06:30] Core Design Principles: Atomicity & Async-First
- [08:00] FastAPI + MongoDB: The Rising Python Stack
- [11:00] Bonnet: The Synchronous Beanie Backport
- [12:55] Live Demo: Defining Document Schemas with Pydantic
- [16:00] Nested Documents, Links & Polymorphic Collections
- [18:45] Best Practices for Schema Design
- [20:30] Index Management in Beanie
- [22:40] Complex Queries: Beanie vs Raw PyMongo
- [24:30] Aggregation Pipelines in Beanie
- [28:05] Schema Migrations: Forward, Backward & Freefall
- [31:30] Motor Is Deprecated — What That Means for You
- [34:00] Beanie v2: What Changed and What Didn't
- [36:20] FastAPI, Flask & Django Integration
- [37:45] What's Next for Beanie: Performance & Lambda Optimization
- [39:30] How to Contribute to Beanie
- [41:00] Resources, Community & Audience Q&A
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Hello, 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 aboutthe Python library.
You're going to chat all together, go through a hands on
(00:23):
demo and then leave some time atthe end for questions straight
from all of you, all from the audience.
So I'm going to go ahead and I'mgoing 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
(00:45):
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.
(01:08):
Hey 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.
(01:28):
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.
So first, of course, it's a verysmall agenda.
We have some housekeeping that we're just going to quickly go
(01:49):
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 ableto 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
(02:10):
any questions that we may have missed and also give all you
have some fantastic resources tolearn more.
So 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.
(02:32):
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.
So let's get started. Let's start off with some intros
(02:57):
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
(03:21):
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.
Like it can search, it can update, it can remain and it can
(03:43):
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.
(04:05):
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 aremore familiar with what an ORM
is. Yeah, happy to take that one.
And ORM literally stands for Object Relational Mapper.
(04:27):
It basically maps the objects inyour 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 thesame thing for developers that
let you work with native language objects and queries
instead of writing either SQL for all MQL commands.
(04:50):
The main differences in underlying data model relational
versus document based. Very cool.
That'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,
(05:10):
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'sa bit low level like people have
(05:32):
to work with as Shuman talked with various directly, while
actually there are Odms is spelled like Mongo engine.
But 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
(05:53):
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 vinion that stack as well.
(06:17):
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.
So every I wanted to first of all to mimic everything as
possible from motor, from from Pymonga.
(06:38):
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 willhave race conditions and other
(06:59):
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
(07:23):
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.
And like every time, it was great ideas to add features to
to Benny loved. That thank you for going over
(07:47):
that. So kind of from from your
answer, I wanted to ask how doesBenny'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.
(08:09):
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
(08:29):
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 haveto create any threats and so on.
We just can use asyncrovate approach for that.
(08:50):
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
(09:10):
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 usersas like the main PM.
(09:31):
Have 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
(09:52):
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
(10:16):
native vector storage capabilityas well as now with our voyage
AI position, you can generate embeddings within the one
platform or would you be access platform.
So 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
(10:38):
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.
Love that, Sir. Thank you.
(10:59):
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
(11:20):
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 ittakes too much.
So what? What is the reason to have ban
it? There are still a lot of people
(11:43):
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 workaroundsto make a synchronous library
(12:07):
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 synchronouscalls forum our site.
It's not that complicated to just rework everything to
support internals as well. So one that is completely the
(12:30):
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.
(12:51):
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?
So if you could give us a littleexplanation, but if you need to
show us, that would be awesome as well.
(13:12):
Yeah, sure. So Pidentic is a library that
gives us all the all the freedomof how we can use the data, use
different types and makes the data nested.
(13:35):
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
(13:57):
and we still want to use freedomof types and so on.
But we still want to understand like in general what we keep in
our collection and to be able towork 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
(14:20):
database and what you receive from a database.
Bini supports a few different ways to store things like.
Here you can see the very simplemodel User.
It consists of name and e-mail only as strings.
Here you can put any data type. It can be your ID, numbers,
(14:48):
date, date, time and so on. So it doesn't matter actually.
But 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 canusing this models we can add for
(15:15):
example post it would look like this so.
Sorry, is there any way that youcould 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?
(15:35):
Can we do a little bit bigger, just so, just so the audience
can see? Yeah.
Thank you. So much sorry for that. 200% I
think it should be visible rightnow, yes.
Yes, that's a lot better. Thank you.
Sylvia and here we can like in the post.
Here for example we can use Useras user mapping directly
(16:00):
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
(16:26):
user into the bracket. So it means how how we did work.
User 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
(16:47):
will be a link to another collection.
But when we will work with Python code with Bini everything
would be fetched and we can workwith everything together.
And as there is another one interesting sync in Bini, you
can use single collection to keep your documents in different
(17:11):
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
(17:38):
for article level for tutorial. And everything would stay in the
same collection in the post collection.
But 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
(18:02):
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.
(18:24):
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
(18:46):
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 firstshot.
Like make everything as simple as possible at the at the very
(19:07):
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
(19:29):
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
(19:51):
fast as civil validation, so it's great.
It 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.
(20:13):
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:35):
So 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.
(20:57):
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
(21:18):
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.
I think. I will not edit here, but we can
go to the documentation. Let's go here because there are
(21:43):
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
(22:04):
be compound indexes with different with different
properties like name like way tosort ascending, ascending and so
on. So on.
This way we can create many indexes per collection just in
the inner settings class for the, for the model, for the, for
(22:27):
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 mongoindex model, so we can create it
the same way as we do it for π mongo.
(22:50):
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?
And 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.
(23:14):
Working with native driver like pymongo gives you full control
over your query is, which is ourfault, 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.
There'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,
(23:37):
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
(24:01):
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.
And that has been a problem withthat whole OMODM space in
general. But it's a trade off.
(24:21):
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.
(24:42):
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.
How is that done in BD and how is that different from other
ODMS? So aggregation pipeline as soon
(25:05):
aggregation pipeline it. In general aggregation framework
as we name it in Mongo DB is a very complicated thing.
So Bini supports aggregation butit supports it on a low level.
We can create a pipeline and we should use this computer to the
(25:25):
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
(25:48):
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
(26:12):
such complicating as aggregationframework.
So 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,
(26:34):
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
(26:56):
document of the another collection.
And in general how it works internally.
As soon Mongo DB doesn't supportsuch references, we use
aggregation framework under their hood.
And for this for sure we have touse indexes.
If we need links from one thing to another we already can use ID
(27:19):
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.
But this is already complicated scenarios.
(27:41):
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.
(28:07):
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:32):
It'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
(28:54):
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
(29:17):
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.
Why we do support both Forward is migration from old to new.
(29:39):
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 incase you migrated everything and
(30:03):
you have no way to migrate everything backward.
So 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
(30:27):
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
(30:49):
and it works. And there is a more complicated
fail called free fall immigration, where users set up
everything on their own. Fantastic.
Thank 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
(31:13):
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,
(31:33):
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.
And I kind of wanted to ask a question to you, Shivam, about
that, about motor being depreciated in favor of async
(31:56):
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
(32:19):
and and Motor for asynchronous application.
However, 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
(32:39):
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
(33:01):
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 releaseand and our internal benchmarks
show performance gains of up to 10 to 30% for highly print
(33:24):
workloads. If you're using async API in
Timeongo, so it's a win, win. And and you know, for developers
who 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
(33:46):
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 thefirst message that payment will
support a synchronous way. We immediately created this,
(34:09):
this thing. And yeah, we've emigrated.
It sexually was straightforward.We only had to remove everything
about motor from our code base and replace with pymongo.
But we introduced a few breakingchanges because of the naming
(34:29):
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
(34:53):
it's a braking change it's the second version of Beni now.
Yeah, that's awesome. I was going to ask about that
because I know that Beni version2 was released last weekend,
right? So it's very new.
Have you heard any feedback fromthe community about amusing
(35:14):
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 aftermajor or even small release we
and if we introduced some, you know, incompatibility, some bugs
(35:36):
and so on, we immediately can see the audience reaction.
While 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,
(35:59):
so nobody complaints. That's perfect.
That's awesome. You got a shout out.
I put it on the screen, but I'llput 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:19):
Another 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 tocreate Binu was to support the
new stack and by design it was supporting like it was
(36:45):
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, forexample, how it creates open API
contracts and so on. And being supports such such
(37:07):
corner cases as well to only show the necessary information
like without showing fields thatwe use only under the hood and
we don't want to expose them forexample 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
(37:34):
based frameworks and libraries. Thanks.
Considering 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?
(37:54):
So actually Beeni currently is avery stable library.
Like the time when we introducedit 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
(38:16):
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
(38:41):
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.
So mostly working on performanceand scalability because this is
critical in our time as well. Yeah, that's I think that's the
(39:07):
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 forthem 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
(39:30):
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 ournew features and what we can do
and what we actually should do. And we help others, people who
(39:52):
just joined community or startedto work with Bini.
There are special sections therelike 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, wherewe can discuss how we could
(40:16):
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:39):
So 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
(41:05):
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:25):
So 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 andcomprehensive tutorial
documentation there. I think you will read everything
you need for your first steps there.
(41:46):
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 casesand you want to dig deeper, you
just can read the quote. Perfect.
And you're getting a lot of lovein the comments right now, but
(42:10):
from everyone who's watching, ifyou 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, anyquestions 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.
(42:33):
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.
Oh, 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
(42:56):
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.
(43:17):
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.
So then you just have to create such a combined index and it
will work that if you don't understand your load profile,
(43:41):
you probably have to create someload 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.
(44:02):
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 like1000 times per second.
(44:22):
And actually, this is a place toimprovement.
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
(44:44):
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:05):
So 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
(45:28):
about this. We have been working internally
on on a project for adding vector source capability and
some of the Odms and and I thinkthis is a great collaboration of
our study for us to talk. Thanks.
I'll set up some time for us. And then you have some more love
from Marco, who's saying that itis his favorite manga DPODM,
(45:50):
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.
(46:10):
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 LinkedInlink, and then someone will
definitely be able to get to you.
But 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 andAFI for joining me today.
(46:31):
This has been a ton of fun. Yeah.
Thank you so much for everyone. Thank you very much.
Hello, 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 aboutthe Python library.
You're going to chat all together, go through a hands on
(00:23):
demo and then leave some time atthe end for questions straight
from all of you, all from the audience.
So I'm going to go ahead and I'mgoing 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
(00:45):
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.
(01:08):
Hey 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.
(01:28):
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.
So first, of course, it's a verysmall agenda.
We have some housekeeping that we're just going to quickly go
(01:49):
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 ableto 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
(02:10):
any questions that we may have missed and also give all you
have some fantastic resources tolearn more.
So 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.
(02:32):
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.
So let's get started. Let's start off with some intros
(02:57):
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
(03:21):
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.
Like it can search, it can update, it can remain and it can
(03:43):
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.
(04:05):
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 aremore familiar with what an ORM
is. Yeah, happy to take that one.
And ORM literally stands for Object Relational Mapper.
(04:27):
It basically maps the objects inyour 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 thesame thing for developers that
let you work with native language objects and queries
instead of writing either SQL for all MQL commands.
(04:50):
The main differences in underlying data model relational
versus document based. Very cool.
That'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,
(05:10):
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'sa bit low level like people have
(05:32):
to work with as Shuman talked with various directly, while
actually there are Odms is spelled like Mongo engine.
But 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
(05:53):
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 vinion that stack as well.
(06:17):
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.
So every I wanted to first of all to mimic everything as
possible from motor, from from Pymonga.
(06:38):
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 willhave race conditions and other
(06:59):
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
(07:23):
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.
And like every time, it was great ideas to add features to
to Benny loved. That thank you for going over
(07:47):
that. So kind of from from your
answer, I wanted to ask how doesBenny'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.
(08:09):
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
(08:29):
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 haveto create any threats and so on.
We just can use asyncrovate approach for that.
(08:50):
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
(09:10):
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 usersas like the main PM.
(09:31):
Have 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
(09:52):
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
(10:16):
native vector storage capabilityas well as now with our voyage
AI position, you can generate embeddings within the one
platform or would you be access platform.
So 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
(10:38):
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.
Love that, Sir. Thank you.
(10:59):
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
(11:20):
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 ittakes too much.
So what? What is the reason to have ban
it? There are still a lot of people
(11:43):
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 workaroundsto make a synchronous library
(12:07):
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 synchronouscalls forum our site.
It's not that complicated to just rework everything to
support internals as well. So one that is completely the
(12:30):
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.
(12:51):
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?
So if you could give us a littleexplanation, but if you need to
show us, that would be awesome as well.
(13:12):
Yeah, sure. So Pidentic is a library that
gives us all the all the freedomof how we can use the data, use
different types and makes the data nested.
(13:35):
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
(13:57):
and we still want to use freedomof types and so on.
But we still want to understand like in general what we keep in
our collection and to be able towork 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
(14:20):
database and what you receive from a database.
Bini supports a few different ways to store things like.
Here you can see the very simplemodel User.
It consists of name and e-mail only as strings.
Here you can put any data type. It can be your ID, numbers,
(14:48):
date, date, time and so on. So it doesn't matter actually.
But 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 canusing this models we can add for
(15:15):
example post it would look like this so.
Sorry, is there any way that youcould 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?
(15:35):
Can we do a little bit bigger, just so, just so the audience
can see? Yeah.
Thank you. So much sorry for that. 200% I
think it should be visible rightnow, yes.
Yes, that's a lot better. Thank you.
Sylvia and here we can like in the post.
Here for example we can use Useras user mapping directly
(16:00):
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
(16:26):
user into the bracket. So it means how how we did work.
User 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
(16:47):
will be a link to another collection.
But when we will work with Python code with Bini everything
would be fetched and we can workwith everything together.
And as there is another one interesting sync in Bini, you
can use single collection to keep your documents in different
(17:11):
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
(17:38):
for article level for tutorial. And everything would stay in the
same collection in the post collection.
But 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
(18:02):
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.
(18:24):
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
(18:46):
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 firstshot.
Like make everything as simple as possible at the at the very
(19:07):
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
(19:29):
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
(19:51):
fast as civil validation, so it's great.
It 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.
(20:13):
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:35):
So 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.
(20:57):
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
(21:18):
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.
I think. I will not edit here, but we can
go to the documentation. Let's go here because there are
(21:43):
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
(22:04):
be compound indexes with different with different
properties like name like way tosort ascending, ascending and so
on. So on.
This way we can create many indexes per collection just in
the inner settings class for the, for the model, for the, for
(22:27):
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 mongoindex model, so we can create it
the same way as we do it for π mongo.
(22:50):
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?
And 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.
(23:14):
Working with native driver like pymongo gives you full control
over your query is, which is ourfault, 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.
There'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,
(23:37):
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
(24:01):
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.
And that has been a problem withthat whole OMODM space in
general. But it's a trade off.
(24:21):
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.
(24:42):
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.
How is that done in BD and how is that different from other
ODMS? So aggregation pipeline as soon
(25:05):
aggregation pipeline it. In general aggregation framework
as we name it in Mongo DB is a very complicated thing.
So Bini supports aggregation butit supports it on a low level.
We can create a pipeline and we should use this computer to the
(25:25):
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
(25:48):
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
(26:12):
such complicating as aggregationframework.
So 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,
(26:34):
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
(26:56):
document of the another collection.
And in general how it works internally.
As soon Mongo DB doesn't supportsuch references, we use
aggregation framework under their hood.
And for this for sure we have touse indexes.
If we need links from one thing to another we already can use ID
(27:19):
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.
But this is already complicated scenarios.
(27:41):
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.
(28:07):
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:32):
It'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
(28:54):
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
(29:17):
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.
Why we do support both Forward is migration from old to new.
(29:39):
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 incase you migrated everything and
(30:03):
you have no way to migrate everything backward.
So 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
(30:27):
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
(30:49):
and it works. And there is a more complicated
fail called free fall immigration, where users set up
everything on their own. Fantastic.
Thank 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
(31:13):
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,
(31:33):
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.
And I kind of wanted to ask a question to you, Shivam, about
that, about motor being depreciated in favor of async
(31:56):
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
(32:19):
and and Motor for asynchronous application.
However, 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
(32:39):
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
(33:01):
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 releaseand and our internal benchmarks
show performance gains of up to 10 to 30% for highly print
(33:24):
workloads. If you're using async API in
Timeongo, so it's a win, win. And and you know, for developers
who 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
(33:46):
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 thefirst message that payment will
support a synchronous way. We immediately created this,
(34:09):
this thing. And yeah, we've emigrated.
It sexually was straightforward.We only had to remove everything
about motor from our code base and replace with pymongo.
But we introduced a few breakingchanges because of the naming
(34:29):
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
(34:53):
it's a braking change it's the second version of Beni now.
Yeah, that's awesome. I was going to ask about that
because I know that Beni version2 was released last weekend,
right? So it's very new.
Have you heard any feedback fromthe community about amusing
(35:14):
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 aftermajor or even small release we
and if we introduced some, you know, incompatibility, some bugs
(35:36):
and so on, we immediately can see the audience reaction.
While 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,
(35:59):
so nobody complaints. That's perfect.
That's awesome. You got a shout out.
I put it on the screen, but I'llput 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:19):
Another 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 tocreate Binu was to support the
new stack and by design it was supporting like it was
(36:45):
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, forexample, how it creates open API
contracts and so on. And being supports such such
(37:07):
corner cases as well to only show the necessary information
like without showing fields thatwe use only under the hood and
we don't want to expose them forexample 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
(37:34):
based frameworks and libraries. Thanks.
Considering 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?
(37:54):
So actually Beeni currently is avery stable library.
Like the time when we introducedit 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
(38:16):
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
(38:41):
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.
So mostly working on performanceand scalability because this is
critical in our time as well. Yeah, that's I think that's the
(39:07):
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 forthem 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
(39:30):
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 ournew features and what we can do
and what we actually should do. And we help others, people who
(39:52):
just joined community or startedto work with Bini.
There are special sections therelike 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, wherewe can discuss how we could
(40:16):
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:39):
So 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
(41:05):
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:25):
So 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 andcomprehensive tutorial
documentation there. I think you will read everything
you need for your first steps there.
(41:46):
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 casesand you want to dig deeper, you
just can read the quote. Perfect.
And you're getting a lot of lovein the comments right now, but
(42:10):
from everyone who's watching, ifyou 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, anyquestions 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.
(42:33):
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.
Oh, 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
(42:56):
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.
(43:17):
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.
So then you just have to create such a combined index and it
will work that if you don't understand your load profile,
(43:41):
you probably have to create someload 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.
(44:02):
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 like1000 times per second.
(44:22):
And actually, this is a place toimprovement.
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
(44:44):
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:05):
So 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
(45:28):
about this. We have been working internally
on on a project for adding vector source capability and
some of the Odms and and I thinkthis is a great collaboration of
our study for us to talk. Thanks.
I'll set up some time for us. And then you have some more love
from Marco, who's saying that itis his favorite manga DPODM,
(45:50):
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.
(46:10):
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 LinkedInlink, and then someone will
definitely be able to get to you.
But 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 andAFI for joining me today.
(46:31):
This has been a ton of fun. Yeah.
Thank you so much for everyone. Thank you very much.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Betrayal Weekly
Betrayal Weekly is back for a new season. Every Thursday, Betrayal Weekly shares first-hand accounts of broken trust, shocking deceptions, and the trail of destruction they leave behind. Hosted by Andrea Gunning, this weekly ongoing series digs into real-life stories of betrayal and the aftermath. From stories of double lives to dark discoveries, these are cautionary tales and accounts of resilience against all odds. From the producers of the critically acclaimed Betrayal series, Betrayal Weekly drops new episodes every Thursday. If you would like to share your story, you can reach out to the Betrayal Team by emailing them at betrayalpod@gmail.com and follow us on Instagram at @betrayalpod and @glasspodcasts. Please join our Substack for additional exclusive content, curated book recommendations, and community discussions. Sign up FREE by clicking this link Beyond Betrayal Substack. Join our community dedicated to truth, resilience, and healing. Your voice matters! Be a part of our Betrayal journey on Substack.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com