Comment choisir le bon BFF pour ton application

Introduction

Dans l'article précédent, nous avons vu comment déterminer si on a besoin d'un BFF. Maintenant, supposons que la décision est prise : vous avez besoin d'un BFF.

La question qui se pose maintenant est : comment l'implémenter ?

Pour des raisons de simplification, on va prendre trois approches populaires :

• Next et ses demi-frères Nuxt et SvelteKit
• GraphQL
• REST

Rappel rapide : notre contexte

Nous avons une application interne de gestion de la relation client après-vente, avec :

• Deux interfaces : bornes Android en magasin + application web pour le service client
• Plusieurs services à orchestrer (stocks, commandes, clients, facturation...)
• Authentification obligatoire avec gestion de sessions
• Application interne uniquement (pas de SEO)

On a validé qu'un BFF est nécessaire. Maintenant, lequel choisir ?

Le choix dépend de plusieurs facteurs

Le choix entre ces technologies va dépendre de plusieurs facteurs, qui ne sont pas uniquement techniques :

Critères organisationnels

1. Quelle approche est favorisée par l'entreprise ?
2. Quel est le Time-to-market ?
3. Quelles sont les compétences existantes dans l'équipe, et sa taille ?
4. Quelle est la data gouvernance de l'entreprise ?

Ainsi, pour une entreprise qui favorise, ou incite à l'utilisation de certains outils, il faut aller dans ce sens. Créer de la cohérence interne est primordial.

Les délais de livraison jouent souvent sur les décisions d'outillage :

• Prendre un outil avec lequel l'équipe est la plus à l'aise
• Et surtout qui permet de "créer de la valeur" rapidement

La data gouvernance est un aspect important, au-delà de l'aspect légalo-juridique, c'est aussi :

• son accessibilité, les moyens pour y parvenir
• en plus des règles de sécurité/confidentialité à appliquer

Les réponses à ces questions permettent d'orienter considérablement la décision.

Si ce n'est pas le cas, nous devrons creuser sur des critères techniques !

Critères techniques

1. Est-ce qu'on souhaite s'orienter sur un certain paradigme DDD, EDA, CQRS (d'ailleurs, si vous voulez des articles sur ces sujets, faites-le nous savoir ;))
2. Quel système de sécurité et d'authentification ?
3. Gestion des erreurs et données partielles ?
4. Quels sont les besoins en termes d'observabilité et monitoring ?
5. Quels sont mes besoins en termes de cache ?
6. Est-ce que l'application est susceptible d'être utilisée dans des conditions réseau faibles ?
7. Besoins en SEO ?

Commençons par les éléments auxquels on sait déjà répondre rapidement

• Notre application est orientée vers deux cibles : Bornes (Android) et Web
• Rajoutons à cela que l'intérêt du SEO est assez faible pour une appli interne

Première piste : les frameworks web (Next, Nuxt, SvelteKit)

Le fait d'avoir une version Web et Mobile implique d'avoir un BFF "agnostique".

On pourrait utiliser Next avec uniquement la partie API, mais quel en serait l'intérêt :

• une dépendance conséquente
• nouvelles notions à assimiler ?
• risque de monolithe déguisé

Un autre bénéfice de Next (ou autres) c'est le SSR/CSR :

• Mis à part dans des cas précis de "performance" ou de "SEO", on n'en profiterait pas a priori

Ces éléments font descendre la priorité des frameworks web.

Leurs avantages ne nous sont pas bénéfiques, et on embarque leurs complexités.

Deuxième piste : un framework plus léger, plus "générique"

Pour des raisons de concision, on va se limiter aux deux "populaires" : REST et GraphQL.

Bien sûr, il en existe beaucoup plus : gRPC, tRPC, OData...

Pour notre application, on va répondre à chaque élément technique. On regardera quelle approche sera la plus adaptée à chaque fois.

Analyse comparative : REST vs GraphQL

Paradigme (DDD, EDA, CQRS)

Que ce soit REST ou GraphQL, on peut les adapter pour répondre à ce besoin. ``

Sécurité et authentification

La politique de sécu impose l'utilisation de cookies avec sessionID plutôt que des tokens Bearer dans les headers.

REST : flexible, gère nativement les cookies et sessionID via le protocole HTTP, s'intègre facilement avec les systèmes d'authentification existants. Les autorisations peuvent être granulaires, tant au niveau endpoint, que champs des données.

GraphQL : permet une sécurité très fine au niveau des champs (via des directives custom ou des libs), mais ça demande une gouvernance stricte et souvent un framework type Apollo ou Yoga pour bien orchestrer tout ça.

Gestion des erreurs et réponses partielles

Les providers peuvent être HS, et donc une gestion des erreurs et des réponses partielles est de mise.

REST : pas de convention native pour les réponses partielles, il faut implémenter sa propre structure. ⚠️

GraphQL : gère nativement les réponses partielles dans sa spec (data + errors). Super pratique quand un service tombe.

Observabilité et monitoring

On doit pouvoir monitorer l'application et avoir un bon niveau d'observabilité.

REST : le tooling déjà intégré dans la plupart des SRE/DevOps (logs par endpoint, facile à tracer).

GraphQL : nécessite plus d'outils spécifiques (Apollo Studio, observabilité des résolveurs...). Plus difficile de savoir "qui demande quoi" sans une bonne instrumentation.

Cache

En ce qui concerne le cache, pas de besoins particuliers à première vue, si ce n'est pour certains cas.

REST : bénéficie gratuitement du cache HTTP standard (CDN, reverse proxy, eTag, Cache-Control...). C'est mature, bien compris par les équipes infra, et ça marche out-of-the-box.

GraphQL : philosophie différente avec un cache applicatif côté client très puissant (Apollo Client, Relay) basé sur la normalisation des données. Côté serveur, il faut mettre en place des stratégies comme les persisted queries.

Conditions réseau

Pas de conditions de réseau particulières, ça sera des bornes (câblées ethernet) en magasins, ou les bureaux du service client (WiFi). La qualité du réseau sera a priori bonne.

GraphQL : est très utile en réseau limité, un appel pour plusieurs ressources.

Convergence vers un choix

Avec cela, on peut voir qu'on converge facilement vers un choix.

Les deux outils permettent d'atteindre l'objectif souhaité : avoir un BFF agnostique. La différence s'est faite sur d'autres éléments comme :

• La facilité de monitoring et d'observabilité
• La gestion de la sécurité et des accès semble plus simple et flexible sur REST
• Facilité de mise en œuvre, avec des outils/libs minimalistes pour REST

Tableau de décision

Conclusion

Dans notre cas, REST semble le choix le plus adapté grâce à :

• sa simplicité de mise en œuvre avec des outils/libs minimalistes
• la facilité de monitoring et d'observabilité avec le tooling existant
• une gestion plus souple de la sécurité qui s'aligne avec nos contraintes
• un écosystème de cache HTTP mature

GraphQL reste une excellente alternative dans d'autres contextes, notamment :

• Conditions réseau difficiles (mobile, zones à faible connexion)
• Besoins de flexibilité côté client très importants
• Plusieurs types de clients avec des besoins de données très différenciés

Comme on peut le voir, le choix d'une solution technique n'est pas basé QUE sur des critères techniques, ni la hype du moment.

Il est plus simple de faire des choix quand on pose les bonnes questions.