Et bienvenue dans la vidéo d'aujourd'hui, nous discuterons de Mladic.
Désormais, une vue d'ensemble de haut niveau vous permet essentiellement d'exécuter votre fonction Lamela pour personnaliser le contenu que votre ami
du cloud pourrait fournir à vos utilisateurs finaux.
Maintenant, fondamentalement, cela peut être facilement expliqué dans une vue schématique, car si nous sautons directement dans ces points
théoriques, cela ne fera que semer la confusion.
Il s'agit donc d'une représentation schématique.
Disons donc qu'il s'agit d'un utilisateur.
Cela peut être un navigateur.
Ciarlante et vous avez un front nuageux ici.
C'est un ami du cloud.
Mon Dieu.
Et c'est l'origine.
Maintenant, cela peut être un marché de rue ou tout autre site Web que vous exécutez dans les coulisses.
Vous savez ce que lamda at the Edge vous permet de faire, c'est qu'il vous permet d'exécuter la fonction lamina à quatre points
principaux.
Le premier point majeur est avant que la demande n'atteigne le cloud.
Mon Dieu, le point d'achoppement se situe après que la requête a raté le cache du cloud et avant qu'elle n'atteigne
l'origine.
C'est donc le deuxième point où vous pouvez exécuter votre fonction lamda.
Le troisième point est dès que vous récupérez les données de votre origine, c'est la troisième partie.
Et la quatrième partie est après que les données aient traversé le cloud print cash et avant qu'elles ne reviennent
à l'utilisateur, vous avez encore un point.
Il y a donc quatre pointeurs où vous pouvez exécuter votre fonction lambda.
Maintenant, ces pointeurs sont définis par un nom.
Le premier est défini à la demande du téléspectateur.
Le second est défini par la demande d'origine.
Ensuite, vous avez la réponse originale.
Et quatrièmement, la réponse du téléspectateur.
Non, en raison de la capacité d'un dabblers à exécuter votre fonction lambda dans ces quatre pointeurs, cela
permet vraiment beaucoup de possibilités et de capacités.
Revenons donc à notre première diapositive et comprenons chacun de ces points.
Revenons maintenant au deuxième point de la première diapositive, il indique que vous pouvez exécuter votre fonction lambda pour
modifier la demande d'impression cloud et les réponses aux points suivants.
Maintenant, nous avons déjà discuté du fait qu'il y avait quatre pointeurs.
Maintenant, ce sont les quatre pointeurs que vous devez retenir par rapport à la demande du téléspectateur.
La deuxième est la réponse originale de Questers.
Et pour cette réponse de téléspectateur, une demande de téléspectateur n'est plus rien, mais après que Cloud Print a reçu une demande
d'un téléspectateur.
C'est donc l'objet de la demande du téléspectateur.
La deuxième est la demande d'origine, qui indique essentiellement qu'il s'agit de l'emplacement avant que l'impression dans le cloud
ne transmette, la demande à l'origine.
Donc avant.
Vous avez donc un nuage de Casoria maintenant avant de transmettre la requête à l'origine, il y a un pointeur plus
boisé.
Donc, à ce stade, c'est ce qu'on appelle la demande initiale.
Maintenant, le troisième est la réponse d'origine, qui est essentiellement après que l'impression en nuage a reçu la
réponse de l'origine.
C'est donc la troisième place de celui-ci.
Et la quatrième place est la réponse du téléspectateur, qui indique essentiellement qu'avant que le front du nuage ne
transmette la réponse au téléspectateur.
Voici donc l'emplacement.
Donc avant que la demande ne soit renvoyée à l'agent utilisateur.
C'est la quatrième place.
Maintenant, rappelez-vous que cette représentation que vous voyez ici, c'est essentiellement l'argent du front du cloud.
Faisons donc une chose.
Comprenons chacun de ces événements de manière détaillée.
Désormais, la demande du téléspectateur est essentiellement exécutée à chaque demande avant que le cloud from cash ne soit vérifié.
C'est quelque chose que nous avons déjà vu qu'un téléspectateur demande, donc toute fonction lambda dans laquelle vous la mettez.
Ce sont donc les quatre emplacements où vous pouvez placer votre fonction lambda et cette fonction
lambda s'exécutera à chacun de ces emplacements chaque fois qu'une demande arrivera.
Ainsi, toute fonction lambda que vous placez à cet emplacement spécifique sera exécutée à chaque fois avant que l'ami du cloud
n'encaisse le chèque.
Maintenant, il y a beaucoup d'avantages à exécuter une fonction à la demande du téléspectateur.
L'un des avantages est de modifier l'Eurail.
Vous pouvez faire un cookie, vous pouvez faire une requête, une modification liée à la chaîne.
Et l'un des plus célèbres d'entre eux est également facile à expliquer est d'effectuer des contrôles d'authentification et d'autorisation.
Cela peut donc être compris avec le diagramme suivant où vous avez un agent utilisateur ici et vous avez un
front cloud.
Ainsi, dès que le cloud reçoit la demande, la première chose avant que le cloud front cash soit git est
la demande du téléspectateur.
Même ainsi, la demande du téléspectateur peut même essentiellement examiner quelle est sa demande que l'agent utilisateur a
envoyée, si la demande contient le mot de passe approprié, qui est requis pour ouvrir le site Web.
Si la demande contient le mot de passe approprié pour ouvrir le site Web, alors la demande
sera envoyée à l'OCC, puis elle sera envoyée à l'origine.
Si la demande n'a pas de mot de passe, votre demande de téléspectateur peut même renvoyer l'EDP pour 03 à
l'agent utilisateur.
Et cette authentification par mot de passe est l'une des fonctions que beaucoup d'organisation mettent au niveau de la demande
du téléspectateur lui-même.
Parce que si disons qu'un agent utilisateur demande un fichier spécifique et que ce fichier est maintenant Kastoria, il
est possible que la demande n'aille pas à l'original.
La demande serait répondue à partir du cache lui-même.
Il est donc très important spécifiquement si vous avez une sorte d'authentification par mot de passe,
vous cochez votre mot de passe lié à l'authentification dans la demande de visionneuse afin que dès que la
demande est arrivée au niveau de menace cloud, vous exécutez votre fonction lambda ici et que lambda La fonction peut déterminer si la
demande doit être autorisée ou non.
Maintenant, la deuxième partie est la demande originale.
Désormais, la demande d'origine est généralement un emplacement de votre fonction lambda, qui s'exécuterait chaque fois qu'un
cache est manqué ou avant qu'une demande ne soit transmise à l'origine.
Maintenant, fondamentalement, il y a beaucoup de choses que vous pouvez faire à ce stade, comme secteur dynamiquement l'origine
en fonction des en-têtes de requête.
Alors comprenons cela.
Mais c'est donc le schéma de la demande originale.
Si vous notez, je dois recommencer ici pour qu'il soit facile de savoir de quelle fonction ou de quel
endroit nous discutons.
Nous y sommes donc, en supposant que la demande a d'abord été envoyée à notre ami, puis vous avez la demande de la visionneuse,
puis elle est allée dans le cache cloud frenk.
Il y a une cache, mademoiselle.
Rappelez-vous une partie importante pour vous souvenir de vous.
Si un cache atteint cela, Cloud Front peut fournir les données directement à l'utilisateur, puis la requête et
la réponse d'origine peuvent ne pas s'exécuter.
Il est donc important de se souvenir.
Ainsi, chaque fois qu'un échec de cache se produit, les données passent à la demande d'origine audio maintenant la demande d'origine que
vous pouvez contrôler de nombreux paramètres.
Nous sommes l'un des paramètres et l'un des cas d'utilisation que vous pouvez travailler à ce niveau est de définir dynamiquement
l'origine en fonction des en-têtes de requête.
Il peut donc arriver qu'il y ait plusieurs origines.
Disons que vous avez un S3, mais avez-vous un exemple facile ?
Non.
À partir de cette fonction lambda, vous pouvez savoir si la demande doit aller au compartiment S3 ou au compartiment facile à instantané
en fonction des en-têtes de demande.
Vous pouvez donc avoir tous ces contrôles au niveau de la demande d'origine elle-même.
Désormais, vous pouvez également renvoyer directement les données de la demande d'origine.
Ce n'est pas nécessairement que cela atteindrait le point final.
Donc, selon la logique que vous souhaitez définir l'audio.
Donc, la prochaine partie dont nous devons discuter est la réponse d'origine.
Désormais, la réponse d'origine est essentiellement exécutée en cas d'échec du cache après la réception d'une réponse de l'origine.
Donc, si nous examinons leur diagramme associé à ou est en réponse.
La réponse d'Aurélien vient donc après l'origine et la date de son origine renvoie.
Il passe à l'audio de l'étage de réponse d'origine.
Maintenant, encore une fois, cette étape est très importante et vous pourrez le faire à votre guise.
Cas d'utilisation de cette réponse, la première étape consiste à modifier les en-têtes de réponse et à intercepter
et remplacer diverses erreurs d'investigation et d'incendie à partir de l'origine.
Alors disons que vous avez l'origine.
Cela peut être facile à instantané et d'une manière ou d'une autre, votre application est en panne et ne fonctionne pas du tout.
Et ce qu'il a donné, il a renvoyé une erreur de cinq cents.
Maintenant, à la réponse d'origine, vous pouvez avoir une logique selon laquelle chaque fois que vous obtenez une
réponse 500 de l'origine, elle peut soit remplacer cette réponse par une réponse spécifique.
Vous pouvez voir un peu dire que le site Web peut être en maintenance ou que la réponse d'origine peut se connecter ou
il peut dire qu'il n'y a pas de redirection résiduelle vers un retour ou vers l'origine de sauvegarde pour que la demande se produise.
C'est donc aussi une étape critique.
Maintenant, la dernière étape est la réponse du téléspectateur.
La réponse de la visionneuse est essentiellement la fonction qui est exécutée sur toutes les réponses reçues
de l'origine ou du cache.
Maintenant, encore une fois, c'est un état très important car il peut arriver qu'après la demande du téléspectateur, la demande puisse atteindre le
nuage à cause de l'argent et du nuage à cause du gaz.
Il a déclaré que les données seraient renvoyées à l'agent utilisateur.
Donc, ce bon site pourrait ne pas être exécuté du tout.
Donc, si vous voulez que certaines fonctions se produisent pour toutes les réponses qui sont renvoyées à l'agent utilisateur, il
est extrêmement important de placer votre fonction à la limite de réponse du téléspectateur.
Maintenant, l'un des cas d'utilisation, pour lequel de nombreuses organisations utilisent la réponse de la visionneuse, consiste à modifier
l'en-tête de réponse avant la mise en cache de la réponse.
Maintenant, ce qui se passe essentiellement à partir de la réponse d'origine, si vous avez certains en-têtes, cela pourrait être
gazé au niveau du nuage Frankish.
Mais si vous le placez au niveau de la réponse du spectateur, vous n'aurez pas du tout la mise en cache.
Il ira directement au niveau de l'agent utilisateur.
Voici donc la vue d'ensemble de haut niveau sur LAMDA chez D. H.
J'espère que cette vidéo vous a été instructive et j'ai hâte de voir la prochaine vidéo.