Shadowing Practice: 2.2k - Learn English Speaking with Video
בחר מצב תרגול
כל מצב פותח חדר תרגול במסך מלא.
129 משפטים
אם המשפטים קצרים או ארוכים מדי, לחץ על ערוך כדי להתאים אותם.
1
Hey friends, welcome back to the channel.
2
So when designing an API,
3
it's easy to think about the happy path of your application.
4
But if you want to build a robust application and keep your users happy,
5
then you need to consider the unhappy path as well.
6
What happens if your user's internet connection cuts out just after making a request?
7
Or maybe your server's struggling under load and the client times out before it can receive a response?
8
Usually errors are handled by the client by doing retries.
9
If there's an error or the request times out,
10
then the client will retry a number of times,
11
either automatically or by a frustrated user hitting that submit button.
12
If the user sends multiple requests to the server and more than one of them gets through,
13
then you'll likely end up with duplicates on your end.
14
Depending on the application, this might not be a big deal.
15
If the user is just writing a comment on a blog post or reviewing a product,
16
then it's not the end of the world if they end up with multiple posts.
17
But what if they're sending an email?
18
Is it okay for the recipients to receive multiple copies of the same email?
19
What if they were buying something online?
20
Would the customer be happy if they got charged twice or maybe even 10 times for the same product.
21
This is where idempotency comes in but what does it actually mean?
22
If we have a look at the internet standards it says the following.
23
A request method is considered idempotent
24
if the intended effect on the server of multiple identical requests with
25
that method is the same as the effect for a single such request.
26
So if we call an API multiple times with the same request then it's considered idempotent
27
if it has the same effect on the server as if we had only called it once.
28
Now let's have a look at the most common methods and see whether they're idempotent or not.
29
The get method is read only,
30
it doesn't affect the server in any way.
31
Nothing gets created or updated so we can call the get method multiple times without it having any adverse effects.
32
So a get method is always idempotent.
33
With a put request we're going to be performing updates.
34
So let's say we're updating a user's email address.
35
No matter how many times we call this method we should always get the same response
36
and the user's details are always going to get updated to the same thing.
37
So a put request is always idempotent as well.
38
With a post request we're creating something on the server.
39
So if we call this method multiple times then we should expect to get multiple copies of the same thing.
40
Or in some cases we might get an error if we're trying to create something that can only be one of.
41
For example if we're trying to create a new user with a post request.
42
Then the first request will go through but a second request for the same username will fail because the user already exists.
43
Technically this is still idempotent but it's not a very nice experience for the user user.
44
Let's say when they make their first request they then have an internet connection failure and therefore don't get a response.
45
When they try and retry it will tell them
46
that the username order exists but in fact it was their first request that created that user.
47
If we take the example of making a payment then generally
48
there aren't any unique identifiers on a payment like there are with creating a user.
49
This is what we typically might send through on a platform like Stripe if someone's buying something for $20.
50
However there is nothing unique about this request that links it to a particular purchase.
51
If a payment platform receives two of these then it'll just think it's two separate payments and charge the customer twice
52
which is not what we want.
53
So post requests are generally not idempotent.
54
With patch requests it depends on how you use them.
55
If you're just using it to update an email address of a user then that could be considered idempotent.
56
However you can also use a patch request to do things like copy,
57
move, add and remove and therefore it's not considered idempotent.
58
Finally we have the delete method which deletes an object on the server.
59
If you run delete multiple times it's going to have the same effect on the server as
60
if you'd only run it once.
61
Sure the second time you might run it you might get an error
62
but the actual server doesn't change its state therefore delete is also considered to be idempotent.
63
In the cases where you're making a payment or some other Crisco operation
64
that needs to happen exactly once then you need to make those other methods such as post and patch idempotent as well.
65
The only way that you can really do this is to have some form of unique identifier.
66
That way you can distinguish that request from some otherwise identical requests.
67
You may have something like this already in place.
68
Let's go back to the payment analogy.
69
Let's say you have a saved basket of items and that basket has an ID.
70
That ID is therefore unique to that order and you could use that ID for the idempotency key.
71
Another option is to hash the body of the request.
72
However if you're doing this you need to make sure
73
that there's no reason for that person to ever send exactly the same request.
74
There should be something about the combination of fields in the request that makes it unique.
75
For example if someone orders a Spongebob beach towel
76
and then 30 seconds later orders another Spongebob beach towel you don't know that that's a duplicate order.
77
They might just really like Spongebob.
78
Generally the way this is normally done is to add an idempotency key to a header.
79
Stripe for example have a header called idempotency-key but really this could be anything.
80
So you now have some form of key that makes this request unique.
81
However with a user supplied key you can't guarantee that it's going to be globally unique.
82
The user could send you the same key as another user or even the same key from multiple endpoints.
83
So it's important you always combine
84
that user supply key with something like a user id as well as the API path that's being used.
85
To implement idempotency you need to store your combined idempotency key along with the successful response that you send to the user.
86
If a request with the same idempotency key comes in instead of actually performing the operation,
87
you just send them back a response that you sent out before.
88
As far as the user is concerned,
89
the operation was successful and they don't need to know that you're sending out a previous response.
90
Typically this is done using some form of key value storage such as Redis or DynamoDB.
91
Technically you could store your idempotency keys in an in-memory storage such as a dictionary.
92
However this won't work if you have multiple copies of your API running behind the load balancer,
93
as each API won't be able to see the keys in the other copies.
94
You will also lose your idempotency keys whenever you have to restart your application.
95
This is why we don't store them in memory.
96
So when a request comes in you need to first check to see whether
97
that idempotency key that's been sent is in your storage.
98
And if it is then you just send back the response that you have stored.
99
If the idempotency key doesn't exist then you carry on with the normal operation
100
and if it's successful then you store the idempotency key along with the response before sending it back to the user.
101
How long you store your idempotency keys for really depends on the application.
102
If you have idempotency enabled just to protect yourself from a
103
user clicking on something multiple times then you might only need to store them for say 10 minutes.
104
But if you have some sort of retry mechanism in place then you might need to store them for longer.
105
Typically we store idempotency keys for anywhere between 24 and 48 hours
106
but you need to check with your application and see if it makes sense to store them for longer.
107
If you are using something like redis
108
or dynamo db to store your keys then you can use the time to live
109
or ttl so that your keys are automatically deleted for you.
110
You may also want to consider idempotency validation in your API.
111
If a request comes in with the same idempotency key from
112
the same user for the same endpoint then we're just going to assume
113
that that's the same request and send them out the same response.
114
However there is a chance
115
that the user has just used the same idempotency key by mistake and the request body is actually very different.
116
If you need to protect yourself against this sort of scenario then you can take a hash of the request
117
and store that alongside the idempotency key and then
118
when the request comes in you can check to see whether it matches the hash as well
119
and if it doesn't return an error to the user.
120
If you want to implement this in the .NET Core API then you can make use of the distributed caching library
121
and then store your keys in redis and then you can create a filter
122
which you can then add to each of the endpoints where
123
you want idempotency to make this even easier there is a new get package called idempotent api
124
that does all the heavy lifting for you
125
if you want to support this channel
126
and also get access to the code shown in my videos
127
and you can subscribe on patreon patreon members also get access
128
to exclusive content from me as well as a private discord community and generous discounts to my courses once I release them.
129
Thank you for watching this video and I'll hopefully see you in the next one.
הורד אפליקציה
כל מה שאתה צריך כדי לדבר בשטף
הגיית AIציון לכל משפט
תרגול IPAשלוט בכל צליל
אוצר מיליםבנה את מאגר המילים שלך
משחק אוצר מיליםלמד תוך כדי משחק
FOR YOU
המלץ על סרטון
C12
42 משפטים
System Design: How to Build an API Rate Limiter
Business EnglishUniversity StudentsWorking Adults
C14
156 משפטים
02 English Vocabulary in Use Advanced Unit 5-8
Business EnglishUniversity StudentsWorking Adults
C24
159 משפטים
What Is Redis Really About? Why Is It So Popular?
Business EnglishUniversity StudentsWorking Adults
C12
51 משפטים
Cloud Models - CompTIA Network+ N10-009 - 1.3
Business EnglishUniversity StudentsWorking Adults
C12
195 משפטים
JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue
Business EnglishUniversity StudentsWorking Adults
C12
11 משפטים
What are Design Patterns? | Introduction to Design Patterns and Principles | Geekific
Business EnglishUniversity StudentsWorking Adults
C13
101 משפטים
How Does a URL Shortener Work?
Business EnglishInterview EnglishUniversity Students
C16
277 משפטים
Distributed Transactions Explained: 2 Phase Commit vs Saga Pattern
Business EnglishUniversity StudentsWorking Adults
C12
18 משפטים
SD91: Reliability vs Scalability
Business EnglishUniversity StudentsWorking Adults
C12
78 משפטים
Why 95% of Android Developers Get Use Cases Wrong
Business EnglishUniversity StudentsWorking Adults
C12
61 משפטים
MCP Just Got a Whole Lot Better
Business EnglishUniversity StudentsWorking Adults
C14
164 משפטים
System Design Mock Interview: Design Facebook Messenger
Business EnglishUniversity StudentsWorking Adults
אוצר מילים והערות הגייה לשיעור הזה
המילים שחוזרות הכי הרבה: request, key, user, idempotency, idempotent. בסרטון הזה יש 129 משפטים ו-1719 מילים לתרגול Shadowing. הדיבור נמשך 7:58. הדובר מדבר מהר, כ-216 מילים בדקה, אז צפו לצלילים מחוברים ומקוצרים. 87% מהמילים נמצאות בין 3,000 המילים הנפוצות ביותר באנגלית; כדאי ללמוד את השאר לפני שמתחילים.
אוצר מילים מרכזי בסרטון הזה
12 המילים המתקדמות ביותר בסרטון, עם ההגייה והמשמעות שלהן:
| מילה | הגייה | משמעות |
|---|---|---|
| hash שם עצם | /ˈhæʃ/ | סוּלָּמִית |
| username שם עצם | שם משתמש | |
| towel שם עצם | /ˈtaʊ̯əl/ | מַגֶּבֶת |
| basket שם עצם | /ˈbæskɪt/ | סַל |
| frustrate פועל | /ˈfɹʌsˌtɹeɪt/ | תִּסְכֵּל |
| cache שם עצם | /kæʃ/ | מִצְבּוֹר, מַחְבּוֹא |
| distribute פועל | /dɪˈstɹɪbjuːt/ | חילק |
| distinguish פועל | /dɪˈstɪŋ.ɡwɪʃ/ | הבחין |
| robust שם תואר | /ɹəʊˈbʌst/ | חָסוֹן, אֵיתָן |
| recipient שם עצם | /ɹəˈsɪp.i.ənt/ | מְקַבֵּל, נמען |
| subscribe פועל | /səbˈskɹaɪb/ | נִמְנָה |
| dictionary שם עצם | /ˈdɪk.ʃəˌnɛ.ɹi/ | מִלּוֹן |
דקדוק בסרטון הזה
המבנים שהדובר משתמש בהם הכי הרבה, עם המילים המדויקות מהסרטון:
| מבנה | בסרטון |
|---|---|
| סביל (Passive voice) be + past participle — הדגש הוא על מה שקורה, לא על מי שעושה את הפעולה | are handled · is considered · is read |
| הווה מושלם (Present perfect) have/has + past participle — פעולה שקרתה בעבר ועדיין יש לה חשיבות או השפעה עכשיו | that's been sent · have stored · has just used |
הגייה ששווה לשים לב אליה
הדובר משתמש ב-28 קיצורים וצורות מקוצרות, כמו we're, doesn't, don't. אמרו אותם בצורה הקצרה, כפי שאתם שומעים אותם.
- הצלילים של “sh” ו-“zh”: hash /ˈhæʃ/, cache /kæʃ/, validation /ˌvæl.əˈdeɪ.ʃən/, distinguish /dɪˈstɪŋ.ɡwɪʃ/, dictionary /ˈdɪk.ʃəˌnɛ.ɹi/
- מילים ארוכות — שימו לב להטעמה: idempotent /ˌaɪ.dəmˈpoʊ.tənt/, validation /ˌvæl.əˈdeɪ.ʃən/, analogy /əˈnæləd͡ʒi/, recipient /ɹəˈsɪp.i.ənt/, dictionary /ˈdɪk.ʃəˌnɛ.ɹi/
צלילים שדוברי עברית מתקשים בהם:
- /æ/ — פתוח יותר מה-“אֶ” העברית, לא כמו “a” ב-“cup”: hash /ˈhæʃ/, basket /ˈbæskɪt/, balancer /ˈbæ.lən.sɚ/, cache /kæʃ/, validation /ˌvæl.əˈdeɪ.ʃən/
- /r/ — הלשון לא נוגעת בשום מקום, לא ה-“ר” הגרונית: retry /riˈtɹaɪ/, discord /ˈdɪskɔɹd/, frustrate /ˈfɹʌsˌtɹeɪt/, restart /ˈɹiːˌstɑɹt/, distribute /dɪˈstɹɪbjuːt/
- עיצור קולי בסוף מילה — /b/, /d/, /g/, /z/, /v/ בלי להפוך אותם לאטומים: discord /ˈdɪskɔɹd/, subscribe /səbˈskɹaɪb/, intend /ɪnˈtɛnd/
איך לתרגל עם הסרטון הזה
- הקשיבו לכל הסרטון פעם אחת בלי לדבר, ורשמו את המילים שאתם לא מכירים.
- התחילו במהירות 0.75×, תרגלו Shadowing משפט אחר משפט, וחזרו למהירות רגילה כשזה מרגיש קל.
- הקליטו את עצמכם והשוו למקור, תוך תשומת לב למילים כמו hash, username, towel.
מהי טכניקת השאדואינג?
שאדואינג היא טכניקת למידת שפה מבוססת מדע שפותחה במקור להכשרת מתורגמנים מקצועיים ופופולרית על ידי הפוליגלוט ד"ר אלכסנדר ארגואלס. השיטה פשוטה אך עוצמתית: אתה מקשיב לאודיו באנגלית ילידית וחוזר עליו בקול רם מיד — כמו צל העוקב אחרי הדובר עם עיכוב של 1–2 שניות בלבד. בניגוד להאזנה פסיבית או תרגילי דקדוק, שאדואינג מכריח את המוח והשרירים בפה לעבד ולשחזר דפוסי דיבור אמיתיים בו זמנית. מחקרים מראים שזה משפר משמעותית את דיוק ההגייה, האינטונציה, הקצב, הדיבור המחובר, הבנת השמיעה ושטף הדיבור — מה שהופך אותו לאחת השיטות היעילות ביותר להכנה לIELTS Speaking ולתקשורת באנגלית בעולם האמיתי.