Styles architecturaux ETL

Question 1

Quand devons-nous retourner un code 20X?

Answer 1

Lorsqu’il n’y a pas d’erreur et que le retour est bon.

Question 2

Que signifie le code 200 et quand devons-nous le retourner?

Answer 2

Il signifie Ok et lorsqu’il y a un body ou l’action s’est bien passée.

Question 3

Que signifie le code 201 et quand devons-nous le retourner?

Answer 3

Il signifie Created et lorsqu’un nouvel objet est créé.

Question 4

Que signifie le code 204 et quand devons-nous le retourner?

Answer 4

Il signifie No Content et lorsqu’il n’y a pas de body.

Question 5

Que signifie le code 202 et quand devons-nous le retourner?

Answer 5

Il signifie Accepted et lorsqu’il y a un traitement async.

Question 6

Quand devons-nous retourner un code 30X?

Answer 6

Lorsqu’il y a navigation (Location header)

Question 7

Que signifie le code 301 et quand devons-nous le retourner?

Answer 7

Il signifie Moved Permanently et lorsque l’URL de la ressource a changé de façon permanente et le nouvel URL est retourné.

Question 8

Que signifie le code 302?

Answer 8

Il signifie Found (avec redirect)

Question 9

Quand devons-nous retourner un code 40X?

Answer 9

Lorsqu’il s’agit d’une erreur du côté client.

Question 10

Que signifie le code 400 et quand devons-nous le retourner?

Answer 10

Il signifie Bad Request et il doit être retourné lorsque la requête de l’utilisateur est mauvaise ou mal formulée.

Question 11

Que signifie le code 401 et quand devons-nous le retourner?

Answer 11

Il signifie Unauthorized et il doit être retourné lorsque l’utilisateur n’est pas authentifié d’un point de vue authentification.

Question 12

Que signifie le code 403 et quand devons-nous le retourner?

Answer 12

Il signifie Forbidden et il doit être retourné lorsque l’utilisateur est authentifié, mais ne peut pas accéder à la ressource d’un point de vue permission.

Question 13

Que signifie le code 404 et quand devons-nous le retourner?

Answer 13

Il signifie Not Found et il doit être retourné lorsque la ressource n’est pas trouvée ou on veut la cachée à l’utilisateur.

Question 14

Que signifie le code 405 et quand devons-nous le retourner?

Answer 14

Il signifie Method not allowed et il doit être retourné lorsque la méthode HTTP n’est pas supporté (Ex: ne permet pas le DELETE sur une ressource).

Question 15

Quand devons-nous retourner un code 50X?

Answer 15

Lorsqu’il s’agit d’une erreur du côté serveur.

Question 16

Que signifie le code 500 et quand devons-nous le retourner?

Answer 16

Il signifie Internal Server et il doit être retourné lorsque le serveur est dans une situation qu’il ne sait pas comment gérer.

Question 17

Que signifie le code 501 et quand devons-nous le retourner?

Answer 17

Il signifie Not Implemented et il doit être retourné lorsque le serveur ne supporte pas la méthode.

Question 18

Que signifie le code 502?

Answer 18

Il signifie Bad Gateway

Question 19

Que signifie le code 503 et quand devons-nous le retourner?

Answer 19

Il signifie Unavailable et il doit être retourné lorsque le serveur ne peut pas être atteint.

Question 20

Quelles sont les méthodes HTTP et à quoi servent-elles?

Answer 20

GET: Fetch de l’info
POST: Ajout ou Action
DELETE: Suppression
OPTION: Savoir les méthodes disponibles, les paths et la documentation
PUT: Ajouter un élément inexistant

Question 21

Que signifie REST et que fait un REST API?

Answer 21

REST: Representationnal State Transfer

Sert d’interface standardisée et manipule des ressources et des états.

Question 22

Qu’est-ce qu’un path et quelles sont ses parties?

Answer 22

Il s’agit d’un identificateur de ressource.

Base: Présente le service, le domaine et le port
Collections et sous-collections: Ex: Users
ID: Ressource unique

Question 23

À quoi sert une custom method?

Answer 23

Elle permet de faire une action sur un path précis qui n’est pas une ressource. Ex: /users/JeBag23/tickets/Bob124:transfer

Question 24

À quoi servent des query params?

Answer 24

Il servent à ajouter des filtres

Question 25

Expliquez le style architectural Extract-Transform-Load.

Answer 25

L’intention derrière le style ETL (extraction, transformation et chargement) est de faire l’interconnection entre plusieurs styles de données ensembles. On prend les données d’un système, souvent patrimonial, pour l’envoyer dans un nouveau système. On agit alors entant qu’intermédiaire qui va adapter les données pour que cela fonctionne entre les deux côtés. L’objectif d’une application de style ETL est d’éviter que deux systèmes indépendants se connaissent. Ainsi ce style veut juste réduire le couplage dans tout le système.

Question 26

Quelles sont les composantes d’un système ETL?

Answer 26

Le processus d’une application ETL est divisé en 3 partie, L’extraction des données que l’on sort d’un système, la transformation dans le bon format pour ensuite faire l’envoi dans le prochain système.

L’extraction de données peut être fait selon 2 types de mécanismes, comme pour le patron observeur (pull ou push) . Cependant, c’est le vieux système qui doit informer que le processus doit se déclencher ou par une cron.

Dans le cas de la transformation, c’est l’étape qui permet de faire la manipulation des données d’un système vers un autre. C’est l’étape du processus qui contient aussi les manipulations reliées à la logique d’affaire particulière d’un système. On peut voir cette étape comme la raison d’être initiale de l’application d’ETL.

L’étape de load est responsable de la communication avec le système destinataire de toutes les transformations. Celui-ci ne contient que très peu de logique autre que la gestion d’erreur qui pourrait subvenir dans le système destinataire.

Question 27

Quel est le cas d’utilisation d’un système ETL?

Answer 27

Le style ETL est souvent utilisé pour permettre de la communication entre des contextes d’affaires différents où ce ne sont pas les mêmes parties prenantes (équipes) qui sont responsables des 2 systèmes. Ainsi, on va élire une des deux parties comme responsable de l’ETL entre les deux. Le plus souvent c’est le système destinataire qui devient le responsable.

Question 28

Expliquez le style architectural Pipe & Filter.

Answer 28

Le style pipe & filter est utile pour faire des transformations par étape sur des champs de données. Popularisé avec la manipulation d’image, l’intention est de passer à travers plusieurs filtres de modifications qui s’enchaînent. Comme chacune des étapes de transformation des données est divisée entre les filtres, cela permet une meilleure compréhension et testabilité des manipulations. On peut aussi enlever ou rajouter des étapes en fonction du contexte.

Question 29

Quelles sont les composantes du Pipe & Filter?

Answer 29

Il y a deux composantes clés dans le style pipe & filter, les pipes et les filtres.

Les filtres représentent la logique de traitement des données. Chaque filtre doit avoir une seule responsabilité de traitement dans la chaîne. On peut avoir plusieurs filtres qui s’enchaînent entre eux.

Les pipes servent à connecter les filtres entre eux. Ils adaptent les données

Question 30

Quels sont les cas d’utilisation du Pipe & Filter?

Answer 30

Ce style est utilisé dans toutes manipulations de données peu importe le format. Comme chaque étape est indépendante, ce style nous permet aussi d’utiliser le parallélisme dans l’application pour réduire la charge CPU ou même augmenter la vitesse de traitement. On utilise souvent ce style dans le milieu de la vision numérique (nuage de point/image/post-processing sur votre téléphone). Avec l’arrivée du big-data, le pipe & filter a été aussi vu avec le terme MapReduce, pour permettre de modifier les données avant l’ingestion dans le système d’apprentissage machine.

Question 31

Expliquez le Map & Reduce?

Answer 31

Il s’agit d’un Pipe & Filter qui branch out en diverses branches de filters et qui recombine en un seul output.

Question 32

Expliquez le Data Pipeline.

Answer 32

Version plus spécifique du Pipe & filter avec une différence majeure, il n’y a pas d’interchangeabilité des filtres. En fait l’intention derrière le data pipeline est de créer une structure plus simple de manipulation de données où les données vont passer toujours à travers les mêmes étapes de transformation. Ainsi, cela simplifie la nécessité d’avoir des pipes intelligentes. Il y a plusieurs façon de faire ce genre de pipeline de données.

Question 33

Quels sont les cas d’utilisation du Data Pipeline

Answer 33

• Persister plusieurs fois dans des systèmes différents le même jeu de données
• Appliquer des transformations sur l’ensemble des données (logique d’affaire)
• Effectuer diverses transactions sur les données (processus par étape)

Question 34

Expliquez le style architectural Proxy/Gateway.

Answer 34

Style plus simple dans la manipulation de données, le gateway est la version style du patron Adapter. Son intention est d’interfacer l’intéraction avec un autre système ou contexte pour toute une application. Avec le gateway, on centralise la logique de communication à une seule place dans le système. Cela permet alors d’avoir un seul contrat d’utilisation et si le système en amont change, il n’y aura que le gateway à changer. Nous avons ainsi un mécanisme qui nous permet de mocker ou de faire un objet faux avec le système externe.

Question 35

Quelles sont les composantes du Proxy/Gateway?

Answer 35

Le gateway est le seul élément nécessaire à avoir. Il offre alors un contrat (abstraction) permettant de mocker ou d’avoir plusieurs implémentations différentes du système externe. Pour faire fonctionner le gateway, nous allons utiliser deux patrons, le proxy et l’adapter.

Question 36

Quels sont les cas d’utilisation du Proxy/Gateway?

Answer 36

Nous allons voir l’utilisation de Gateway pour faire la connexion vers un système. Il se peut que cela soit utilisé même directement dans le même monolithe de l’application. Cependant, ce que l’on voit surtout c’est l’utilisation pour du gateway vers le monde extérieur (réseau, firmware, SO). Nous voyons souvent le gateway ayant deux types de langages (termes d’affaires) de DDD à l’intérieur de l’implémentation. C’est normal, il nous permet de nous protéger d’une contamination des contextes d’affaire externes à notre application.