characteristics and ms

Author: adrien1212

content/architecture_style_distribued/servicebased/apilayer.md

@@ -3,17 +3,35 @@ title = "Api Layer"
 weight = 20
 +++
 
-Nous pouvons ajouter une couche "API Layer" qui va faire office de *reverse proxy* ou de *gateway* entre nos services et l'interface utilisateur.
+{{% notice style="tip" title="Ressources" icon="fa fa-book" %}}
+[6 More Microservices Interview Questions](https://blog.bytebytego.com/p/6-more-microservices-interview-questions)
+{{% /notice %}}
+
+Nous pouvons ajouter une couche "API Layer" qui va faire office de _reverse proxy_ ou de _gateway_ entre nos services et l'interface utilisateur.
 
 ![Alt text](../images/api_layer.png)
 
-## Pourquoi l'utiliser ? 
+## API Gateway
+
+> In a microservices architecture, an API gateway acts as a single entry point for client requests. The API gateway is responsible for request routing, composition, and protocol translation. It also provides additional features like authentication, authorization, caching, and rate limiting.
+
+[api gateway](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F82be2aaf-c292-481e-b8d5-d47cbe9e64d7_1243x1600.png)
+
+## Pourquoi l'utiliser ?
+
+L'avantage de cette pratique c'est qu'elle abstrait notre système derrière un "mur". Les systèmes externes communiquent avec nos services uniquement au travers de la couche API. Cette couche peut par exemple s'assurer que l'utilisateur ait le droit de consulter la ressource (authentification et autorisation).
 
-L'avantage de cette pratique c'est qu'elle abstrait notre système derrière un "mur". Les systèmes externes communiquent avec nos services uniquement au travers de la couche API. Cette couche peut par exemple s'assurer que l'utilisateur ait le droit de consulter la ressource (authentification et autorisation). 
 1. L'utilisateur envoie une requête au service de Commande
-2. La couche API Layer contacte le service d'Authentification 
+2. La couche API Layer contacte le service d'Authentification
 3. Le service d'authentification retourne une réponse autorisant ou non l'accès (e.g. vérifier si l'utilisateur saisi est le bon)
 4. Si l'authentification est réussite avec la couche API Layer transmet à requête au service Commande. Dans le cas contraire, l'API Layer ne contacte pas le service et retourne un code d'erreur au client (e.g. mot de passe incorrect)
 
+> On retrouve un fonctionnement similaire avec la librairie [Spring Cloud Gateway](https://spring.io/blog/2019/08/16/securing-services-with-spring-cloud-gateway)
+
+## Rate Limiter
+
+Il est parfois souhaité de limiter le nombre de de connexion d'un adresse IP, d'un utilisateur sur le serveur. Pour ce faire on utilise un Rate Limiter. Cet outil peut être mis en place sur le serveur ou sur une couche intermédiaire (middleware) entre le client et le serveur
+
+![ratelimiter](../images/ratelimiter.png)
 
-> On retrouve un fonctionnement similaire avec la librairie [Spring Cloud Gateway](https://spring.io/blog/2019/08/16/securing-services-with-spring-cloud-gateway)
+Et si nous avons une architecture microservice possédant une API Gateway qui gère l'authentification, etc ... nous pouvons y rajouter le Rate Limiter

content/architecture_style_distribued/servicebased/images/ratelimiter.png

@@ -4,7 +4,7 @@ weight = 5
 +++
 
 {{% notice style="tip" title="Ressources" icon="fa fa-book" %}}
-[When NOT to write an Abstraction Layer](https://youtu.be/tqqH_Ib_gDc)
+[When NOT to write an Abstraction Layer](https://codeopinion.com/when-not-to-write-an-abstraction-layer/)
 {{% /notice %}}
 
 Comme l'a noté Edsger W. Dijkstra dans son article "The Humble Programmer ", le but de l'abstraction n'est pas d'être vague mais de créer un nouveau niveau sémantique dans lequel on peut être absolument précis.

content/basics/abstraction.md

@@ -0,0 +1,8 @@
++++
+title = "Disponibilité"
+weight = 60
++++
+
+High availability is the ability of a system to be continuously operational for a desirably long period of time. High availability is measured as a percentage, with 100% means a service that has 0 downtime. Most services fall between 99% and 100%.
+
+![availability](../images/availability.png)

content/characteristics/availability.md

@@ -0,0 +1,9 @@
++++
+title = "Faisabilité"
+weight = 50
++++
+
+{{% notice style="tip" title="Ressource" icon="fa fa-icon" %}}
+
+- [Lesson 181 - Feasibility and Questioning Requirements ](https://youtu.be/65qOqfbQV2Y)
+  {{% /notice %}}