Forem: FAMCHON Baptiste

Let's talk: SOLID Principles 🇬🇧

FAMCHON Baptiste — Thu, 19 Sep 2024 14:29:10 +0000

Why do we need principles ?

Software would be a pain without clean code rules. But getting well written bricks of code is not enough: you can make a mess if those bricks are not well assembled.

That's were architecture principles comes in.

S.O.L.I.D. rules stands for:

SRP: Single Responsibility Principle
OCP: Open Closed Principle
LSP: Liskov Substitution Principle
ISP: Interface Segregation Principle
DIP: Dependency Inversion Principle

Single Responsibility Principle

| A module should be responsible to one, and only one, actor.

Let's understand this principle with an example.

class Employee {
  calculatePay()
  reportHours()
}

A product got two methods to calculate a pay and report working hours of an employee.

Calculate pay is used by an Actor responsible of financial stuff, and hours reporting by another Actor, a manager for example.

We broke the Single Responsibility Principle.

Furthermore, imagine that these methods have some lines of code in common because we care about code reusability.

A change in the common lines of code would satisfy the result of a method but can make the second fail.

Open Closed Principle

| Code entities should be open to extensions and closed to modifications

class Player {
  printRole() {
    switch(this.role) {
        case "elf":
            console.log("Player is elf !");
            break;
        case "warrior": 
            console.log("Player is warrior !");
            break;
        case "..."
    }
  }
}

What happens if you need to add another Player role ?

You will have to modify the existing function and then violate the principle.

To be compliant with the principle, you will need to use abstractions.

class Player {
    constructor(private readonly role: PlayerRole) {}
    printRole() {
        console.log("Player is ", this.role.getRole());
    }
}

interface PlayerRole {
    getRole(): string
}

class RoleElf implements PlayerRole {
    getRole() {
        return 'elf';
    }
}

class RoleWarrior implements PlayerRole {
    getRole() {
        return 'warrior';
    }
}

const player = new Player(new RoleWarrior());
player.printRole();

This way, if you want to add a new Role, you will not have to modify existing code, but only implement PlayerRole.

Liskov Substitution Principle

| When extending a class, remember that you should be able to pass objects of the subclass in place of objects of the parent class without breaking the client code.

Imagine this Player class, we define a property and a method to make player flying...

class Player {
    items: string[];
    flying: boolean;

    fly(): {
        this.flying = true;
    }
}

class Warrior extends Player {
    fly(): void {
        throw new Error("Warriors can't fly, only Elves can !!!!");
    }
}

But we break the Liskov principle as defining a subclass of Player, Warrior, may break the code.

Let's see how we can be compliant easily.

class Player {
    items: string[];
}

class Elf extends Player {
    items: string[];
    flying: boolean;

    fly(): void {
        this.flying = true;
    }
}

Interface Segregation Principle

| No client should be forced to depend on methods it does not use.

Let's start by an example which breaks ISP.

interface CharacterActions {
    throwMagicPower(): number;
    speak(): string;
}
class PlayableCharacter implements CharacterActions {
    throwMagicPower(): number {
        return 100;
    }
    speak(): string {
        return "I am a playable character";
    }
}
class NonPlayableCharacter implements CharacterActions {
    throwMagicPower(): number {
        // not applicable to NPC...
        return 0;
    }
    speak(): string {
        return "I am a non playable character";
    }
}

This breaks ISP because NonPlayableCharacter is forced to depend of method throwMagicPower it doesn't use.

To be compliant, we can split CharacterActions into smaller interfaces and only implement when needed.

interface Speaker {
    speak(): string;
}

interface Magician {
    throwMagicPower(): Damage;
}

class PlayableCharacter implements Magician, Speaker {
    throwMagicPower(): Damage {
        return 100;
    }
    speak(): string {
        return "I am a playable character";
    }
}
class NonPlayableCharacter implements Speaker {
    speak(): string {
        return "I am a non playable character";
    }
}

Dependency Inversion Principle

| Depend upon abstractions, not concretions.

Dependency Inversion proposes that instead of depending on concrete class implementations, we should depend on abstractions.

Even more important when it concerns business logic !

Let's see what would be a bad code example

class NotifyUserUseCase {
    constructor(private readonly emailSender = new EmailSender()) {}
    execute({order, buyer}) {
        const text = `An order of ${order.price}${order.currency} have been created with your account`;
        this.emailNotificationSender.send({
            text,
            to: buyer
        })
    }
}

Here, our notify use-case is directly dependent of EmailSender.

First, it would be hard to unit test our use-case because we cannot easily fake our Notifier.

Secondly, we're coupled with an implementation detail: what if our product owner want to change from mail to SMS ?

Here is a proper version implementing DIP

interface NotificationProvider {
    send(): void;
}

class EmailNotificationProvider implements NotificationProvider {
    send(): {
        // stuff to send email
    }
}

class SMSNotificationProvider implements NotificationProvider {
    send(): {
        // stuff to send SMS
    }
}

class FakeNotificationProvider implements NotificationProvider {
    send(): {}
}

class NotifyUserUseCase {
    constructor(private readonly notificationProvider: NotificationProvider) {}
    execute({order, buyer}) {
        const text = `An order of ${order.price}${order.currency} have been created with your account`;
        // business logic don't care about notification being a SMS or Mail
        this.notificationProvider.send({
            text,
            to: buyer
        })
    }
}

I'm Baptiste FAMCHON, Tech Lead specialized in frontend at Claranet.
I write regularly on dev.to and LinkedIn about web and software crafting topics.

At Claranet, we can also help you think about IT modernization, cloud infrastructure, security and web development.

Don't hesitate to contact us! 🚀

Parlons IA : Stratégie RAG

FAMCHON Baptiste — Thu, 25 Jul 2024 07:26:25 +0000

Nous ne pouvons pas aborder le sujet de l'intelligence artificielle générative sans parler des stratégies RAG.

Dans un monde où les données explosent, la recherche d'informations pertinentes devient de plus en plus complexe. Les technologies de l'IA ont ouvert de nouvelles perspectives pour optimiser la recherche et la génération de réponses.

Parmi ces innovations, les stratégies RAG se démarquent par leur efficacité et leur précision !

Partons explorer les fondements, les avantages et les applications de ces stratégies RAG.

RAG: késako ?

Retrieval Augmented Generation, pour génération augmentée de récupération, est une stratégie de surcharge de l'IA générative.

Au lieu de se baser uniquement sur le contenu de la base d'entraînement du modèle, qui est constituée de sources diverses comme des articles sur le web, wikipédia, des livres, des papiers scientifiques... La stratégie RAG va induire, au préalable, une recherche depuis une base de données externe afin de fournir plus de contexte pour la génération de réponses par le LLM.

Ce qui a pour avantage de réduire les hallucinations.

Se pose alors les questions sur le choix des données sources, sur la manière dont on va interroger ces données (étape 2), sur le choix des modèles...

Chaque question à son importance, creusons ces points et tentons d'y voir plus clair !

Choix des données sources

Le succès d'une stratégie RAG va grandement dépendre des documents utilisés pour récupérer les informations.
Il faudra surtout chercher des sources :

Pertinentes et liées à votre domaine d'application.
Si vous souhaitez faciliter la recherche dans vos documents d'entreprise, certains dossiers de votre Drive sont sûrement plus intéressants que d'autres.
Fiable et d'actualité.
On s'en doute, on ne peut pas s'attendre à avoir des réponses cohérentes avec des sources dépassées. D'où la nécessité de cibler les bonnes sources, et les bons documents, en accordant peut être + de poids aux documents les + récents ?
Suffisamment diversifiée, mais sans diluer l'information.
Afin de convenir à vos utilisateurs, il pourrait être utile de travailler avec de la variété: ce qui intéresse les commerciaux intéresse sûrement moins les équipes produits...

Posez-vous ces questions car toute réponse est contextuelle.

La vectorisation comme principal allié

Dans les stratégies RAG, la vectorisation des sources est souvent utilisées.

Mais d'abord, qu'est-ce qu'une donnée vectorisée et qu'apporte-t-elle ?

On connaît très bien les données représentées sous forme de table, comme c'est le cas dans un SGBD traditionnel.

Cependant, on imagine qu'il va être difficile d'aller rechercher les films similaires dans cette base de données, il faudrait user de requêtes complexes, basées sur plusieurs attributs.

Dans ce contexte de recherche de proximité, les bases de données vectorielles excellent.
Elles sont optimisées:

Pour l'indexation, à travers des stratégies comme Locality Sensitive Hasing (LSH), Inverted File (IVF) ou encore Hierarchical Navigable Small Worlds (HNSW)...
Pour la récupération, à travers des calculs de proximité comme Euclidean Distance, Dot Product Similarity ou encore Cosine Similarity.

Vespa, Pinecone, Qdrant, Chroma, toutes vont avoir leurs particularités et leurs spécialités.

Si l'on devait imaginer nos films précédents dans une représentation vectorielle, on pourrait les voir comme ceci.

Choix des modèles de Chat & Embeddings

Nous avons parlé de vecteurs précédemment, mais comment transformer nos données sous cette forme ?

C'est là qu'interviennent les modèles d'embedding !

Les embeddings vont jouer un rôle important car ils vont vous permettre de passer d'une représentation textuelle en une représentation vectorielle.

Un modèle d'embedding connu, text-embedding-ada-002 par OpenAI par exemple.

Chaque modèle va avoir ses spécificités, liées notamment:

aux corpus, les données utilisées pour l'entraînement
et à la dimensionnalité, le nombre de valeur numérique qui composera un vecteur

Comment choisir un bon modèle d'embedding ?

Là encore, toute réponse est contextuelle !

Imaginez que tous vos documents sont en français, et que vous utilisez un modèle entraîné sur des données en anglais ?
Les résultats ne pourront pas être pertinent, les relations entre les mots vont avoir du mal à être détectées par les algorithmes.

Dans ce cas, il faudrait peut-être s'orienter vers un modèle multilingue comme intfloat/multilingual-e5-large.

Concernant les modèles de Chat (pensez à gpt-4 par exemple), on ne va pas forcément chercher ceux les plus complets, multi-modaux, entraînés sur des corpus énormes, mais plutôt chercher un modèle peu coûteux et fiable dans sa capacité à générer des phrases fluides adaptées au contexte.

Je pense notamment à un GPT-3.5-Turbo ou un Mistral Small qui feraient parfaitement l'affaire.

L'importance du Chunking

Nous avons parlé de l'importance du choix des sources de données et de leur vectorisation à travers des modèles d'embeddings.

Il nous reste à évoquer le chunking.

Le Chunking est une technique qui sera utilisée pour diviser la données en morceaux (= chunks) plus petits, facilitant l'indexation et la recherche.

Imaginons une étude scientifique, rédigée sur plusieurs centaines de pages. Il serait inconcevable de venir l'indexer entièrement en un seul gros bloc !
Dans notre recherche de proximité, si l'algorithme arrive à nous retourner cette donnée, on se retrouverait avec une information diluée et un contexte énorme à passer au modèle de Chat. Une démarche pas vraiment optimisée.

Le chunking dans ce cas, serait le découpage de cette étude en paragraphe, par exemple.
L'information pertinente serait plus facilement identifiée car on travaillerai avec des segments plus petits.

Toute la difficulté sera d'identifier la bonne taille pour nos chunks, dépendante aussi de la donnée traitée.
Une segmentation trop fine diminuera le contexte, une segmentation trop importante et on retombe dans l'exemple précédent.

Un titre d'une étude pourrait être un bon délimiteur de chunk
Un paragraphe dans une page Confluence aussi
Ou encore, une ligne d'un CSV, une slide d'un diaporama...

Concrétisations business

Selon moi, quelques cas d'usage sortent du lot.

La recherche d'information en entreprise.
Plus votre entreprise grandit, plus votre connaissance augmente, et plus ça devient un calvaire pour les équipes de trouver l'information.
Le RAG répond parfaitement à ce besoin en venant cibler les sources d'informations les + pertinentes.
L'assistance client.
Qu'on se le dise, le chatbot classique n'apporte pas une vraie satisfaction dans l'assistance qu'il apporte, souvent très limitée.
À la place, imaginez qu'un utilisateur ait accès à une base d'assistance, une FÀQ géante qu'il pourrait interroger en language naturel.
Secteur de la recherche ou médical.
Les professionnels de santé pourraient utiliser une stratégie RAG pour se tenir à jour sur les dernières études et ainsi améliorer les protocoles de soins des patients.
Un cas d'usage applicable à d'autres professions, comme le droit ou la recherche de manière générale.

Chez Claranet, nous travaillons principalement avec plusieurs solutions pour proposer la recherche documentaire: Azure AI Search, AWS Bedrock & DAnswer, une solution open-source sur laquelle nous contribuons.

Ressources

Je suis Baptiste FAMCHON, Tech Lead spécialisé frontend chez Claranet.
J'écris régulièrement sur dev.to et LinkedIn à propos de sujets autour du web et de l'artisanat logiciel.

Chez Claranet, nous vous accompagnons aussi dans vos réflexions de modernisation SI, d'infrastructure cloud, de sécurité et de développement web.

N'hésitez pas à nous contacter ! 🚀

Parlons pattern: BFF

FAMCHON Baptiste — Wed, 19 Jun 2024 15:23:16 +0000

Aujourd'hui, nous allons parler pattern.
Il se présente comme le meilleur ami des développeurs (BFF, you got it ? 😶), mais on l'utilise souvent sans le connaître.
Penchons nous sur le Backend For Frontend !

Pourquoi ce pattern ?

En développant des applications web, on est souvent confronté à une volonté de récupération de données, majoritairement provenant d'API...
Et en travaillant dans un contexte MACH (Micro Services, API-first, Cloud Native, Headless), où ces données vont provenir de plusieurs sources, c'est souvent l'application Frontend qui va se charger de leur récupération et manipulation.

Tant que l'application reste simple, on pourrait se contenter de ce fonctionnement.

Mais on imagine bien que plus l'application gagne en cas d'usage, plus on va se retrouver avec beaucoup de logique de transformation, d’agrégation...
Et ce, dans chaque application Frontend du périmètre: mobile, web, embarquée...

Dans notre exemple précédent, on imagine de multiples API, mais on pourrait aussi imaginer un Backend unique !

Et dans ce cas, la donnée exposée aux Frontend se verra de plus en plus générique, de moins en moins spécialisée aux usages des Frontend... Et on se retrouvera avec les même problématiques: transformation, aggregation etc.

Est-ce vraiment ce que l'équipe souhaite ?

Dans le cas où la réponse serait négative, continuons la (re)découverte de ce pattern !

Qu'est ce qu'un BFF ?

Un Backend For Frontend, c'est donc une couche qui se place entre le Frontend et les API.
Au lieu de laisser le Frontend faire les appels aux différentes API et agréger, on se contente de faire un appel au BFF qui va lui faire le travail.
On déplace le travail côté serveur en évitant de surcharger le navigateur avec des tâches à faible valeur ajoutée.

Le BFF va finalement retourner une réponse prête à être consommée par les Frontend du même type.
Par exemple, il y a de fortes chances pour que la donnée sur iOS et Android soit utilisée de la même manière, un BFF pour ces deux applications pourrait suffire.

Comment l'implémenter ?

Partons d'un existant où tous vos Frontend appelleraient un ensemble d'API. Chaque Frontend va porter sa logique de manipulation des données.

Nous allons introduire une couche supplémentaire côté mobile et côté web, notre BFF.

Au passage, nous profiterons ainsi de facilités d'évolution pour nos applications mobiles, car moins soumises au redéploiement sur les stores.

Quelles différences avec l'API Gateway ?

On pourrait se poser la question car les deux solutions ont le même esprit: une couche passerelle entre des applications consommatrices de données, et des services qui la propose.

Les grandes différences se situent :

Sur le périmètre adressé

Là où l'API Gateway va servir de point unique, on l'a vu, le BFF va être dédié pour un seul type de client: mobile, web, console de jeu... Car chaque type de client peut avoir sa spécificité en terme de présentation de donnée, de gestion d'erreurs, d'authentification etc

Sur les responsabilités

Techniquement, vous allez pouvoir gérer du cache, du rate limiting, de la monétisation côté serveur... Mais ce n'est vraiment pas le but du BFF !
Il faudrait plutôt privilégier des solutions d'API Gateway / Management comme Gravitee.
Et donc vous l'avez compris, on peut tout à fait combiner BFF et API Gateway, ils n'ont pas les mêmes usages.

Ça pourrait mériter un article dédié !

Comment se décider ?

Voyons quelques avantages et inconvénients à l'usage du pattern BFF.

+ Résilient aux changements d'API
+ Gestion des erreurs provenant des API, retransmission dans un format intéressant pour les Frontend
+ Une donnée présentée sur mesure
- Nécessité d'avoir + de compétences fullstack dans l'équipe
- Maintient d'une couche supplémentaire

La question intéressante à se poser pour savoir si l'implémentation d'un BFF est nécessaire, serait:

Est-ce que j'ai besoin de proposer une expérience différentes aux utilisateurs selon le type d'application ?

Prenons l'exemple d'une console de salon.
Il y a de grande chance pour que l'expérience utilisateur souhaitée soit différente selon l'application utilisée: dashboard web, application mobile, interface de la console...
La donnée sera présentée différemment, l'authentification sera différente...
Le pattern BFF aurait tout à fait sa place dans ce contexte.

Par contre, si vous développez une application unique, avec un scope réduit, la complexité induite par une nouvelle couche dans votre architecture ne serait pas nécessaire.

Quelques réflexions supplémentaires...

Réfléchir au pattern BFF, c'est déjà avoir envisagé les micro-services comme une solution potentielle.

Est-ce vraiment le cas, quels seraient les cas d'usages parfait pour ce besoin d'architecture ?

Est-ce que j'ai plutôt intérêt à partir sur le développement d'un monolithe modulaire ?

Comment mettre en place une API Gateway dans mon architecture ?

Ressources

Je suis Baptiste FAMCHON, Tech Lead spécialisé frontend chez Claranet.
J'écris régulièrement sur dev.to et LinkedIn à propos de sujets autour du web et de l'artisanat logiciel.

Chez Claranet, nous vous accompagnons aussi dans vos réflexions de modernisation SI, d'infrastructure cloud, de sécurité et de développement web.

N'hésitez pas à nous contacter ! 🚀