The video owner has disabled playback on external websites.
This video is no longer available on YouTube.
This video cannot be played right now.
Watch on YouTube
KI-gestützte Lerntools freischalten
Registriere dich, um leistungsstarke Tools zu nutzen, die dir helfen, schneller aus jedem Video zu lernen.
CQRS in Python: Clean Reads, Clean Writes
Untertitel (558 Segmente)
Let's say you're doing customer support
for OpenAI and you want to compute some
data to get an idea of how broken your
product is, but your API is a bit
limited and can only return all ticket
data at once. That is probably a lot of
data. On top of that, say you're running
some analytics script that gathers that
data while those support tickets are
flowing in, your reads and your rights
may interfere and that leads to all
sorts of performance issues. Now, you
can avoid all those problems using the
CQRS architecture. And I'll explain
exactly how it works in this video using
an example with fast API and MongoDB. I
talk about when to use it and when not
to use it and why MongoDB actually fits
this architecture really well. That's
why they're also the sponsor of this
video. Now, let's take a look at the
code. Like I said, the starting point is
a fast API app that uses MongoDB. So
first create this file that uses pyongo
to set up a MongoDB database. So create
some uh URL. This by the way I'm running
MongoDB locally on my machine with
Docker Compose and then I define a
database type. I create a client
with that URL. And then I have a couple
of functions that are useful in my app
like getting the database which will be
injected into the endpoints uh shutting
down the database and some helpful
things like being able to convert
strings to and from object ids. Now the
API app itself is then also pretty
straightforward. So I have a collection
of tickets, customer support tickets.
These tickets can have a status that's
either open, triaged or closed. Uh I
have a couple of other functions that
are useful like getting the current
time. Uh making a preview of a message
that's part of a customer support
ticket. Then I create the app. Uh
there's a startup phase which gets the
DB and set some indices which is helpful
for uh you know common queries that we
do. Uh then there's of course shutting
down the database when the app shuts
down. And then there's a couple of
pyantic models. uh one for creating
tickets uh one for updating tickets. As
you can see, we can update the status or
add a note to a customer support ticket.
Then we have a ticket details model that
contains basically everything related to
the ticket. And then there's another uh
model here called ticket list item that
I'll talk about in a minute. And then we
have some endpoints. So I can post to
the tickets endpoint and that gets a
payload which is this ticket in then
creates a ticket. uh we have updating a
ticket uh that this is actually kind of
a complicated operation because well uh
of course first have to check that the
ticket actually exists then uh we can
only update certain things in certain
ways. For example, if a status is closed
then uh we cannot reopen that ticket in
this particular setup. And for updating
the agent there is actually no rule
though we can simply update that. And
then I have list tickets endpoint that
retrieves tickets. talk more about that
in a minute. Uh we have retrieving a
particular ticket uh given an ID and I
have a sort of dashboard endpoint that
does some aggregates like collecting how
many tickets are open, triaged and
closed. So that's the API and this
interacts with this database that I
created right here. Let's say that there
is a UI requirement that the list view
needs some extra information like a
short preview of the agent note or a has
note boolean flag. So what you would do
if you just implement stuff right inside
this fast API app is that you would have
this ticket list item model that
contains the um preview message and a
has node boolean value, right? And then
in the endpoint where we list the
tickets, we would basically return that
as a response model. And that's already
where you see kind of a problem
occurring here because in this uh list
view, we need to of course compute this
preview and compute whether there there
is a note. That means that every time
you list the tickets using this endpoint
that these things are going to be
computed. Now, of course, computing a
preview message and whether there's a
note or not is not really that
computationally intensive unless you
have a lot of tickets, but uh you can
imagine that there are other things that
may also add uh extra uh computation and
extra problems if you need to compute
Vollständige Untertitel im Videoplayer verfügbar
Mit Übungen trainieren
Erstelle Vokabel-, Grammatik- und Verständnisübungen aus diesem Video
Kommentare (0)
Zum Kommentieren AnmeldenRegistriere dich, um alle Features freizuschalten
Verfolge deinen Fortschritt, speichere Vokabeln und übe mit Übungen
Interaktiver Modus
Quiz
Richtige Antwort:
Quiz
Richtige Antwort:
Quizfragen erscheinen beim Anschauen des Videos
Merkhilfe
Aus diesem Video
Kostenlos Sprachen lernen
