De nos jours, il est rare de trouver une application qui ne communique pas du tout avec l’extérieur. La majorité des applications que l’on utilise font des requêtes vers un ou plusieurs serveurs - pour demander des données, les afficher dynamiquement, et pour en envoyer.

J’ai fait le test avec mon téléphone, j’ai eu du mal à trouver une application qui ne faisait aucune requête (en tout cas en apparence, je n’en suis même pas sûr à 100%). J’ai la calculatrice qui vit sa vie dans son coin.

Pourquoi je raconte ça ? Parce que ces applications font très probablement des requêtes vers un serveur qui leur appartient. En d’autres termes, l’équipe, le département, ou l’entreprise qui gère le développement de l’application est également responsable du serveur.

Dans l’épisode précédent, on a vu qu'une configuration à distance permettait de changer le comportement d’une application mobile. Et que la configuration à distance, ce pouvait être simplement un fichier JSON ou une API qui exposait quelques valeurs.

De là à faire le rapprochement entre les données envoyées par nos serveurs et la possibilité de changer le comportement d’une application mobile à distance, il n’y a vraiment qu’un petit pas. Alors faisons-le !

Vers une API spécialisée

En général, ce qu’on retrouve souvent, c’est un backend qui tends vers de l’envoi de données brutes aux fronts. Et qui s’approche plus ou moins du REST. Pour alimenter une page, le front mobile devra effectuer une ou plusieurs requêtes puis traiter les données, appliquer un peu de logique.

Imaginons une page agenda sur notre application. On a envie de mettre en valeur les événements qui ont lieu aujourd’hui, dans de jolis encarts avec un maximum d’informations, ainsi que les 3 prochains événements. Pour le reste, on les groupe par semaine glissante et juste le titre nous suffira.

Notre backend nous propose une route qui retourne 100 événements, à partir du début de la semaine. Côté front mobile, on va devoir trier par date, filtrer les événements passés, mettre de côté les événements du jour et également les 3 prochains pour la mise en valeur, puis ensuite faire des groupes par semaine glissante.

Beaucoup de logique métier qui se retrouve côté client (l’application). Si on décide de changer, disons par exemple la sélection des événements qui sont mis en valeur, il faut modifier l’application et donc redéployer, ce qui implique de traverser tout le process de soumission sur les stores que l’on aimerait éviter.

Sans parler des données qui transitent sur le réseau : on a besoin que du titre pour une grande partie des événements. On augmente au passage la charge serveur pour rien. Bonne nouvelle, on a dit qu’on est responsable du serveur - on peut décider d’y déporter certaines logiques.

Le backend pourrait :

• Trier dans l’ordre adapté,
• Ne renvoyer que les futurs événements.
• Porter la mise en valeur en envoyant deux listes distinctes, et indiquer juste le titre pour les événements lointains.
• Grouper par semaine glissante.
• Aller plus loin en portant la logique de présentation. “Afficher une carte avec un titre, une description, une date pour cet événement mis en valeur, afficher un simple titre pour cet événement, etc”. On commencerait alors à parler de Server-Driven UI.

En fonction de ce que l’on déporte sur le backend, on pourra modifier le comportement de l’application à distance en déployant une nouvelle version du backend plutôt que de l’application. Et c’est souvent bien plus rapide.

Notre API, qui était généraliste, devient spécialisée pour un front.

Le cas GraphQL

Un petit aparté sur GraphQL. Je le mettrais bien dans le panier API généraliste pour notre histoire. Oui, ça apporte une certaine flexibilité au front qui consomme l’API, il peut sélectionner ce qu’il veut, mais à la fin, c’est toujours le front qui construit les requêtes. On veut finalement filtrer les événements passés ? Eh bien il faut redéployer l’application.

Certes, c’est une modification très simple puisque c’est peut-être seulement un paramètre dans la requête GraphQL à ajouter ou modifier, mais cette modification est à faire côté client (notre application). Elle impliquera une soumission de la version sur les stores.

On n’est pas dans la spécialisation de notre API, elle ne porte pas de la logique supplémentaire dédiée au front.

Backend for Frontend

Avoir une API spécialisée, ça peut nous embêter dans certains cas. Si j’ai plusieurs fronts par exemple : un site web et une application mobile. Il y a parfois une logique différente entre les deux. Le web est une autre plateforme, l’interface est très différente. Pour l’agenda, je veux tout afficher sous la forme d’un calendrier mensuel.

On comprend donc l’intérêt d’avoir une API généraliste qui essaye de faire plaisir à tout le monde. Pour autant, on perçoit aussi les avantages d’avoir une API spécialisée. C’est là qu’intervient le principe de Backend for Frontend : on peut avoir les deux !

Un Backend For Frontend, souvent connu avec l’acronyme BFF, est une couche intermédiaire entre un backend et un frontend. Concrètement, c’est un backend supplémentaire qui va traiter des données spécifiquement pour un type de front (une application mobile par exemple).

Notre front mobile va effectuer toutes ses requêtes en passant par le Back for Front, et uniquement ce dernier. C’est le Back for Front qui appellera le backend pour obtenir les données nécessaires. Il pourra ensuite appliquer de la logique dédiée avant de renvoyer les données à l’application mobile. Le site web aurait de son côté son propre Back for Front.

Vu que le Back for Front devient le point d’entrée unique du front, il peut servir d'agrégateur. Peut-être que pour notre agenda, on avait besoin de la liste des événements futurs et également des événements où l’on est inscrit. Plutôt que de faire deux requêtes, le front n’en fera qu’une seule vers le BFF.

Avec cette mécanique, on voit rapidement plusieurs avantages :

• On sépare les logiques spécialisées. Il y a un BFF mobile, un BFF web, etc.
• On sépare la partie spécialisée de la partie généraliste. Il y a un backend qui ne subit pas les caprices du front.
• Un développeur mobile peut plus aisément sortir de son éco-système et effectuer des changements sur le BFF.
• On peut regrouper plusieurs ressources en une seule route, et réfléchir en termes de page, d’écran.
• On cache la complexité au front. Il n’y a pas à savoir s’il y a plusieurs services ou même s’il y a un partenaire externe.

Et notamment, ce qui nous intéresse particulièrement dans cette série d’articles, on déporte de la logique client (app mobile) sur un serveur distant (notre BFF). On peut donc modifier du comportement sans passer par les stores ! On aime :)

C’est tout de même une décision à peser dans l’équipe. Qui dit couche supplémentaire, dit une maintenance supplémentaire. Il y a une nouvelle brique qui doit évoluer et être déployée. Déléguer davantage au Back for Front augmente au passage les possibilités d’erreurs sur l’application - elle est plus permissive. On songera à monitorer plus en profondeur ce qu’il se passe dans l’application.

Série d’articles Mettre à jour une application mobile sans passer par les stores :

• #1 Pourquoi
• #2 Remote config, Feature Flag & co
• #3 Backend for Frontend (BFF)
• #4 Server-Driven UI
• #5 Interpréteur de code
• #6 Over-the-air update (OTA)
• #7 Les ressources
• #8 En résumé, mes options

Hors-série :

• Accélérer le temps de review App Store d’une application iOS
• Forcer la mise à jour d’une application mobile